A risk control analysis method, device, equipment and medium
By constructing a full-domain risk control interception strategy and feature testing system analysis in risk control analysis, the problem of feature data error and inaccuracy is solved, the accuracy and reliability of risk control analysis is improved, and the risks of misjudgment and misjudgment are reduced.
Patent Information
- Application Number
- CN202411816267.8
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-12-11
- Publication Date
- 2025-04-04
AI Technical Summary
The prior art has problems with characteristic data errors or inaccuracy in risk control analysis, which affects the accuracy and reliability of the analysis results, increasing the risk of misjudgment and misjudgment.
By constructing a full-domain risk control interception strategy, the characteristic data in the business request is strongly verified, the feature testing system is used to analyze and judge the problem information, generate missing analysis results, and create a problem follow-up order through the risk control testing system to complete the risk control analysis.
It significantly improves the quality of risk control feature data, avoids the risks of misjudgment and misjudgment caused by missing or non-compliance in characteristic data, enhances the accuracy and reliability of the risk control system, and reduces the lag of data governance and the time for problem handling.
Smart Images

Figure CN119761815A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the field of the Internet, and in particular to a risk control analysis method, device, equipment and medium. Background Art
[0002] In Internet business, feature data refers to data indicators that can reflect the identity, behavior and credit status of users. These feature data usually include user identity information, etc. At present, there are some significant problems in risk control analysis of feature data.
[0003] The accuracy of risk control analysis results is highly dependent on the accuracy of the acquired feature data. If the feature data itself contains errors or inaccuracies, it will directly affect the analysis results and lead to misjudgments or wrong judgments. The sources of feature data may be diverse, including user-submitted information, system logs, third-party data, etc. These data may have problems such as input errors, transmission loss, and data forgery, which seriously affect the analysis. Therefore, how to improve the accuracy and reliability of risk control analysis and reduce misjudgments and wrong judgments is an urgent problem to be solved. Summary of the invention
[0004] The object of the present invention is to provide a risk control analysis method, device, equipment and medium, which can improve the accuracy and reliability of risk control analysis.
[0005] In order to solve the above technical problems, the present invention is achieved through the following technical solutions:
[0006] The present invention provides a risk control analysis method, comprising:
[0007] In response to a service request from a user terminal, the real-time risk control system verifies the service request according to the configured global interception condition, and if the service request fails to pass the verification, the system feeds back the verification result to the user terminal and generates problem information; wherein the service request includes at least one feature data, and the problem information includes the feature data with the problem;
[0008] The feature testing system analyzes and determines the problem information according to the configured notification conditions to generate a missing analysis result;
[0009] The risk control test system analyzes the business request according to the missing analysis result to generate missing information;
[0010] The risk control testing system creates a problem follow-up form according to the missing information, and processes the problem follow-up form to complete the risk control analysis of the business request.
[0011] In one embodiment of the present invention, the step of the real-time risk control system verifying the service request according to the configured global interception condition includes:
[0012] The risk control test system selects the interface information required to be input based on the preset interface document, wherein the interface information includes whether the feature data is necessary and the enumeration relationship between the feature data;
[0013] The risk control test system configures corresponding global interception conditions according to the interface information;
[0014] The real-time risk control system verifies the business request according to the configured global interception conditions.
[0015] In one embodiment of the present invention, the step of the real-time risk control system verifying the service request according to the configured global interception condition includes:
[0016] The real-time risk control system verifies the characteristic data in the business request according to the interface information in the configured global interception condition:
[0017] When the service request includes all the necessary feature data in the global interception condition and there is no problem in the enumeration relationship between the feature data in the service request, the service request passes the verification and the verification result is fed back to the user terminal;
[0018] Otherwise, the service request fails the verification, and the verification result is fed back to the user terminal, and problem information is generated at the same time.
[0019] In one embodiment of the present invention, the feature testing system analyzes and determines the problem information according to the configured notification conditions to generate a missing analysis result, including:
[0020] The risk control test system configures notification conditions based on preset interface problems;
[0021] The feature testing system judges the problem information according to the configured notification conditions:
[0022] When the problem information belongs to the preset interface problem, the risk control analysis process ends;
[0023] Otherwise, a missing analysis is performed on the problem information, a missing analysis result is generated, and notification information is generated.
[0024] In an embodiment of the present invention, the risk control testing system creates a problem follow-up form according to the missing information, and processes the problem follow-up form to complete the risk control analysis of the business request, including the following steps:
[0025] The risk control test system creates a problem follow-up form according to the missing information, and determines the problem of the corresponding problem follow-up form according to the notification information:
[0026] When the issue in the issue follow-up form is invalid, the risk control analysis process ends;
[0027] When the problem follow-up form needs to be deferred for processing, the problem follow-up form is processed after the deferred time reaches a preset time;
[0028] When the problem follow-up form needs to be processed, the problem in the problem follow-up form is judged:
[0029] When the problem in the problem follow-up form does not need to be modified, the problem follow-up form is fed back to the user end, and the user end modifies the service request according to the problem follow-up form and generates a new service request;
[0030] When the issue in the issue follow-up form is invalid, the risk control analysis process ends;
[0031] When the problem in the problem follow-up sheet is an interface document error or a program error, it is repaired to complete the risk control analysis of the business request.
[0032] In one embodiment of the present invention, when the problem follow-up form needs to be deferred for processing, after the deferred time reaches a preset time, the step of processing the problem follow-up form includes:
[0033] After the extension period reaches the preset period, the risk control test system is used to determine whether the issue of the issue follow-up order is an invalid issue:
[0034] If yes, then the risk control analysis process ends;
[0035] Otherwise, the issue follow-up sheet will be processed.
[0036] In one embodiment of the present invention, when the problem in the problem follow-up form is an interface document error or a program error, the step of repairing it to complete the risk control analysis of the business request includes:
[0037] When the problem in the problem follow-up form is an interface document error or a program error, a corresponding problem rectification form is created, and the interface document error or program error is repaired according to the problem rectification form until the repair is completed, so as to complete the risk control analysis of the business request.
[0038] The present invention also provides a risk control analysis device, comprising:
[0039] A service verification module is used to respond to a service request from a user terminal, verify the service request through the global interception condition configured by the real-time risk control system, and if the service request fails to pass the verification, feedback the verification result to the user terminal and generate problem information; wherein the service request includes at least one feature data, and the problem information includes the feature data with the problem;
[0040] An analysis and judgment module, used to analyze and judge the problem information through the notification conditions configured by the feature test system to generate a missing analysis result;
[0041] a result analysis module, configured to analyze the business request according to the deficiency analysis result through the risk control test system to generate deficiency information; and
[0042] A result processing module is used to create a problem follow-up form according to the missing information through the risk control testing system, and process the problem follow-up form to complete the risk control analysis of the business request.
[0043] The present invention also provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the steps of the risk control analysis method are implemented when the processor executes the computer program.
[0044] The present invention also provides a computer-readable storage medium, which stores a computer program, and when the computer program is executed by a processor, the steps of the risk control analysis method are implemented.
[0045] As described above, the present invention provides a risk control analysis method, device, equipment and medium, which constructs a global risk control interception strategy to perform strong verification on the characteristic data in the business request, significantly improves the quality of the risk control characteristic data, avoids the risk of misjudgment and missed judgment due to missing or non-compliant characteristic data, and enhances the accuracy and reliability of the risk control system. Through the risk control characteristic test system, a detailed comparison and analysis of the intercepted non-compliant traffic is performed to quickly identify specific problem characteristic data and the cause of the problem, which greatly reduces the lag of data governance and improves the efficiency and response speed of problem handling.
[0046] Of course, any product implementing the present invention does not necessarily need to achieve all of the advantages described above at the same time. BRIEF DESCRIPTION OF THE DRAWINGS
[0047] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings required for describing the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other accompanying drawings can be obtained based on these accompanying drawings without paying creative work.
[0048] Figure 1 This is a flow chart of a risk control analysis method according to an embodiment of the present invention;
[0049] Figure 2 A schematic diagram of a risk control analysis process according to an embodiment of the present invention;
[0050] Figure 3 A schematic diagram of generating missing information according to an embodiment of the present invention;
[0051] Figure 4 A schematic diagram of processing a problem follow-up form according to an embodiment of the present invention;
[0052] Figure 5 A schematic diagram of generating a missing analysis result by a feature testing system according to an embodiment of the present invention;
[0053] Figure 6 Another schematic diagram of processing a problem follow-up form according to an embodiment of the present invention;
[0054] Figure 7 A schematic diagram of a risk control analysis device according to an embodiment of the present invention;
[0055] Figure 8 FIG. 4 is a schematic diagram of an electronic device according to an embodiment of the present invention.
[0056] In the figure: 100, user end; 200, risk control test system; 300, real-time risk control system; 400, feature test system; 500, business verification module; 600, analysis and judgment module; 700, result analysis module; 800, result processing module; 1, electronic device; 12, memory; 13, processor. DETAILED DESCRIPTION
[0057] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.
[0058] See also Figure 1 The present invention provides a risk control analysis method, which can verify the service request sent by the user terminal 100 to complete the risk control analysis of the service request. The risk control analysis method may include the following steps:
[0059] Step S10: In response to the service request of the user terminal, the real-time risk control system verifies the service request according to the configured global interception condition, and if the service request fails to pass the verification, the system feeds back the verification result to the user terminal and generates problem information; wherein the service request includes at least one feature data, and the problem information includes the feature data with the problem;
[0060] Step S20: the feature testing system analyzes and determines the problem information according to the configured notification conditions to generate a missing analysis result;
[0061] Step S30: The risk control test system analyzes the business request according to the missing analysis result to generate missing information;
[0062] Step S40: The risk control testing system creates a problem follow-up form according to the missing information, and processes the problem follow-up form to complete the risk control analysis of the business request.
[0063] See also Figure 1 and Figure 2 In one embodiment, when executing step S10, specifically, step S10 may include the following steps:
[0064] Step S11: The risk control test system selects the interface information required to be input based on the preset interface document, wherein the interface information includes whether the feature data is necessary and the enumeration relationship between the feature data;
[0065] Step S12: The risk control test system configures corresponding global interception conditions according to the interface information;
[0066] Step S13: The real-time risk control system verifies the business request according to the configured global interception conditions.
[0067] See also Figure 2 In one embodiment, when executing step S11, specifically, the risk control test system 200 may select the interface information required to be input from the preset interface document. The interface information may include whether the feature data is necessary and the enumeration relationship between the feature data.
[0068] In one embodiment, the interface document may be a risk control interface document, which is a document of various interface specifications for risk control purposes. The risk control interface document defines the specific requirements of the interface, such as the parameters that need to be passed in (i.e., feature data), whether these parameters must be provided, the type and format of the parameters, the relationship between the parameters (e.g., whether the value of a parameter depends on the value of another parameter), etc.
[0069] In one embodiment, the risk control test system 200 can extract and organize the interface information related to the current risk control test from the risk control interface document. The interface information may include but is not limited to the necessity of feature data, the type of feature data, the format of feature data, the enumeration relationship between feature data, etc. The enumeration relationship refers to the possible logical relationship or dependency.
[0070] In one embodiment, when executing step S12, specifically, the risk control test system 200 can configure the corresponding global interception condition according to the interface information, and send the global interception condition to the real-time risk control system 300.
[0071] In one embodiment, the feature compliance verification condition refers to the interface information sorted out from the risk control interface document, and reasonable verification rules are set for each or each group of feature data in the interface information. The verification rules can be used to check whether the incoming feature data meets the requirements in the risk control interface document, such as whether all necessary feature data are provided, whether the value of the feature data is valid, whether the enumeration relationship between the feature data is correct, etc. The purpose of setting these verification conditions is to discover and prevent possible risk operations in advance and improve the security and stability of the system.
[0072] In one embodiment, the global interception condition refers to a set of feature compliance verification conditions that are valid throughout the entire risk control system and are used to intercept high-risk or non-compliant operations. The risk control test system 200 can generate corresponding global interception conditions based on the configured feature compliance verification conditions and send them to the real-time risk control system 300. The real-time risk control system 300 can be responsible for real-time monitoring and interception of business requests sent by the user terminal 100 based on the received global interception conditions during the actual operation of the system, so as to ensure that the risk control rules can be applied in a timely manner and effectively control risks.
[0073] In one embodiment, when step S13 is executed, specifically, step S13 may include the following steps:
[0074] Step S131: The real-time risk control system verifies the characteristic data in the business request according to the interface information in the configured global interception condition:
[0075] Step S132: When the service request includes all the necessary feature data in the global interception condition and there is no problem with the enumeration relationship between the feature data in the service request, the service request passes the verification and the verification result is fed back to the user terminal;
[0076] Step S133: Otherwise, the service request fails the verification, and the verification result is fed back to the user end, and problem information is generated at the same time.
[0077] In one embodiment, when executing step S131, specifically, the user terminal 100 can be any front-end application or service, such as an App for a ride-hailing driver. The user terminal 100 can send a business request by calling the risk control interface of the real-time risk control system 300. The business request contains at least one feature data, which can be various information filled in by the user, such as vehicle information, certificate information, etc.
[0078] In one embodiment, after the real-time risk control system 300 receives the service request sent by the user terminal 100, it is necessary to determine whether the data quality of the service request meets the standard according to the configured global interception conditions. When verifying the service request, necessity verification and enumeration relationship verification can be performed separately. Necessity verification refers to checking whether all necessary feature data are included in the service request. Enumeration relationship verification refers to checking whether the logical relationship between feature data is correct, for example, whether the value of a feature data depends on the value of another feature data.
[0079] In one embodiment, when executing step S132, specifically, in one embodiment, if the service request contains all necessary feature data in the global interception condition, and there is no problem with the enumeration relationship between the feature data, then the real-time risk control system 300 feeds back the verification result to the user terminal 100, allowing the service to continue.
[0080] In one embodiment, when executing step S133, specifically, in one embodiment, if the service request does not contain some or all of the feature data necessary in the global interception condition, and / or there is a problem with the enumeration relationship between the feature data in the service request, then the real-time risk control system 300 can feedback the result of the verification failure to the user terminal 100. At the same time, the problem information is sent to the feature test system for further processing and analysis.
[0081] See also Figure 3 In one embodiment, the registration scenario when an online car-hailing driver joins the online car-hailing App is taken as an example. At this time, the driver can submit the joining information through the App, and the information review system assembles this information into an HTTP request and calls the risk control interface. The real-time risk control system 300 can check whether the submitted feature data contains required data, such as joining ID, driver information, certificate information, vehicle information, etc. according to the configured global interception strategy. If all the required data is present and the logical relationship is correct, the real-time risk control system 300 returns a passed result and allows the driver to continue registering. If it is detected that the required data is missing or the logical relationship is wrong, the real-time risk control system 300 returns an interception result code (for example, 100001-forbidden to join) and returns a message that "the risk control required field is missing". After receiving this information, the information review service blocks the driver's joining authentication, and transparently transmits the interception result and message to the App to display it to the user.
[0082] In one embodiment, when step S20 is executed, specifically, step S20 may include the following steps:
[0083] Step S21: The risk control test system configures notification conditions according to preset interface problems;
[0084] Step S22: The feature test system determines the problem information according to the configured notification conditions:
[0085] Step S23: When the problem information belongs to a preset interface problem, the risk control analysis process ends;
[0086] Step S24: Otherwise, perform a missing analysis on the problem information, generate a missing analysis result, and generate notification information.
[0087] In one embodiment, when executing step S21 , specifically, the risk control testing system 200 may also be used to configure notification conditions according to preset interface problems and send them to the feature testing system 400 .
[0088] In one embodiment, in the feature testing system 400, the notification condition is used to inform the risk control testing system 200 that there are data quality problems with the business request from the user terminal 100. The notification condition may include policy-tolerance interface information, policy ID information, and policy interception condition information. Among them, the policy-tolerance interface information refers to the policy of which interface information triggered the notification, so that the risk control testing system 200 can quickly locate the interface information where the problem is. The policy ID information means that each policy has a unique identifier (ID) to distinguish different policy configurations. The policy interception condition information refers to which feature compliance verification conditions triggered the interception, so that the risk control testing system 200 can understand the specific cause of the problem. Notification conditions can be divided into three types.
[0089] In one embodiment, the first type is no notification, that is, no message is sent to the risk control test system 200. For example, when the data quality problem request message intercepted by the interface information does not require manual intervention (for example, a known interface problem that cannot be fixed temporarily). In this case, the risk control test system 200 can automatically handle the problem, or the problem has been recorded but there is no solution temporarily.
[0090] In one embodiment, the second type is a silent notification, that is, a message is sent to the risk control test system 200. For example, when the data quality problem request message intercepted by the interface information is being processed (for example, a known problem, which is being repaired and does not need to be processed repeatedly). This notification method reminds relevant personnel that the problem is being processed to avoid duplication of work or multiple alarms.
[0091] In one embodiment, the third type is notification, that is, sending a message to a fixed group (for example, a team responsible for monitoring and handling all problems in the risk control test system 200). By default, all intercepted data quality issues will be notified.
[0092] In one embodiment, when executing step S22, specifically, the feature test system 400 can receive the problem information transmitted from the real-time risk control system 300, and verify and process the information according to the configured notification conditions. Specifically, the feature test system 400 needs to determine whether the problematic feature data in the problem information meets the configured notification conditions. When the business request fails to pass the verification, the real-time risk control system 300 will send the problem information to the feature test system 400. The problem information may include which feature data has problems, specific problem details, etc.
[0093] In one embodiment, the feature testing system 400 can determine whether the received problem information meets the preset notification conditions and decide whether a notification needs to be sent. If the problem information meets the preset interface problem in the notification conditions, the subsequent processing flow continues. If the problem information does not meet the preset interface problem in the notification conditions, the processing flow is terminated and no notification is sent. Among them, the preset interface problem refers to a known business problem that does not need to be processed and no notification is sent. For example, a known problem of an interface cannot be fixed for the time being, but it has been recorded and there is no need to send a notification every time.
[0094] In one embodiment, when step S23 is executed, specifically, if all problematic feature data in the problem information belong to the preset interface problem, the risk control analysis process is terminated and no further processing is performed.
[0095] In one embodiment, when executing step S24, specifically, part or all of the feature data in the problem information does not belong to the preset interface problem and needs further processing. For example, a certain feature data is missing or wrong, but this problem has not been encountered before and needs to be analyzed and processed in detail. The feature testing system 400 will perform a missing analysis on these problem data and generate detailed missing analysis results. Subsequently, the generated missing analysis results can be sent to the risk control testing system 200 for further processing and improvement. After completing the missing analysis, the feature testing system 400 can send a notification to the corresponding notification recipient based on the notification recipient information in accordance with the rule conditions.
[0096] In one embodiment, when executing step S30, specifically, the risk control test system 200 can be used to analyze the business request according to the missing analysis results to generate missing information. Specifically, the risk control test system 200 can confirm and collect missing information with the business service in the user terminal 100 (i.e., the source service where the problem occurs). The missing information may include characteristic data of the problem, the time node for sending the business request, and the business scenario of the business request. The characteristic data of the problem still refers to which specific fields are missing or wrong. The time node for sending the business request refers to the specific time when the problem occurs. The business scenario of the business request refers to the business scenario where the problem occurs, such as driver registration, order submission, etc.
[0097] In one embodiment, when step S40 is executed, specifically, step S40 may include the following steps:
[0098] Step S41: The risk control test system creates a problem follow-up form based on the missing information, and determines the problem of the corresponding problem follow-up form based on the notification information:
[0099] Step S42: When the issue in the issue follow-up form is an invalid issue, the risk control analysis process ends;
[0100] Step S43: When the problem follow-up form needs to be deferred, the problem follow-up form is processed after the deferred time reaches a preset time;
[0101] Step S44: When the problem follow-up form needs to be processed, the problem of the problem follow-up form is judged:
[0102] Step S45: When the problem in the problem follow-up form does not need to be modified, the problem follow-up form is fed back to the user end, and the user end modifies the business request according to the problem follow-up form and generates a new business request;
[0103] Step S46: When the issue in the issue follow-up form is an invalid issue, the risk control analysis process ends;
[0104] Step S47: When the problem in the problem follow-up form is an interface document error or a program error, repair it to complete the risk control analysis of the business request.
[0105] See also Figure 4 , Figure 5 and Figure 6 In one embodiment, when executing step S41, specifically, after completing the analysis, the risk control test system 200 may create a problem follow-up form in the feature test system 400 to record and manage the problem handling process. The problem follow-up form may include the missing analysis results and the missing information.
[0106] In one embodiment, after the feature testing system 400 generates the missing analysis results, the risk control testing system 200 will create a corresponding problem follow-up form and change the problem follow-up form to a pending status. The status of the problem follow-up form will flow between different states according to the processing situation. The status of the problem follow-up form may include pending, following up, deferred processing, abandoned, closed, and transferred to bug, etc. The risk control testing system 200 can be used to process the problem follow-up form and determine the problems therein.
[0107] In one embodiment, when executing step S42, specifically, the risk control test system 200 ends the risk control analysis process when confirming that the problem in the problem follow-up form is an invalid problem. An invalid problem refers to a preset problem that does not need to be processed. For example, an invalid problem may be a manual request for traffic rather than a real business. At this time, the problem follow-up form flows to an abandoned state and does not need to be processed.
[0108] In one embodiment, when step S43 is executed, specifically, step S43 may include the following steps:
[0109] Step S431: After the extension period reaches the preset period, the risk control test system is used to determine whether the issue in the issue follow-up form is an invalid issue:
[0110] Step S432: If yes, then end the risk control analysis process;
[0111] Step S433: Otherwise, process the problem follow-up form.
[0112] In one embodiment, when executing step S431, step S432 and step S433, specifically, when the risk control test system 200 confirms that the problem follow-up form needs to be deferred for processing, after the deferred time reaches the preset time, the risk control test system is used to determine whether the problem in the problem follow-up form is an invalid problem: if so, the risk control analysis process is terminated; otherwise, the problem follow-up form is processed. Among them, deferred processing means that if the problem processing cost is high and it takes a long time to solve (for example, it cannot be solved within a week), the problem follow-up form will be transferred to the deferred processing state. After the deferred time reaches the preset time, if it is determined that the problem needs to be reprocessed based on the existing information, the problem follow-up form will be transferred to the follow-up state and continue to be processed. If the problem in the problem follow-up form becomes an invalid problem at this time, the follow-up form will be transferred to the abandoned state.
[0113] In one embodiment, when executing step S44, specifically, when the risk control test system 200 confirms that the problem follow-up form needs to be processed, it needs to judge the problem of the problem follow-up form again. At this time, the risk control test system 200 can continue to add more clues to better judge the problem.
[0114] In one embodiment, when executing step S45, specifically, when the risk control test system 200 confirms that the problem of the problem follow-up form does not need to be modified, it will feedback the problem follow-up form to the user end, and the user end will modify the business request according to the problem follow-up form and send a new business request. If it is determined that the problem does not need to be modified, the problem follow-up form will flow to the closed state.
[0115] In one embodiment, when executing step S46, specifically, the risk control test system 200 ends the risk control analysis process when confirming that the problem in the problem follow-up form is an invalid problem. For example, if it is determined to be an invalid problem, the problem follow-up form flows to the abandoned state.
[0116] In one embodiment, when executing step S47, specifically, when the problem in the problem follow-up form is an interface document error or a program error, a corresponding problem rectification form is created, and the interface document error or program error is repaired according to the problem rectification form until the repair is completed, thereby completing the risk control analysis of the business request.
[0117] In one embodiment, when the risk control test system 200 confirms that the problem in the problem follow-up form is an interface document error or a program error, the risk control test system creates a corresponding problem rectification form, and repairs the interface document error or program error according to the problem rectification form until the repair is completed, so as to complete the risk control analysis of the business request. For example, if the problem is a code bug or a product document bug, a problem rectification form needs to be created at this time, and the problem rectification form is transferred to the bug state, and the bug repair progress is continuously followed up until the follow-up form is completed after the problem is resolved.
[0118] In one embodiment, the registration scenario of an online car-hailing driver joining an online car-hailing App is taken as an example for explanation. After the feature testing system 400 generates the missing analysis results, the risk control testing system 200 will create a problem follow-up form in the feature testing system 400 and change the status to pending. When the risk control testing system 200 processes the problem follow-up form, if it is judged to be an invalid problem, for example, a driver registration request is manually sent by the testing team, rather than the actual driver registration traffic, then the problem follow-up form will be transferred to the abandoned state. If a problem with missing feature data involves multiple systems and teams, it is expected to take a long time to resolve. At this time, the follow-up form will be transferred to the deferred processing state. If a problem with missing feature data requires further confirmation of the cause, the follow-up form will be transferred to the follow-up state by adding more clues.
[0119] In one embodiment, adding more clues means continuing to collect information, such as confirming with the development team the specific cause of the problem. After confirmation, it is found that the missing feature data is required by the business logic and does not need to be modified. At this point, the follow-up form is transferred to the closed state. If it is found that a certain feature data is missing due to a code logic error or a product document description error, a bug ticket is created, and the follow-up form is transferred to the bug state. The bug repair progress is continuously followed up until the problem is resolved and the follow-up form is completed. If it is found that a certain feature data is missing due to user error rather than a system problem, the problem follow-up form can be fed back to the user end. The user end can modify the business request according to the problem follow-up form and send a new business request. At this time, the problem follow-up form can be transferred to the abandoned state.
[0120] It can be seen that in the above scheme, by constructing a global risk control interception strategy and performing strong verification on the feature data in the business request, the quality of the risk control feature data is significantly improved, the risk of misjudgment and missed judgment caused by missing or non-compliant feature data is avoided, and the accuracy and reliability of the risk control system are enhanced. Through the risk control feature test system, the intercepted non-compliant traffic is compared and analyzed in detail to quickly identify the specific problem feature data and the cause of the problem, which greatly reduces the lag of data governance and improves the efficiency and response speed of problem handling. The problem follow-up form mechanism is not only used to record the discovery of the problem, but also to track the problem handling process to ensure that each problem has a clear processing path and result. By creating and managing problem rectification forms, code bugs or product document bugs are fixed, further improving the reliability and performance of the risk control system. Through real-time interception and rapid processing mechanisms, it is ensured that the business requests submitted by users can be responded to quickly and accurately, avoiding business interruptions or erroneous processing caused by data non-compliance.
[0121] It should be understood that the order of execution of the steps in the above embodiment does not necessarily mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiment of the present invention.
[0122] See also Figure 7 The present invention also provides a risk control analysis device, which can be applied to the above-mentioned risk control analysis method. The risk control analysis device can include a business verification module 500, an analysis and judgment module 600, a result analysis module 700, and a result processing module 800.
[0123] In one embodiment, the business verification module 500 can be used to respond to a business request from a user terminal, verify the business request through the global interception conditions configured by the real-time risk control system, and if the verification fails, feedback the verification result to the user terminal and generate problem information; wherein, the business request includes at least one characteristic data, and the problem information includes the characteristic data with problems.
[0124] In one embodiment, the analysis and judgment module 600 may be used to analyze and judge the problem information according to the notification conditions configured by the feature test system to generate a missing analysis result.
[0125] In one embodiment, the result analysis module 700 may be used to analyze the business request according to the missing analysis result through the risk control test system to generate missing information.
[0126] In one embodiment, the result processing module 800 may be used to create a problem follow-up form according to the missing information through the risk control testing system, and process the problem follow-up form to complete the risk control analysis of the business request.
[0127] See also Figure 8 In one embodiment, the electronic device 1 may include a memory 12, a processor 13 and a bus, and may also include a computer program stored in the memory 12 and executable on the processor 13, such as a risk control analysis program.
[0128] In one embodiment, the memory 12 includes at least one type of readable storage medium, and the readable storage medium includes a flash memory, a mobile hard disk, a multimedia card, a card-type memory (for example, SD or DX memory, etc.), a magnetic memory, a disk, an optical disk, etc. In some embodiments, the memory 12 may be an internal storage unit of the electronic device 1, such as a mobile hard disk of the electronic device 1. In other embodiments, the memory 12 may also be an external storage device of the electronic device 1, such as a plug-in mobile hard disk, a smart memory card (Smart Media Card, SMC), a secure digital (Secure Digital, SD) card, a flash card (Flash Card), etc. equipped on the electronic device 1. Further, the memory 12 may also include both an internal storage unit of the electronic device 1 and an external storage device. The memory 12 can not only be used to store application software and various types of data installed in the electronic device 1, such as risk control analysis code, etc., but also be used to temporarily store data that has been output or is to be output.
[0129] In one embodiment, the processor 13 may be composed of an integrated circuit, for example, a single packaged integrated circuit, or a plurality of packaged integrated circuits with the same or different functions, including one or more central processing units (CPUs), microprocessors, digital processing chips, graphics processors, and combinations of various control chips. The processor 13 is the control core (ControlUnit) of the electronic device 1, and uses various interfaces and lines to connect various components of the entire electronic device 1, and executes or executes programs or modules stored in the memory 12, and calls data stored in the memory 12, so as to execute various functions of the electronic device 1 and process data.
[0130] In one embodiment, the processor 13 executes the operating module and various installed applications of the electronic device 1. The processor 13 executes the application to implement the steps in the above-mentioned risk control analysis method.
[0131] In one embodiment, the computer program may be divided into one or more modules, one or more modules are stored in the memory 12, and executed by the processor 13 to complete the present application. One or more modules may be a series of computer program instruction segments capable of completing specific functions, and the instruction segments are used to describe the execution process of the computer program in the electronic device 1.
[0132] The embodiments of the present invention disclosed above are only used to help illustrate the present invention. The embodiments do not describe all the details in detail, nor do they limit the invention to the specific embodiments described. Obviously, many modifications and changes can be made according to the content of this specification. This specification selects and specifically describes these embodiments in order to better explain the principles and practical applications of the present invention, so that those skilled in the art can understand and use the present invention well. The present invention is limited only by the claims and their full scope and equivalents.
Claims
1. A risk control analysis method, characterized in that: include: In response to a service request from a user terminal, the real-time risk control system verifies the service request according to the configured global interception condition, and if the service request fails to pass the verification, the system feeds back the verification result to the user terminal and generates problem information; wherein the service request includes at least one feature data, and the problem information includes the feature data with the problem; The feature testing system analyzes and determines the problem information according to the configured notification conditions to generate a missing analysis result; The risk control test system analyzes the business request according to the missing analysis result to generate missing information; The risk control testing system creates a problem follow-up form according to the missing information, and processes the problem follow-up form to complete the risk control analysis of the business request.
2. The risk control analysis method according to claim 1, characterized in that: The step of the real-time risk control system verifying the business request according to the configured global interception condition includes: The risk control test system selects the interface information required to be input based on the preset interface document, wherein the interface information includes whether the feature data is necessary and the enumeration relationship between the feature data; The risk control test system configures corresponding global interception conditions according to the interface information; The real-time risk control system verifies the business request according to the configured global interception conditions.
3. The risk control analysis method according to claim 2, characterized in that: The step of the real-time risk control system verifying the business request according to the configured global interception condition includes: The real-time risk control system verifies the characteristic data in the business request according to the interface information in the configured global interception condition: When the service request includes all the necessary feature data in the global interception condition and there is no problem in the enumeration relationship between the feature data in the service request, the service request passes the verification and the verification result is fed back to the user terminal; Otherwise, the service request fails the verification, and the verification result is fed back to the user terminal, and problem information is generated at the same time.
4. The risk control analysis method according to claim 1, characterized in that: The feature testing system analyzes and determines the problem information according to the configured notification conditions to generate a missing analysis result, including: The risk control test system configures notification conditions based on preset interface problems; The feature testing system judges the problem information according to the configured notification conditions: When the problem information belongs to the preset interface problem, the risk control analysis process ends; Otherwise, a missing analysis is performed on the problem information, a missing analysis result is generated, and notification information is generated.
5. The risk control analysis method according to claim 4, characterized in that: The steps of the risk control testing system creating a problem follow-up form according to the missing information and processing the problem follow-up form to complete the risk control analysis of the business request include: The risk control test system creates a problem follow-up form according to the missing information, and determines the problem of the corresponding problem follow-up form according to the notification information: When the issue in the issue follow-up form is invalid, the risk control analysis process ends; When the problem follow-up form needs to be deferred for processing, the problem follow-up form is processed after the deferred time reaches a preset time; When the problem follow-up form needs to be processed, the problem in the problem follow-up form is judged: When the problem in the problem follow-up form does not need to be modified, the problem follow-up form is fed back to the user end, and the user end modifies the service request according to the problem follow-up form and generates a new service request; When the issue in the issue follow-up form is invalid, the risk control analysis process ends; When the problem in the problem follow-up sheet is an interface document error or a program error, it is repaired to complete the risk control analysis of the business request.
6. The risk control analysis method according to claim 5, characterized in that: When the problem follow-up form needs to be deferred for processing, after the deferred time reaches a preset time, the step of processing the problem follow-up form includes: After the extension period reaches the preset period, the risk control test system is used to determine whether the issue of the issue follow-up order is an invalid issue: If yes, then the risk control analysis process ends; Otherwise, the issue follow-up sheet will be processed.
7. The risk control analysis method according to claim 5, characterized in that: When the problem in the problem follow-up form is an interface document error or a program error, the step of repairing it to complete the risk control analysis of the business request includes: When the problem in the problem follow-up form is an interface document error or a program error, a corresponding problem rectification form is created, and the interface document error or program error is repaired according to the problem rectification form until the repair is completed, so as to complete the risk control analysis of the business request.
8. A risk control analysis device, characterized in that: include: A service verification module is used to respond to a service request from a user terminal, verify the service request through the global interception condition configured by the real-time risk control system, and if the service request fails to pass the verification, feedback the verification result to the user terminal and generate problem information; wherein the service request includes at least one feature data, and the problem information includes the feature data with the problem; An analysis and judgment module, used to analyze and judge the problem information through the notification conditions configured by the feature test system to generate a missing analysis result; a result analysis module, configured to analyze the business request according to the deficiency analysis result through the risk control test system to generate deficiency information; and A result processing module is used to create a problem follow-up form according to the missing information through the risk control testing system, and process the problem follow-up form to complete the risk control analysis of the business request.
9. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the computer program, the steps of the risk control analysis method according to any one of claims 1 to 7 are implemented.
10. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the steps of the risk control analysis method according to any one of claims 1 to 7 are implemented.