Risk verification method, system and equipment for staged business and medium

Abstract

The invention relates to the technical field of data processing, in particular to a risk verification method, system and device for installment business and a medium, and aims to solve the problem that information of a user during installment cannot be audited due to overdue repayment of the user and the like. The method comprises the steps of receiving a request of a user for applying for an installment service, and determining a target verification stage based on application information; if the target verification stage is the first stage, determining that the verification strategy indication response is successful, and sending a constructed first response message to the corresponding channel through the application request; if the target verification stage is a second stage, determining that the verification strategy indication only stores the application information, storing the application information, and sending a constructed first response message to a corresponding channel through the application request; and if the target verification stage is a third stage, determining a verification strategy to indicate to execute verification, performing verification based on a verification rule and verification data, storing the application information, the verification data and a verification result, and sending a constructed second response message to a corresponding channel.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a risk verification method, system, device and medium for installment business. Background Technology

[0002] In today's highly digitalized consumer ecosystem, users have a wide variety of convenient channels for processing installment payments. For example, users can process installment payments through e-commerce platform checkout pages, brand official online stores, online banks, and other channels, thereby greatly improving user convenience and shopping experience.

[0003] Currently, when processing installment payment services for users, numerous risk verifications are required, such as verifying the user's credit history, the authenticity of the user's identity, consumption behavior preferences, repayment ability, and debt level, in order to ensure that the risks of installment payment services are controllable.

[0004] If the risk verification passes, the installment payment plan is processed directly for the user. However, due to incomplete data storage, if a user later defaults on payments, the user's installment payment information cannot be audited. Summary of the Invention

[0005] This application provides a risk verification method, system, device, and medium for installment payment transactions to address the problem of being unable to audit a user's installment payment information when situations such as user repayment defaults occur later. The specific implementation scheme is as follows: Firstly, this application provides a risk verification method for installment payment business, the method comprising: In response to receiving a user's application request, a target verification stage is determined based on the application information in the application request; wherein, the application request is the user's request to apply for installment payment services; the application information includes the corresponding channel, installment type, and application time of the application request; the verification stages corresponding to different installment types for each channel include a first stage, a second stage, and a third stage; the time of the first stage is earlier than the time of the second stage, and the time of the second stage is earlier than the time of the third stage; If the target verification stage is the first stage, then if the verification strategy corresponding to the application request indicates a direct successful response, the application request is directly approved, and a first response message is constructed and sent to the corresponding channel; wherein, the first response message indicates that the application request is approved; or If the target verification stage is the second stage, and the verification strategy indicates that only application information should be saved, then the application information is saved, and the first response message is constructed directly through the application request and sent to the corresponding channel; or If the target verification stage is the third stage, then the verification strategy is determined to instruct the verification to be performed. Based on the verification rules and verification data, the user is verified to obtain the verification result. The application information, the verification data, and the verification result are saved. A second response message is constructed and sent to the corresponding channel. The second response message contains the verification result.

[0006] Through the above application embodiments, since the verification stages corresponding to the installment business of different installment types for each channel include a first stage, a second stage, and a third stage, the target verification stage of the application request can be determined based on the corresponding channel, installment type, and application time included in the application information. Then, when the target verification stage is the first stage, the verification strategy is determined to be a strategy that directly responds to success. Since the first stage is the earliest stage in the verification process, for example, in the initial production stage of the corresponding installment business of the channel, directly responding to the user's application request helps decouple the timing of channel production. When the target verification stage is the second stage, the verification strategy is determined to be a strategy that only saves the application information, thereby providing data support for verifying the compliance of each verification rule. Only when the target verification stage is the third stage is the verification strategy determined to be a strategy that instructs the execution of verification. Furthermore, based on the specific content of the verification strategy, the operation of directly approving the application request or performing verification is determined. This avoids the abnormality of installment business caused by excessively high or low verification pass rates, ensuring the accuracy and rationality of risk verification for installment business. Through different verification strategies, the risk verification method for installment business can be more smoothly deployed.

[0007] Subsequently, upon receiving a user's installment payment application, a verification strategy is used to determine whether to verify the user. Verification is only performed based on the verification rules and data when the strategy instructs it to do so. Simultaneously, the verification results, verification data, and application information from the application request are saved. This allows for subsequent auditing of the user's installment payment application using the application information, verification data, and verification results. This ensures the data required for future audits and solves the problem of being unable to audit the user's installment payment information in cases of late payments or other issues. It also enables risk verification of user-submitted installment payment applications and further ensures the rationality and accuracy of risk verification. For example, in the event of bad debt, the saved application information, verification data, and verification results can be used to verify whether the installment payment application met the requirements and whether the bad debt was caused by the installment payment. Regardless of whether the verification result indicates success or failure, the verification result, verification data, and application information are all saved. This allows for subsequent auditing of the reasonableness and accuracy of the verification result when it indicates failure, and also enables precise identification of the user even after a failure, preventing issues with subsequent remarketing. Furthermore, the construction and transmission of the first and second response messages allow the corresponding channel requesting the application to know whether the risk verification for the installment plan has passed, thus determining whether to process the corresponding installment plan for the user, further refining the risk verification method for installment plans.

[0008] Secondly, this application also provides a risk verification system for installment payment business, the system comprising: The acquisition module is used to respond to receiving a user's application request and determine the target verification stage based on the application information in the application request; wherein, the application request is the user's request to apply for installment payment services; the application information includes the corresponding channel, installment type, and application time of the application request; the verification stages corresponding to the installment services of different installment types for each channel include a first stage, a second stage, and a third stage; the time of the first stage is earlier than the time of the second stage, and the time of the second stage is earlier than the time of the third stage; The processing module is configured to, if the target verification stage is the first stage, determine that the verification policy corresponding to the application request indicates a direct successful response, then directly approve the application request, construct a first response message, and send the first response message to the corresponding channel; wherein the first response message indicates that the application request is approved; or If the target verification stage is the second stage, and the verification strategy indicates that only application information should be saved, then the application information is saved, and the first response message is constructed directly through the application request and sent to the corresponding channel; or If the target verification stage is the third stage, then the verification strategy is determined to instruct the verification to be performed. Based on the verification rules and verification data, the user is verified to obtain the verification result. The application information, the verification data, and the verification result are saved. A second response message is constructed and sent to the corresponding channel. The second response message contains the verification result.

[0009] Thirdly, this application provides an electronic device, comprising: Memory, used to store program instructions; A processor is configured to invoke program instructions stored in the memory and execute the steps of the method described in any one of the first aspects according to the obtained program instructions.

[0010] Fourthly, this application provides a computer-readable storage medium storing a computer program, the computer program including program instructions, which, when executed by a computer, cause the computer to perform the method described in any one of the first aspects.

[0011] Fifthly, this application provides a computer program product comprising: computer program code, which, when run on a computer, causes the computer to perform the method described in any one of the first aspects. Attached Figure Description

[0012] Figure 1 A flowchart illustrating a risk verification method for installment payment services provided in this application embodiment; Figure 2 A schematic diagram illustrating the channel-based risk verification method provided in this application embodiment; Figure 3 A schematic diagram of a risk verification system for installment payment services provided in this application embodiment; Figure 4 This is a schematic diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0013] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application. Unless otherwise specified, the embodiments and features in the embodiments of this application can be arbitrarily combined with each other. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than that shown here.

[0014] The terms "first" and "second" in the specification, claims, and accompanying drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the term "comprising" and any variations thereof are intended to cover non-exclusive protection. For example, a process, method, system, product, or device that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or devices. The term "multiple" in this application can mean at least two, for example, two, three, or more, and the embodiments of this application do not impose limitations.

[0015] The following description, in conjunction with the accompanying drawings, illustrates exemplary embodiments of this application, including various details to aid understanding. These embodiments should be considered merely exemplary. Therefore, those skilled in the art should recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope of this application. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description. It should be noted that in the embodiments of this application, certain existing industry solutions such as software, components, and models may be mentioned. These should be considered exemplary, intended only to illustrate the feasibility of implementing the technical solutions of this application, and do not imply that the applicant has already used or necessarily used such solutions.

[0016] The acquisition, transmission, storage, and use of data in this application all comply with the requirements of relevant national laws and regulations.

[0017] The embodiments of this application will now be described in detail with reference to the accompanying drawings.

[0018] In today's highly digitalized consumer ecosystem, users have a wide variety of convenient channels for processing installment payments. For example, users can process installment payments through e-commerce platform checkout pages, brand official online stores, online banks, and other channels, thereby greatly improving user convenience and shopping experience.

[0019] Currently, when processing installment payment services for users, numerous risk verifications are required, such as verifying the user's credit history, the authenticity of the user's identity, consumption behavior preferences, repayment ability, and debt level, in order to ensure that the risks of installment payment services are controllable.

[0020] If the risk verification fails, the installment payment plan will be refused to the user, and the user will be notified. However, since the user's information no longer exists in the system after the verification fails, the user cannot be found later. Consequently, even if the user's information is updated and the verification passes, it will be impossible to conduct remarketing to that user.

[0021] If the risk verification result is passed, installment payment will be processed directly for the user. However, due to incomplete data storage, if the user defaults on payments later, the user's installment payment information cannot be audited.

[0022] Therefore, this application proposes a risk verification method for installment payment services, which can be applied to a risk verification system. The verification stages for different installment types across each channel include a first stage, a second stage, and a third stage. The first stage begins earlier than the second stage, and the second stage begins earlier than the third stage. Furthermore, the verification strategies differ for each stage. Based on the specific content of the verification strategy, the method determines whether to directly approve the application request or proceed with verification, thus avoiding abnormal installment payment processes caused by excessively high or low approval rates. This ensures the accuracy and rationality of the risk verification for installment payment services. Upon receiving a user's application request for installment payment services, the target verification stage is first determined based on the application information. When the target verification stage is the first stage, the verification strategy instructs direct approval of the application request. A first response message instructing the approval of the application request is then constructed and sent to the corresponding channel, allowing the channel to be aware that the user's application request has been approved and thus process the installment payment for the user.

[0023] When the target verification stage is the second stage, it can be determined that the verification strategy indicates that only the application information is saved. This application information is saved so that the compliance of the set verification rules can be verified in advance based on the application information. This further ensures the rationality and accuracy of the risk verification of the installment business. The constructed first response message is sent to the corresponding channel so that the corresponding channel knows that the user's application request has been approved, so as to process the installment business for the user.

[0024] When the target verification stage reaches the third stage, the verification strategy can be determined to execute the verification. Only then, based on the verification rules and data, is the user verified. Simultaneously, the verification results, verification data, and application information are saved. This allows for subsequent auditing of the user's installment payment business using the application information, verification data, and verification results, providing data support for subsequent audits. This solves the problem of being unable to audit the user's installment payment information when situations such as user repayment delinquency occur later, and achieves risk verification of user-submitted installment payment applications. Regardless of whether the verification result indicates approval or disapproval, the verification results, verification data, and application information are saved. This allows for subsequent auditing of the reasonableness and accuracy of the verification result when the verification result indicates disapproval. Furthermore, since the verification results, verification data, and application information are saved regardless of whether the verification result indicates approval or disapproval, the user's intention to apply for installment payment business is preserved even when the verification result indicates failure. This allows for precise identification of the user, avoiding the problem of being unable to remarket to them later. Furthermore, a second response message containing the verification result is constructed and sent to the corresponding channel that made the application request, so that the corresponding channel can determine whether to process the corresponding installment business for the user based on the verification result.

[0025] Reference Figure 1 The diagram shown is a flowchart of a risk verification method for installment payment services provided in an embodiment of this application. The method includes: S101, in response to receiving the user's application request, determines the target verification stage based on the application information in the application request.

[0026] S102, if the target verification stage is the first stage, then if the verification strategy indicates a direct successful response, then directly pass the application request, construct the first response message, and send the first response message to the corresponding channel.

[0027] S103, if the target verification stage is the second stage, then if the verification strategy indicates that only the application information is to be saved, then the application information is saved, and the first response message is constructed directly through the application request and sent to the corresponding channel.

[0028] S104, if the target verification stage is the third stage, then the verification strategy is determined to perform the verification. Based on the verification rules and verification data, the user is verified, the verification result is obtained, and the application information, verification data and verification result are saved. A second response message is constructed and sent to the corresponding channel.

[0029] Before conducting risk verification, the risk verification system will first receive a user's application request. This application request is for the user to apply for installment payment services.

[0030] The application request may also include application information such as business date, timestamp, data source system number, customer number, credit card number, account number, installment type code, installment date, installment time, number of installments, authorized transaction amount, installment plan number, installment interest rate, and installment handling fee rate. The data source system number indicates the channel, i.e., the customer channel. For example, if the application request originates from mobile banking / Alipay / WeChat, then the data source system number is the corresponding mobile banking / Alipay / WeChat channel number. The installment type code indicates whether the installment service corresponding to the application request is cash installment / consumer installment / bill installment / merchant installment, etc.

[0031] In this application embodiment, different channels can handle installment payment services of different installment types. For example, as shown in Table 1 below.

[0032]

[0033] Table 1

[0034] As shown in Table 1, different installment payment options can be processed through different channels. For example, Channel A can process installment payments for bill installments, consumption installments, and cash installments, while Channel B can only process installment payments for bill installments and cash installments, and Channel D can process installment payments for bill installments, consumption installments, cash installments, and merchant installments.

[0035] Furthermore, in this embodiment of the application, the verification stage corresponding to the installment business of different installment types for each channel may include three stages, such as the first stage, the second stage, and the third stage. Among them, the time of the first stage is earlier than the time of the second stage, and the time of the second stage is earlier than the time of the third stage.

[0036] For example, the initial verification phase of installment billing services on channel A is designated as Phase 1. This initial phase is the first preset duration. Assuming installment billing services on channel A begin operation at time point a1, the first phase spans from time point a1 to time point a2, and the duration from time point a1 to time point a2 is the first preset duration. The verification phase for installment billing services on channel A then extends to Phase 2 from time point a2 to time point a3, and to Phase 3 from time point a3 to time point a4. The duration from time point a2 to time point a3 is the second preset duration, and the duration from time point a3 to time point a4 is the third preset duration. Furthermore, time point a1 precedes time point a2, time point a2 precedes time point a3, and time point a3 precedes time point a4. The first, second, and third preset durations can be the same, different, or partially the same, and can be adjusted according to the specific application scenario.

[0037] Therefore, based on the channel for processing installment payments, the installment type corresponding to the installment payment, and the application time, the target verification stage for verifying the corresponding user before processing the installment payment can be determined.

[0038] Therefore, after receiving a user's application request, the risk verification system can determine the target verification stage corresponding to the application request based on the installment type and application time (such as business hours and timestamp) contained in the application information.

[0039] Furthermore, the risk verification system determines the verification strategy based on this target verification stage.

[0040] In this embodiment, the verification strategy for the first stage can be a strategy that indicates a direct success response, i.e., no user verification is required, and the user's application request is directly approved. The verification strategy for the second stage can be a strategy that indicates only saving the application information, i.e., no user verification is required, the user's application request is directly approved, and the application information in the application request is saved. The verification strategy for the third stage can be a strategy that indicates performing verification, i.e., user verification is required, and then the approval of the user's application request is determined based on the verification result.

[0041] Therefore, when the target verification stage is the first stage, the verification strategy indicates a direct success response. At this time, the risk verification system can directly approve the user's application request without verifying the user. Since the various channels for handling installment business have a time sequence when they are put into production, the user's application request is approved by default in the initial stage of each channel's production (i.e., the first stage). This is to decouple the time sequence of channel production and ensure system performance.

[0042] The risk verification system, based on the verification strategy, can also construct a first response message when directly approving an application request. This first response message indicates that the user's application request has been approved, allowing for a quick determination of the success of the application and thus expediting the final installment payment process for the user.

[0043] Since the installment payment business processed by the user is processed through the corresponding channel, after constructing the first response message, the risk verification system can also send the first response message to the corresponding channel so that the corresponding channel can determine that there is no need to verify the user and can directly process the user's installment payment business.

[0044] In another possible implementation, when the target verification stage is the second stage, the verification strategy is determined to save only the application information. At this time, the risk verification system can directly pass the user's application request and save the application information in the user's application request.

[0045] The risk verification system can use a database to store application information. For example, the application information stored by the risk verification system is shown in Table 2 below.

[0046]

[0047] Table 2

[0048] In Table 2, the first column represents the English name of each piece of information in the application information, i.e., the English name of the field; the second column represents the Chinese name of each piece of information in the application information, i.e., the Chinese name of the field; and the third column represents the identifier code of each piece of information in the application information, i.e., the field identifier code. For example, in Table 2, Cst_ID represents the English name of the customer number in the application information, and 102024 represents the identifier code of that customer number. Therefore, 102024 indicates that it is the customer number in the queried application information.

[0049] Therefore, based on the application information in Table 2, relevant application information when users apply for installment payment services can be obtained at any time, facilitating subsequent auditing to ensure the rationality and accuracy of the installment payment business. Furthermore, based on the saved application information, the compliance of each set verification rule can be verified in advance, thereby assessing the risk of the verification rules.

[0050] For example, for installment billing through channel A, the application information saved for installment billing through channel A is used to perform verification using verification rules and verification data to obtain the corresponding verification result. Based on the verification result, it is determined whether the set verification rules are reasonable.

[0051] For example, first determine the pass rate of installment bill payments for channel A based on the verification results. When the pass rate is not lower than the set threshold, it is determined that the verification rules are set reasonably, and at this time, the set verification rules can continue to be used to verify user application requests.

[0052] When the pass rate is lower than the set threshold, it is determined that the verification rule settings are unreasonable. At this time, the verification rule can be adjusted, and the saved application information can be re-verified according to the adjusted verification rule until the verification pass rate is not lower than the set threshold.

[0053] In this embodiment of the application, there can be multiple verification rules, which can be classified to facilitate better management of the verification rules.

[0054] For example, multiple validation rules can be displayed as an execution rule list, as shown in Table 3 below.

[0055]

[0056] Table 3

[0057] As shown in Table 3, the execution rule list divides multiple verification rules into multiple types, such as: installment type judgment (credit card judgment), hard policy (credit card judgment), scoring policy (BDC strategy platform judgment), People's Bank of China policy (BDC strategy platform judgment), and People's Bank of China policy (credit card judgment).

[0058] The verification rules for installment type determination (credit card determination) can include card product determination, validity period determination, and amount and installment period determination. The card product determination rule indicates whether the card (e.g., credit card) used in the user's requested installment service is a personal card or a corporate card. The validity period determination rule indicates whether the validity period of the card (e.g., credit card) used in the user's requested installment service exceeds the validity period threshold. If the validity period does not exceed the validity period threshold, the sub-verification result of this rule is considered passed; otherwise, the sub-verification result is considered failed. The amount and installment period determination rule indicates whether the amount of the user's requested installment service exceeds the amount threshold and whether the installment period exceeds the installment period threshold. If both the amount and installment period do not exceed the amount threshold and the installment period threshold, the sub-verification result of this rule is considered passed; otherwise, the sub-verification result is considered failed.

[0059] The verification rules corresponding to the hard policy (credit card determination) can include cardholder status and blacklist determination. The cardholder status verification rule indicates whether the user has any blocked cards / accounts / customers. If it is determined that the user does not have any blocked cards / accounts / customers, the sub-verification result of this rule is considered passed; otherwise, it is considered failed. The blacklist determination verification rule indicates whether the user is on a blacklist. If it is determined that the user is not on a blacklist, the sub-verification result of this rule is considered passed; otherwise, it is considered failed.

[0060] The verification rules corresponding to the scoring policy (judged by the BDC strategy platform) can include a fusion score. In this BDC strategy platform, B represents Big, D represents Data, and C represents Cloud. This platform can comprehensively score users based on user information. Therefore, the risk verification system can input user information into the BDC strategy platform, which will then process the information to obtain a fusion score. Subsequently, the risk verification system can determine whether the sub-verification rules corresponding to this verification rule pass based on the comparison between the fusion score and a scoring threshold. For example, if the fusion score is lower than the BDC scoring threshold, the sub-verification result corresponding to this verification rule is determined to fail; only when the fusion score is not lower than the BDC scoring threshold is the sub-verification result corresponding to this verification rule determined to pass.

[0061] The verification rules corresponding to the People's Bank of China (PBOC) policies (judged by the BDC strategy platform) can include historical PBOC reporting policies and historical PBOC push notification policies. The verification rules corresponding to the historical PBOC reporting policies can instruct whether the user's relevant information meets the historical PBOC reporting policy; if the user's relevant information meets the historical PBOC reporting policy, the sub-verification result corresponding to this verification rule is determined to be passed; otherwise, the sub-verification result corresponding to this verification rule is determined to be failed. Similarly, the verification rules corresponding to the historical PBOC push notification policies can instruct whether the user's relevant information meets the historical PBOC push notification policies; if the user's relevant information meets the historical PBOC push notification policies, the sub-verification result corresponding to this verification rule is determined to be failed; otherwise, the sub-verification result corresponding to this verification rule is determined to be passed.

[0062] The verification rules corresponding to the People's Bank of China's policies (credit card assessment) may include customer rating policies. The verification rules corresponding to these customer rating policies indicate the criteria for assessing information such as a user's credit rating. For example, if the verification rule determines that a user's credit rating is excellent, then the sub-verification result corresponding to that rule is passed.

[0063] However, the verification rules in this embodiment are not limited to those shown in Table 3. Multiple different verification rules can be set according to specific application scenarios. Furthermore, the verification rules in this embodiment are not limited to the execution rule list shown in Table 3; they can also be displayed using tree structures, flowcharts, or other methods.

[0064] Furthermore, each verification rule in this embodiment supports on / off control. For example, the risk verification system sets an on / off flag for each verification rule, such as 0 or 1. 0 indicates on; when the flag is on, the verification rule corresponding to that flag is used to verify the user. 1 indicates off; when the flag is off, the verification rule corresponding to that flag is not used to verify the user. Thus, by supporting on / off control settings for verification rules, the use of verification rules can be more flexible, and dynamic switching of verification rules can be achieved, avoiding the use of inappropriate verification rules.

[0065] The on / off flags for the above verification rules can be set according to the priority indicators of the verification rules, or they can be flexibly set according to the specific application scenario, without any specific limitations.

[0066] This priority metric can be determined based on the triggering frequency and resource consumption (such as cost) of the verification rule. For example, the priority metric is the weighted sum of the triggering frequency and resource consumption of the corresponding verification rule. The higher the priority metric, the higher the priority of the verification rule corresponding to the priority metric, meaning that the verification rule is more likely to be used.

[0067] Furthermore, when the verification rules are determined to be unreasonable based on the saved application information and need to be adjusted, the risk verification system can adjust the verification rules according to their priority indicators, thereby saving resources.

[0068] For example, each verification rule is sorted sequentially according to its priority index from highest to lowest. When the verification pass rate falls below the set threshold, the switch for the verification rule with the lowest priority index is first set to "off". Then, based on multiple application information, the adjusted verification rule is used for verification. Based on the verification results, the verification pass rate is re-determined. If the verification pass rate is still below the set threshold, the switch for the verification rule with the lowest priority index among the multiple verification rules with the "on" switch is set to "off", and the readjusted verification rule is used again to verify with the saved application information until the determined verification pass rate is not lower than the set threshold.

[0069] By saving the application information in the second stage, the compliance of each set verification rule can be verified in advance. This avoids abnormal pass rates caused by the strictness or leniency of the set verification rules when using them for verification in the third stage, which would have an adverse impact on the customer.

[0070] In addition, in this embodiment of the application, the application information is not saved in the first stage, but is saved in the second stage. This can avoid the application information occupying too many resources in the first stage, which would prolong the response time of risk verification. In this way, resources can be used reasonably and the response time of risk verification can be reduced.

[0071] Similarly, when the risk verification system saves application information based on the verification strategy, it can also construct a first response message and send the first response message to the corresponding channel of the application request so that the corresponding channel can process the installment business for the user.

[0072] In another possible implementation, when the target verification stage is the third stage, the verification strategy is determined to instruct the verification to be performed. At this time, the risk verification system can verify the user based on the verification rules and verification data to obtain the verification result.

[0073] When the risk verification system verifies a user based on verification rules and verification data, and obtains the verification result, it can first read the execution rule list. Then, it determines whether the corresponding verification data exists in the current database. If it determines that the corresponding verification data does not exist in the current database, it retrieves the verification data and then verifies the user based on the verification rule in the execution rule list and its corresponding verification data to obtain the verification result; otherwise, it directly verifies the user based on the verification rule in the execution rule list and its corresponding verification data to obtain the verification result.

[0074] In one possible implementation, when acquiring verification data, the risk verification system can determine whether verification data for each verification rule in the execution rule list exists in the current database. Subsequently, if the verification data for each verification rule in the execution rule list does not exist in the current database, the system acquires the verification data for each verification rule in the execution rule list, and then verifies the user based on the verification rules in the execution rule list and their corresponding verification data to obtain the verification result.

[0075] If the current database only contains verification data corresponding to some of the verification rules in the execution rule list, then the verification data corresponding to the verification rules for which no verification data exists in the execution rule list is obtained. Then, based on the verification rules in the execution rule list and their corresponding verification data, the user is verified to obtain the verification result.

[0076] If the current database contains verification data corresponding to each verification rule in the execution rule list, then the user is directly verified based on the verification rule in the execution rule list and its corresponding verification data to obtain the verification result.

[0077] When the risk verification system performs risk verification on a user based on the verification rules and their corresponding verification data in the execution rule list, it can perform risk verification on the user based on each verification rule and its corresponding verification data in the execution rule list, or it can perform risk verification on the user based on one or at least two verification rules and their corresponding verification data in the execution rule list. The number of verification rules used for risk verification is not limited and can be adjusted according to the specific application scenario.

[0078] Therefore, when the risk verification system performs risk verification on a user based on the verification rules and their corresponding verification data in the execution rule list, it can first select N target verification rules from the execution rule list according to the switch indicator. Here, N is a positive integer. For example, when the switch indicator of a verification rule is on, that verification rule is selected as the target verification rule. Then, based on the N target verification rules and their corresponding verification data, the user is verified, and the verification result is obtained.

[0079] The risk verification system verifies a user based on N target verification rules and their corresponding verification data. When obtaining the verification result, the system only determines the user's verification result as passed if every single one of the N target verification rules passes. That is, the first verification result indicates that the verification has passed. For example, the first verification result might be that user A's request for installment payment service C has passed verification.

[0080] If any of the N target verification rules fails, the user's verification result is determined to be a failure; that is, the verification result is a second verification result indicating a failure. For example, the second verification result might be that user A's request for installment payment service C failed verification. Therefore, when the risk verification system verifies a user based on the N target verification rules, once it determines that one of the N target verification rules has failed, it can directly determine the verification result as a failure, thereby ending the verification of that user and not continuing to use the unused target verification rules among the N target verification rules.

[0081] In addition, since each verification rule has a priority index, when the risk verification system uses N target verification rules to verify users, it can use the target verification rules in descending order of priority index to verify users, thereby further saving resources.

[0082] In another possible implementation, when acquiring verification data, the risk verification system can first determine the verification rules currently needed in the execution rule list; that is, it can first select N target verification rules from the execution rule list. These target verification rules can be selected based on a switch identifier. Then, the risk verification system determines whether verification data for each of the N target verification rules exists in the current database.

[0083] If there is verification data for each of the N target verification rules in the current database, then the user is directly verified based on the N target verification rules and their corresponding verification data to obtain the verification result.

[0084] Otherwise, only the part of the verification data corresponding to the N target verification rules that does not exist in the database is obtained, and then the user is verified based on the N target verification rules and the verification data corresponding to each of the N target verification rules to obtain the verification result.

[0085] In this embodiment of the application, the aforementioned verification data may include personal company card identification code, credit card primary and supplementary card code, blocking code code, card record blocking code code, account record blocking code code, credit card status, credit card account overdue status type code, customer's maximum overdue status type code, credit card customer blacklist control code, operation priority value, personal legal name, document type code, document number, credit card customer filing date, credit card issuing branch code, special installment card mark, credit card account last due date, credit card permanent credit limit, previous period special consumption transaction amount, bill consumption principal amount, MCC past special control amount, current day credit card bill installment amount, credit card ordinary installment available credit limit, credit card cash installment available credit limit, credit card ordinary installment account available credit limit, credit card ordinary installment amount, credit card customer cumulative number of installment transactions, credit card cumulative installment amount, scoring card score, personal important information reminder code, rule check mark one, rule check mark two, rule check mark three, rule check mark four, installment available credit limit, applied installment credit limit, and other information.

[0086] Since the verification data is obtained from an external source, it can also be called external data.

[0087] In this embodiment of the application, after obtaining the verification data, the risk verification system can also save the verification data. As shown in Table 4 below, the risk verification system can use a database to save the verification data in a data table.

[0088]

[0089] Table 4

[0090] In Table 4, the first column represents the English name of each data point in the verification data, i.e., the English name of the field; the second column represents the Chinese name of each data point in the verification data, i.e., the Chinese name of the field; and the third column represents the identifier code of each data point in the verification data, i.e., the field identifier code. For example, in Table 4, Idv_CorpCrd_IDCd represents the English name of the personal company card identifier code in the verification data, and 145716 represents the identifier code of that personal company card identifier code. Therefore, 145716 indicates that it is the personal company card identifier code in the queried verification data. Thus, based on the verification data in Table 4, the data used for user verification can be obtained at any time for subsequent auditing to ensure the rationality and accuracy of installment payment transactions.

[0091] Similarly, when the risk verification system determines to verify a user based on the verification strategy and verifies the user based on N target verification rules and verification data, it can also construct a second response message. This second response message can include the verification result.

[0092] Furthermore, when the risk verification system determines to verify a user based on the verification strategy and verifies the user based on N target verification rules and verification data, it can also save the application information in the application request. The operation of saving this application information is the same as when the verification strategy instructs that only application information should be saved, and will not be elaborated further here.

[0093] Furthermore, after obtaining the verification result, the risk verification system can also store it. For example, after confirming that the verification has passed, the verification identifier indicating success can be associated with and stored in relation to the installment payment plan ultimately processed by the user. This verification identifier can be associated with a specific type of installment payment plan. For instance, if the user applies for a bill installment plan, the verification identifier will be associated with and stored as a bill installment plan.

[0094] After confirming that the verification failed, the reason for rejection and the verification result can also be stored.

[0095] For example, a risk verification system can use a database to store verification results, as shown in Table 5 below.

[0096]

[0097] Table 5

[0098] In Table 5, the first column represents the English name of the relevant information in the verification result, i.e., the English name of the field; the second column represents the Chinese name of the relevant information in the verification result, i.e., the Chinese name of the field; and the third column represents the identifier code of the relevant information in the verification result, i.e., the field identifier code. For example, in Table 5, PreEx_Btch_Ind represents the English name of the pre-approval flag in the relevant information of the verification result, and 146820 represents the identifier code of the pre-approval flag. Thus, 146820 indicates that it is the pre-approval flag of the queried verification result. This pre-approval flag can be 0 or 1. 0 indicates approval and 1 indicates disapproval; or 0 indicates disapproval and 1 indicates approval. The meaning of 0 and 1 in the pre-approval flag can be adjusted according to the specific application scenario. When the pre-approval flag indicates disapproval, the reason for disapproval can be displayed to the user through the first-level rejection reason description and the second-level rejection reason description, so that the user understands why the installment business was rejected.

[0099] Therefore, based on the verification results in Table 5, relevant information about the verification results after user verification can be obtained at any time, which will facilitate subsequent auditing to ensure the rationality and accuracy of installment payment business.

[0100] Furthermore, by storing verification results, verification data, and application information in the application request, it enables the backtracking of successful installment data and the statistics of failed installment data. This solves the problem of not being able to audit the user's installment information when the user defaults on repayments, and also solves the problem of not being able to conduct secondary marketing to rejected customers.

[0101] In addition, the risk verification method in this embodiment can be separated from the channels for handling installment business, so that each channel can directly obtain the verification result of the user's application request from the risk verification system when handling installment business, and directly determine whether to process the installment business for the user based on the obtained verification result. This reduces the specific verification steps of risk verification for the channels handling installment business, thereby reducing the response time of installment business and improving the efficiency of installment business processing.

[0102] Therefore, after obtaining the verification result, the risk verification system can also send a second response message containing the verification result to the corresponding channel of the application request, so that the user can be processed for installment payment or the installment payment can be refused through the corresponding channel.

[0103] Specifically, when the verification result is a first verification result indicating that the verification has passed, the risk verification system can send a second response message to the corresponding channel of the application request. This second response message contains the verification result of the first verification result, thereby enabling the corresponding channel to process the installment payment service corresponding to the user's application request. The second response message can also be a token indicating that the verification for the application request has passed.

[0104] When the verification result is a second verification result indicating that the verification failed, the risk verification system can send a second response message to the corresponding channel of the application request. The second response message contains the second verification result and may also include the reason for the failure of the application request (i.e. the reason for rejection), so that the corresponding channel can show the user the reason why their application for installment payment was rejected.

[0105] For example, channel A needs to process bill installment payments for user 1, and channel B needs to process bill installment payments for user 2. The risk verification system verifies the application requests from user 1 and user 2 respectively, and obtains the verification results. Then, channel A and channel B directly obtain the verification results from the risk verification system.

[0106] Assuming User 1's verification passes, the risk verification system sends a token to Channel A indicating that User 1's application request has been verified. Upon receiving this token, Channel A can directly process the bill installment plan for the user.

[0107] User 2's verification failed, and the risk verification system sent a rejection reason to Channel B indicating that User 2's application request verification failed. After receiving the rejection reason sent by the risk verification system, Channel B can directly refuse to process the bill installment plan for User 2 and display the rejection reason to User 2.

[0108] Therefore, each channel can directly obtain the verification results of relevant users from the risk verification system to determine whether to process installment payments. This reduces the specific verification steps for each channel and allows for more efficient use of computing resources when processing installment payments, thereby reducing response time and improving processing efficiency. Furthermore, by using a separate risk verification system to verify users before processing installment payments through the appropriate channel, and by using two independent modules for risk verification and processing, the management of installment payments becomes more controllable, thus achieving efficient risk control.

[0109] Furthermore, after the risk verification system fails the initial verification, it can audit the second verification result to determine whether the second verification result is reasonable. That is, it audits the reasonableness of refusing a user's installment payment application and can save relevant audit information. The saved audit information is shown in Table 6 below.

[0110]

[0111] Table 6

[0112] In Table 6, the first column represents the English name of the audit-related information, i.e., the English name of the field; the second column represents the Chinese name of the audit-related information, i.e., the Chinese name of the field; and the third column represents the identifier code of the audit-related information, i.e., the field identifier code. For example, in Table 6, ApRlt_Ind represents the English name of the approval result flag in the audit-related information, and 113529 represents the identifier code of the approval result flag. Therefore, 113529 indicates that it is the approval result flag of the audit-related information being queried.

[0113] Therefore, based on the audit-related information in Table 6, relevant information on user audits can be obtained at any time, allowing for a clear and intuitive understanding of the rationality and accuracy of the verification results. Furthermore, audit-related information can be obtained at any time to facilitate audit verification.

[0114] In addition, in this embodiment of the application, the risk verification system may also use the transaction design shown in Table 7 below to obtain various information.

[0115]

[0116] Table 7

[0117] In Table 7, the first column represents the interface number. Through the interface corresponding to this number, a specific operation can be performed to obtain the relevant information. The second column represents the interface function. For example, the interface corresponding to A0281P077 represents a general installment information query, i.e., how to obtain verification data. Therefore, verification data can be obtained through the interface corresponding to A0281P077. As another example, the interface corresponding to A06734101 represents pre-approval before installment payments - general information, used to obtain verification results. Therefore, the verification results can be obtained through this interface.

[0118] In addition, different methods can be used for verification for customer channels and employee channels.

[0119] For example, such as Figure 2As shown, for customer channels, users first apply for installment verification, and then the risk verification system verifies the user using the aforementioned risk verification method. If the verification is successful, the user directly applies for installment payment; if the verification fails, the installment payment transaction ends.

[0120] For employee channels, employees can query and audit the verification data to determine whether the risk verification conducted when processing installment transactions is reasonable.

[0121] Based on the same inventive concept, this application also provides a risk verification system for installment payment business, such as... Figure 3 The diagram shown is a structural schematic of a risk verification system for installment business provided in this application. The system includes: The acquisition module 301 is used to respond to receiving a user's application request and determine the target verification stage based on the application information in the application request; wherein, the application request is the user's request to apply for installment payment services; the application information includes the corresponding channel, installment type, and application time of the application request; the verification stages corresponding to the installment services of different installment types for each channel include a first stage, a second stage, and a third stage; the time of the first stage is earlier than the time of the second stage, and the time of the second stage is earlier than the time of the third stage; Processing module 302 is configured to, if the target verification stage is the first stage, determine that the verification strategy corresponding to the application request indicates a direct successful response, then directly approve the application request, construct a first response message, and send the first response message to the corresponding channel; wherein the first response message indicates that the application request is approved; or If the target verification stage is the second stage, and the verification strategy indicates that only application information should be saved, then the application information is saved, and the first response message is constructed directly through the application request and sent to the corresponding channel; or If the target verification stage is the third stage, then the verification strategy is determined to instruct the verification to be performed. Based on the verification rules and verification data, the user is verified to obtain the verification result. The application information, the verification data, and the verification result are saved. A second response message is constructed and sent to the corresponding channel. The second response message contains the verification result.

[0122] In one possible implementation, when the processing module 302 verifies the user based on verification rules and verification data to obtain a verification result, it specifically reads the execution rule list; determines whether verification data corresponding to N target verification rules in the execution rule list exists in the database; where N is a positive integer; if not, it obtains the verification data and verifies the user based on the N target verification rules and the verification data to obtain the verification result; if yes, it directly verifies the user based on the N target verification rules and the verification data to obtain the verification result.

[0123] In one possible implementation, the verification result is either a first verification result or a second verification result, where the first verification result indicates that the verification passed and the second verification result indicates that the verification failed. Specifically, when the processing module 302 verifies the user based on the verification rules and verification data to obtain a verification result, it verifies the user based on the N target verification rules and the verification data. If all N target verification rules pass the verification, the first verification result is obtained; if any one of the N target verification rules fails the verification, the second verification result is obtained.

[0124] In one possible implementation, each verification rule in the execution rule list supports on / off control.

[0125] In one possible implementation, the processing module 302 is further configured to, after obtaining the verification result, associate and store the verification identifier indicating that the verification has passed with the installment service processed by the user when the verification result is a first verification result indicating that the verification has passed; or, when the verification result is a second verification result indicating that the verification has failed, audit the second verification result and save the audit information.

[0126] In one possible implementation, when the verification result is a second verification result indicating that the verification failed, the processing module 302 further includes a rejection reason in the second response message; wherein the rejection reason is the reason why the verification of the application request failed.

[0127] Based on the same inventive concept, this application also provides an electronic device that can realize the function of the aforementioned risk verification system for installment business. (Refer to...) Figure 4 The aforementioned electronic devices include: At least one processor 401 and a memory 402 connected to at least one processor 401. In this embodiment, the specific connection medium between the processor 401 and the memory 402 is not limited. Figure 4The example shown is the connection between processor 401 and memory 402 via bus 400. Bus 400 is... Figure 4 The connections between other components are indicated by thick lines and are for illustrative purposes only, not as limiting information. The 400 bus can be divided into address bus, data bus, control bus, etc., for ease of representation. Figure 4 The term is represented by a single thick line, but this does not imply that there is only one bus or one type of bus. Alternatively, processor 401 can also be called a controller; there is no restriction on the name.

[0128] In this embodiment, the memory 402 stores instructions executable by at least one processor 401. By executing the instructions stored in the memory 402, the at least one processor 401 can perform the risk verification method for installment payments discussed above. The processor 401 can implement... Figure 3 The system shown illustrates the functions of each module.

[0129] The processor 401 is the control center of the system. It can connect to various parts of the control device through various interfaces and lines. By running or executing instructions stored in memory 402 and calling data stored in memory 402, the system can perform various functions and process data, thereby monitoring the system as a whole.

[0130] In one possible design, processor 401 may include one or more processing units. Processor 401 may integrate an application processor and a modem processor, wherein the application processor mainly handles the operating system, user interface, and applications, and the modem processor mainly handles wireless communication. It is understood that the modem processor may also not be integrated into processor 401. In some embodiments, processor 401 and memory 402 may be implemented on the same chip; in some embodiments, they may also be implemented separately on separate chips.

[0131] Processor 401 can be a general-purpose processor, such as a central processing unit (CPU), digital signal processor, application-specific integrated circuit, field-programmable gate array or other programmable logic device, discrete gate or transistor logic device, or discrete hardware component, capable of implementing or executing the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the risk verification method for installment services disclosed in the embodiments of this application can be directly manifested as execution by a hardware processor, or execution by a combination of hardware and software modules within the processor.

[0132] Memory 402, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs, non-volatile computer-executable programs, and modules. Memory 402 may include at least one type of storage medium, such as flash memory, hard disk, multimedia card, card-type memory, random access memory (RAM), static random access memory (SRAM), programmable read-only memory (PROM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), magnetic memory, magnetic disk, optical disk, etc. Memory 402 can be any other medium capable of carrying or storing desired program code in the form of instructions or data structures that can be accessed by a computer, but is not limited thereto. In the embodiments of this application, memory 402 can also be a circuit or any other device capable of implementing storage functions for storing program instructions and / or data.

[0133] By designing and programming the processor 401, the code corresponding to the risk verification method for installment business described in the foregoing embodiments can be embedded into the chip, thereby enabling the chip to execute the code during operation. Figure 1 The steps of the risk verification method for installment business in the illustrated embodiment are as follows. How to design and program the processor 401 is a technique well-known to those skilled in the art and will not be described further here.

[0134] Based on the same inventive concept, embodiments of this application provide a computer-readable storage medium. The computer program product includes computer program code, which, when executed on a computer, causes the computer to perform any of the installment payment risk verification methods discussed above. Since the principle by which the above-described computer-readable storage medium solves the problem is similar to that of the installment payment risk verification method, the implementation of the above-described computer-readable storage medium can be found in the implementation of the method; repeated details will not be elaborated further.

[0135] Based on the same inventive concept, this application also provides a computer program product, which includes computer program code. When the computer program code is run on a computer, it causes the computer to execute any of the installment business risk verification methods discussed above. Since the principle of the above computer program product in solving the problem is similar to that of the installment business risk verification method, the implementation of the above computer program product can refer to the implementation of the method, and the repeated parts will not be described again.

[0136] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0137] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0138] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0139] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of user-operated steps to be executed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0140] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A risk verification method for installment payment business, characterized in that, include: In response to receiving a user's application request, a target verification stage is determined based on the application information in the application request; wherein, the application request is the user's request to apply for installment payment services; the application information includes the corresponding channel, installment type, and application time of the application request; the verification stages corresponding to different installment types for each channel include a first stage, a second stage, and a third stage; the time of the first stage is earlier than the time of the second stage, and the time of the second stage is earlier than the time of the third stage; If the target verification stage is the first stage, then if the verification strategy corresponding to the application request indicates a direct successful response, the application request is directly approved, and a first response message is constructed and sent to the corresponding channel; wherein, the first response message indicates that the application request is approved; or If the target verification stage is the second stage, and the verification strategy indicates that only application information should be saved, then the application information is saved, and the first response message is constructed directly through the application request and sent to the corresponding channel; or If the target verification stage is the third stage, then the verification strategy is determined to instruct the verification to be performed. Based on the verification rules and verification data, the user is verified to obtain the verification result. The application information, the verification data, and the verification result are saved. A second response message is constructed and sent to the corresponding channel. The second response message contains the verification result.

2. The method as described in claim 1, characterized in that, The process of verifying the user based on verification rules and verification data to obtain verification results includes: Read the list of execution rules; Determine whether the database contains verification data corresponding to the N target verification rules in the execution rule list; where N is a positive integer; If not, obtain the verification data, and verify the user based on the N target verification rules and the verification data to obtain the verification result; If so, the user is directly verified based on the N target verification rules and the verification data to obtain the verification result.

3. The method as described in claim 2, characterized in that, The verification result is either a first verification result or a second verification result, where the first verification result indicates that the verification passed and the second verification result indicates that the verification failed. The process of verifying the user based on the verification rules and verification data to obtain the verification result includes: The user is verified based on the N target verification rules and the verification data; If all N target verification rules pass the verification, the first verification result is obtained; If any of the N target verification rules fails verification, then the second verification result is obtained.

4. The method according to any one of claims 2-3, characterized in that, Each verification rule in the execution rule list supports on / off control.

5. The method according to any one of claims 1-3, characterized in that, After obtaining the verification result, the following is also included: When the verification result is a first verification result indicating that the verification has passed, the verification identifier indicating that the verification has passed is associated with and stored with the installment payment service processed by the user; or When the verification result is a second verification result indicating that the verification failed, the second verification result is audited and the audit information is saved.

6. The method according to any one of claims 1-3, characterized in that, The method further includes: When the verification result is a second verification result indicating that the verification failed, the second response message also includes a rejection reason; wherein, the rejection reason is the reason why the verification of the application request failed.

7. A risk verification system for installment payment business, characterized in that, include: The acquisition module is used to respond to receiving a user's application request and determine the target verification stage based on the application information in the application request; wherein, the application request is the user's request to apply for installment payment services; the application information includes the corresponding channel, installment type, and application time of the application request; the verification stages corresponding to the installment services of different installment types for each channel include a first stage, a second stage, and a third stage; the time of the first stage is earlier than the time of the second stage, and the time of the second stage is earlier than the time of the third stage; The processing module is configured to, if the target verification stage is the first stage, determine that the verification policy corresponding to the application request indicates a direct successful response, then directly approve the application request, construct a first response message, and send the first response message to the corresponding channel; wherein the first response message indicates that the application request is approved; or If the target verification stage is the second stage, and the verification strategy indicates that only application information should be saved, then the application information is saved, and the first response message is constructed directly through the application request and sent to the corresponding channel; or If the target verification stage is the third stage, then the verification strategy is determined to instruct the verification to be performed. Based on the verification rules and verification data, the user is verified to obtain the verification result. The application information, the verification data, and the verification result are saved. A second response message is constructed and sent to the corresponding channel. The second response message contains the verification result.

8. The system as described in claim 7, characterized in that, When the processing module verifies the user based on verification rules and verification data to obtain a verification result, it specifically reads the execution rule list; determines whether verification data corresponding to N target verification rules in the execution rule list exists in the database; where N is a positive integer; if not, it obtains the verification data and verifies the user based on the N target verification rules and the verification data to obtain the verification result; if yes, it directly verifies the user based on the N target verification rules and the verification data to obtain the verification result.

9. The system as described in claim 8, characterized in that, The verification result is either a first verification result or a second verification result. The first verification result indicates that the verification passed, and the second verification result indicates that the verification failed. When the processing module verifies the user based on the verification rules and verification data to obtain the verification result, it is specifically used to verify the user based on the N target verification rules and the verification data. If all N target verification rules pass the verification, the first verification result is obtained. If any of the N target verification rules fails verification, then the second verification result is obtained.

10. The system as described in any one of claims 8-9, characterized in that, Each verification rule in the execution rule list supports on / off control.

11. The system as described in any one of claims 7-9, characterized in that, The processing module is further configured to, after obtaining the verification result, associate and store the verification identifier indicating that the verification has passed with the installment payment business processed by the user when the verification result is a first verification result indicating that the verification has passed; or, when the verification result is a second verification result indicating that the verification has failed, audit the second verification result and save the audit information.

12. The system as described in any one of claims 7-9, characterized in that, When the verification result is a second verification result indicating that the verification failed, the second response message also includes a rejection reason; wherein, the rejection reason is the reason why the verification of the application request failed.

13. An electronic device, characterized in that, include: Memory, used to store program instructions; A processor is configured to invoke program instructions stored in the memory and execute the method of any one of claims 1-6 according to the obtained program instructions.

14. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, the computer program including program instructions that, when executed by a computer, cause the computer to perform the method as described in any one of claims 1-6.

15. A computer program product, characterized in that, The computer program product includes: computer program code, which, when run on a computer, causes the computer to perform the method as described in any one of claims 1-6.

Images