Risk control method and program product

Abstract

This disclosure provides a risk control method and program product. The method includes: acquiring status data of a target merchant; determining the target merchant level based on the status data; determining target risk control rules associated with the target merchant level based on the correlation between the merchant level and risk control rules; and performing risk control on the target merchant based on the target risk control rules. This solution, by establishing a mapping mechanism between merchant levels and risk control rules, can automatically adjust the merchant level based on merchant information and execute risk control rules corresponding to the level. It configures and stores personalized risk control rules for specific merchants, achieving refined risk control based on the merchant's risk status, thereby improving the targeting of risk control measures and the system's adaptability.

Description

Technical Field

[0001] This disclosure relates to the field of risk control technology, specifically to a risk control method and procedure product. Background Technology

[0002] In the field of risk control technology, especially in the risk identification and handling aspects of transaction processing, how to build a risk strategy system that can flexibly and quickly respond to business changes is a common pursuit in the industry.

[0003] In related technologies, common risk control systems typically rely on a pre-defined, relatively fixed set of risk control rules. While these rules allow for adjustments to some threshold parameters, their core logic and judgment conditions are pre-defined in the system code. When faced with new risk patterns or business scenarios, if risk control personnel need to add or modify rule logic, developers must intervene, modifying the system source code and redeploying it. Under this architecture, risk control rules are essentially static and universal, making it difficult to adapt them to the real-time risk status of different merchants.

[0004] Therefore, the risk control mechanism based on the aforementioned static rule architecture has inherent limitations: on the one hand, due to the lack of dynamic assessment and stratification capabilities for individual merchant risk status, risk control rules are difficult to apply precisely and differentiatedly to match the specific risk levels of merchants, resulting in inaccurate risk control; on the other hand, rule updates and iterations heavily rely on development resources, resulting in lengthy processes and difficulty in quickly responding to rapidly changing market risks and business needs. With the increasing complexity of payment, finance, and other business scenarios and the ever-increasing demands for risk control agility, overcoming the insufficient accuracy and limited flexibility of existing static risk control models has become a pressing technical challenge in this field. Summary of the Invention

[0005] This disclosure provides a risk control method, an electronic device, a storage medium, and a program product.

[0006] Firstly, this disclosure provides a risk control method, which includes: Obtain the status data of the target merchant; Based on the status data, the target merchant level of the target merchant is determined; Based on the relationship between merchant level and risk control rules, determine the target risk control rules associated with the target merchant level; Risk control is carried out on the target merchant based on the target risk control rules.

[0007] Optionally, determining the target merchant level of the target merchant based on the status data includes: Based on preset trigger conditions that are based on merchant attribute data and / or merchant behavior data, the target merchant level of the target merchant is automatically and dynamically evaluated and adjusted.

[0008] Optionally, the method further includes: In response to manual instructions from risk control personnel, the target merchant level of the target merchant is adjusted.

[0009] Optionally, the risk control of the target merchant based on the target risk control rules includes: If the target risk control rule is met, risk restriction measures corresponding to the target risk control rule shall be implemented.

[0010] Optionally, the method further includes: Provides multiple predefined, configurable rule condition units; Receive user configuration instructions, the user configuration instructions including at least one rule condition unit selected from the plurality of predefined configurable rule condition units and a logical operator; In response to the user configuration instruction, the selected at least one rule condition unit is combined using the logical operator to generate an executable risk control rule.

[0011] Optionally, the user configuration instructions may further include the effective scope and effective nodes configured for the risk control rules; the effective scope includes merchant level and product type, and the effective nodes include merchant registration, before transaction, after transaction, and before disbursement.

[0012] Optionally, the user configuration instruction further includes configuring a release condition for the risk control rule, and the method further includes: When implementing risk restriction measures corresponding to the target risk control rule, the risk restriction measures are lifted in response to the target merchant meeting the lifting conditions.

[0013] Optionally, the status data includes merchant attribute data and / or merchant behavior data; the merchant attribute data includes merchant type, merchant network access duration, and merchant authentication status; the merchant behavior data includes the merchant's transaction volume within a preset time period, the number of transaction users within a preset time period, and the transaction-to-loan ratio within a preset time period.

[0014] Optionally, the method further includes: Configure and store personalized risk control rules for specific merchants; The step of determining the target risk control rule associated with the target merchant level includes: if the target merchant is the specific merchant, then determining the personalized risk control rule as the target risk control rule.

[0015] Secondly, this disclosure provides an electronic device, including: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores at least one computer program that can be executed by the at least one processor, the at least one computer program being executed by the at least one processor to enable the at least one processor to perform the risk control method as described in the first aspect.

[0016] Thirdly, embodiments of this disclosure provide a computer-readable storage medium storing a computer program for performing the risk control method described in the first aspect above.

[0017] Fourthly, this disclosure provides a computer program product, which includes a computer program that, when run in a processor, implements the risk control method described in the first aspect.

[0018] The embodiments provided in this disclosure construct a dynamic and differentiated risk control decision-making process by acquiring merchant status data, determining merchant levels accordingly, and matching and executing corresponding risk control rules based on predefined level-policy relationships. This solution directly links the execution of risk control measures to merchant levels, thereby achieving automatic and accurate matching of risk control rules with individual merchant risk profiles. This results in personalized risk control rules, effectively improving the accuracy and timeliness of risk control, while avoiding false positives or omissions caused by static, universal strategies that may affect merchants with different risk levels. Attached Figure Description

[0019] The accompanying drawings are provided to further illustrate the present disclosure and form part of the specification. They are used together with the following detailed description to explain the present disclosure, but do not constitute a limitation thereof. In the drawings: Figure 1 The diagram shown is a flowchart of a risk control method provided in an embodiment of this disclosure.

[0020] Figure 2 The diagram shown is an architectural schematic of a risk control system provided in an embodiment of this disclosure.

[0021] Figure 3 The diagram shown is a structural schematic of an electronic device provided in an embodiment of this disclosure. Detailed Implementation

[0022] The specific embodiments of this disclosure will be described in detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are for illustration and explanation only and are not intended to limit this disclosure.

[0023] To overcome the technical problems mentioned in the background section, this disclosure proposes a technical approach. Its core concept lies in introducing a merchant risk level stratification system based on dynamic assessment of merchant status data, and establishing a configurable association between this level and differentiated risk control rules. This improves the generation and triggering of risk decisions, effectively enhancing the targeting of risk control rules and the agility of the configuration process. In other words, it provides a status-driven, level-associative, and strategy-configurable risk control method, improving the accuracy of risk control and the flexibility of risk control rule configuration.

[0024] Specifically, the above-mentioned technical path includes at least the following inventive points: 1) The system can configure multiple merchant levels according to the merchant's attributes and industry. The system will automatically and dynamically adjust the merchant level according to the merchant level configuration. It also supports risk control personnel to manually adjust the merchant level. 2) The risk control rule engine, implemented using a modular approach, eliminates the need for system development, updates, and deployments. Risk control personnel can quickly and flexibly configure new risk control rules to respond rapidly to business needs. 3) Adopt a risk control system based on merchant level tiers, and implement different risk control strategies according to the merchant level, etc. In addition, personalized risk control rules can be configured for individual merchants to achieve personalized risk control strategies.

[0025] The invention points described above will now be explained in detail with reference to specific embodiments.

[0026] In this application, "status data" refers to any set of information that can characterize the status of a risk control object (such as a merchant) at a certain point in time or within a certain time period, used for subsequent assessment of the merchant's merchant rating. For example, it may include, but is not limited to: static attribute data extracted from merchant registration information, or dynamic behavioral data statistically derived from transaction records and operation logs, or a combination thereof. "Risk control rules" refer to a set of computer-executable instructions consisting of one or more conditional judgment logics and their corresponding risk handling actions. For example, it can be expressed as the logical form "If condition A and condition B are both true, then execute action C," or it can be a binding relationship between a set of conditions and actions defined by more complex logical expressions (such as "(A and B and I) or (C and D and I))." "Risk restriction measures" refer to specific control actions taken to prevent and control risks. Taking the payment industry as an example, these include: merchant onboarding control, merchant number blacklists (no onboarding, no offboarding), wallet offboarding blacklists (only onboarding, no offboarding), transaction limits, etc. In specific implementation, different risk control restriction measures can be tailored according to the company's actual situation.

[0027] Figure 1The diagram shown is a schematic flowchart of a risk control method according to an embodiment of the present disclosure. This method can be executed by an electronic device. The method includes the following:

[0028] Step S110: Obtain the status data of the target merchant.

[0029] This step aims to provide real-time and comprehensive data input for subsequent merchant rating assessments. In this application, status data can be obtained in various ways. For example, it could involve querying and retrieving the latest data of the target merchant from the merchant information management module and related business databases in real time in response to specific risk decision requests (such as transaction authorization requests). Alternatively, it could be achieved through background batch processing tasks, periodically (e.g., hourly) extracting incremental behavioral data of merchants from the data warehouse, summarizing and calculating it, and then updating it to the status data snapshot table for quick retrieval during decision-making. More generally, the acquisition of status data is not limited to internal system databases; it can also include auxiliary information obtained from external credit reporting systems and compliance platforms through secure interfaces.

[0030] As a specific implementation method, status data includes merchant attribute data and / or merchant behavior data. Merchant attribute data includes relatively static information such as merchant type (e.g., micro-enterprises, individuals, enterprises), merchant onboarding duration, and merchant authentication status (e.g., whether enterprise four-factor authentication has been completed). Merchant behavior data includes dynamically changing information such as the merchant's transaction volume within a preset time period, the number of transacting users within a preset time period, and the transaction-to-loan ratio within a preset time period. This approach allows for a comprehensive assessment of a merchant's risk status from two dimensions: basic qualifications and ongoing operational performance, making the assessment more multi-dimensional and objective.

[0031] In a specific example, the system calculates from the transaction log that the target merchant had 50 successful transactions in the past 7 days, with 8 users participating, and credit card transactions accounting for 75% of the total transaction amount. Simultaneously, it reads from the merchant profile table that the merchant type is "enterprise," the network access period is 120 days, and the authentication status is "authenticated." These data collectively constitute the set of status data upon which this decision is based.

[0032] Step S120: Determine the target merchant level of the target merchant based on the status data.

[0033] This step is the core of the invention's dynamic differentiated risk control, and its function is to map multidimensional state data into a risk classification identifier with business meaning. This identifier provides a direct index for subsequent selection of risk control rules.

[0034] As a specific implementation method, this determination process includes: automatically and dynamically evaluating and adjusting the target merchant level of the target merchant based on preset trigger conditions based on merchant attribute data and / or merchant behavior data. This means that the system has a built-in automated evaluation logic that can update the merchant level according to data changes without manual intervention.

[0035] Below are some examples of merchant levels and examples of evaluation criteria for different levels.

[0036] S0: Default level; S1: The merchant type is individual or corporate merchant and has passed the four-factor authentication of enterprises; or the merchant type is micro and small and has ≥1 different transaction user and ≥8 transactions within 2 days; S2: The merchant type is micro, small, individual or enterprise merchant, and within 5 days, there are ≥5 different transaction users and ≥5 transactions; S3: Merchant types are micro, small, individual, and corporate merchants, and within 7 days, there are ≥7 different transaction users, ≥7 transaction transactions, and the proportion of transactions by debit card is ≤80%; S4: The risk control offline review of the materials has passed, and the level has been manually changed to S4.

[0037] The system compares the status data obtained in step S110 with these pre-configured level trigger conditions one by one to determine which level the target merchant meets, and then adjusts it to that level. This allows risk control rules to automatically adapt to the actual risk situation of the merchant. Furthermore, considering that automated rules may not cover all complex or special cases, this method also includes adjusting the target merchant level in response to manual instructions from risk control personnel. This provides risk control personnel with a necessary channel for manual intervention, improving the system's flexibility and controllability. For example, in the level example above, after reviewing a merchant's offline qualification materials, risk control personnel can directly modify its level from S2 to the higher S4 level through the management interface.

[0038] More generally, determining a merchant's level is not limited to the "trigger condition" model. For example, a pre-trained risk scoring model can be used. The state data is input into the model to obtain a score from 0 to 100, and then mapped to the corresponding merchant level according to a preset score range (e.g., 0-30 is S0, 31-60 is S1, etc.). All such methods that transform state data into discrete risk classification labels can achieve the higher-level function of associating dynamic states with risk control rules.

[0039] In this application, the term "merchant level" is a classification label used to distinguish different levels of risk or trust. For example, it can be represented by a combination of letters and numbers such as S0, S1, S2, etc., or by textual descriptions such as "high", "medium", "low". Essentially, it is a classification key used for indexing strategies.

[0040] Step S130: Based on the relationship between merchant level and risk control rules, determine the target risk control rules associated with the target merchant level.

[0041] This step facilitates the transition from risk classification to specific control measures. The system pre-stores sets of risk control rules corresponding to different merchant levels, and this association is configurable. Once the target merchant level is determined, the system uses this as the basis for querying and determining one or more risk control rules to be applied to that merchant. To address extremely personalized needs, this method also includes configuring and storing personalized risk control rules for specific merchants; in this case, determining the target risk control rule associated with the target merchant level includes: if the target merchant is the specific merchant, then determining the personalized risk control rule as the target risk control rule. This design adds a special "exception channel" to the general hierarchical system. For example, for a key monitored merchant (whose merchant ID is entered into a special list), regardless of its automatically assigned level, when making risk control decisions, the system will prioritize calling the potentially stricter personalized rules configured specifically for that merchant, while temporarily ignoring the general rules corresponding to its level. This achieves "personalized" risk control rules. The process of determining the target risk control rules can be as follows: retrieve all rules whose "scope of effect" includes the target merchant level from the rule base, and then filter them in combination with the "effective point" of the current decision (such as before the transaction) to finally obtain a list of rules that need to be evaluated in the current context.

[0042] Step S140: Perform risk control on the target merchant based on the target risk control rules.

[0043] This step is the final execution stage of risk control decisions, applying the condition judgment logic and handling actions defined in the rules to actual business scenarios.

[0044] As a specific implementation method, the risk control of the target merchant based on the target risk control rule includes: executing risk restriction measures corresponding to the target risk control rule when the target risk control rule is met. This means that each risk control rule is clearly bound to a specific control action. For example, if the condition of a rule is "a single transaction amount greater than 10,000 yuan", the corresponding risk restriction measure is "transaction blocking and notification". After determining that the condition is met, the system calls the transaction blocking service, terminates the transaction process, and returns a notification message to the user. The types of risk restriction measures are diverse, including but not limited to: merchant onboarding control, adding the merchant number to the blacklist (prohibiting all transactions), adding the merchant wallet to the outgoing blacklist (allowing receipt of payments but prohibiting withdrawals), adjusting transaction limits, and triggering risk warnings without blocking, etc. Specifically, in an example of pre-payment transaction risk control, the target risk control rule is determined to be a rule for S1 level merchants: "If the transaction location is not in the province where the merchant operates, then transaction blocking will be performed." The system determines that the current transaction meets this condition and then executes the "transaction blocking" risk restriction measure, and the transaction request is rejected.

[0045] It should be noted that the merchant level determined in step S120 provides a precise index for quickly selecting the rule subset applicable to the target merchant in step S130, avoiding unnecessary traversal and judgment in the full rule base and improving decision-making efficiency. Furthermore, the target risk control rules determined in step S130 define the logic and actions for specific risk assessment in step S140. The close collaboration of these three steps forms a complete closed loop of "status assessment - strategy matching - decision execution," transforming a static, universal risk control model into a dynamic, differentiated risk control model, thereby effectively resolving the contradiction between risk control accuracy and business flexibility mentioned in the background technology.

[0046] To further optimize the flexibility of rule configuration in the above embodiments, enabling risk control personnel to quickly respond to business changes without development intervention, this application also provides the following preferred solution for a configurable rule engine. As mentioned above, risk control rules need to be highly configurable. In a preferred embodiment, the system provides multiple predefined configurable rule condition units and allows users to combine them in a modular fashion to generate rules.

[0047] Specifically, the system first provides a set of predefined configurable rule condition units. These rule condition units are abstract encapsulations of common risk control judgment conditions, such as "merchant level belongs to a certain set", "registration duration is less than N days", "number of transactions in the last X days is greater than M", and "transaction amount is within the range [Y, Z]". Each unit is an independently configurable "building block", and users can set specific parameters for it, such as the values ​​of N, M, X, Y, and Z.

[0048] Then, the system receives a user configuration instruction, which includes at least one rule condition unit selected from the aforementioned rule condition unit library and logical operators (such as "AND", "OR", and "NOT") connecting them. In response to this instruction, the system combines the selected rule condition units using the logical operators to generate an executable risk control rule. For example, the user selects "Merchant level belongs to {S0, S1}" as unit A, "Registration duration < 60 days" as unit B, and "Transaction payment method is QR code payment" as unit I through the interface, and connects them using the logical "AND" to form a subexpression "A AND B AND I". Multiple such subexpressions are then connected using "OR" to ultimately generate a complete rule expression. This design allows business personnel to intuitively construct complex rules like building blocks, without requiring system development updates and deployments. Risk control personnel can quickly and flexibly configure new risk control rules to rapidly respond to business needs.

[0049] Building upon this, to further enhance the applicability and granularity of the rules, user configuration instructions can also include configuring the scope and activation point for the risk control rules. The scope includes which merchant levels and product types (such as credit card transactions and QR code transactions) the rule applies to, and the activation point includes at which stage of the business process the rule is triggered, such as merchant registration, before the transaction, after the transaction, or before disbursement. By configuring the activation point, end-to-end risk control can be achieved throughout the business process. For example, a rule can be configured to only take effect at the "after the transaction, before disbursement" stage, serving as a final interception of funds flowing out of suspicious transactions.

[0050] Furthermore, to provide a reasonable unblocking pathway after risk control is implemented, the user configuration instruction may also include configuring unblocking conditions for the risk control rule. Accordingly, the method further includes: when implementing risk restriction measures corresponding to the target risk control rule, in response to the target merchant meeting the unblocking conditions, lifting the risk restriction measures. Unblocking conditions may include requiring the merchant to complete real-name authentication, facial recognition verification, submit supplementary qualification materials, or undergo a security observation period, etc. This achieves closed-loop management of risk control procedures, avoiding permanent bans on merchants, and balancing risk control with the possibility of merchant experience and business recovery.

[0051] Those skilled in the art will understand that the specific content of the rule condition unit can be expanded as business develops, for example, adding "device fingerprint risk score" as a new condition unit. The division of the effective node can also be more refined, for example, adding "after binding the device" or "when participating in marketing activities". The judgment of the release condition can also be executed automatically by the system or transferred to manual review. These variations can all achieve the core purpose of user-configurable rule generation. By adopting the above-mentioned configurable rule engine, this preferred solution can greatly reduce the launch cycle of new rules and greatly improve the response speed of risk control rules to new market risks, thereby synergistically strengthening the overall technical effect of the dynamic adaptive risk control of this invention.

[0052] To better understand this disclosure, the risk control system implementing this disclosure is described below, such as... Figure 2 As shown, the risk control model, including the effective node, effective scope, and rule set, works together to generate risk control decisions. Subsequently, the risk control system can execute corresponding risk control restrictions based on these decisions. Furthermore, users can configure the requirements for lifting risk control restrictions; the risk control system can then lift the restrictions when these requirements are met.

[0053] Those skilled in the art will understand that, in the above-described method of specific implementation, the specific execution order of each step should be determined by its function and possible internal logic, and the execution order between steps is not limited to implementation according to step number.

[0054] In addition, this disclosure also provides electronic devices, computer-readable storage media, and computer program products, all of which can be used to implement any of the risk control methods provided in this disclosure. The corresponding technical solutions and descriptions are described in the relevant section of the method and will not be repeated here.

[0055] Figure 3 This is a block diagram of an electronic device provided in an embodiment of the present disclosure.

[0056] Reference Figure 3 This disclosure provides an electronic device, which includes: at least one processor 301; at least one memory 302; and one or more I / O interfaces 303 connected between the processor 301 and the memory 302; wherein the memory 302 stores one or more computer programs that can be executed by the at least one processor 301, and the one or more computer programs are executed by the at least one processor 301 to enable the at least one processor 301 to perform the risk control method described above.

[0057] The modules in the aforementioned electronic devices can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of a computer device in hardware form or independent of it, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0058] This disclosure also provides a computer-readable storage medium storing a computer program for performing the risk control method described above.

[0059] This disclosure also provides a computer program product, including a computer program that, when run in a processor, implements the above-described risk control method.

[0060] The aforementioned computer program product can be implemented through hardware, software, or a combination thereof. In one optional embodiment, the computer program product is specifically manifested as a computer storage medium; in another optional embodiment, the computer program product is specifically manifested as a software product, such as a software development kit (SDK), etc.

[0061] Those skilled in the art will understand that all or some of the steps, systems, and apparatuses disclosed above, and their functional modules / units, can be implemented as software, firmware, hardware, or suitable combinations thereof. In hardware implementations, the division between functional modules / units mentioned above does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed collaboratively by several physical components. Some or all physical components may be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit (ASIC). Such software can be distributed on a computer-readable storage medium, which may include computer storage media (or non-transitory media) and communication media (or transient media).

[0062] As is known to those skilled in the art, the term computer storage medium includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information, such as computer-readable program instructions, data structures, program modules, or other data. Computer storage media includes, but is not limited to, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), static random access memory (SRAM), flash memory or other memory technologies, portable compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to a computer. Furthermore, it is known to those skilled in the art that communication media typically contain computer-readable program instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.

[0063] The computer-readable program instructions described herein can be downloaded from computer-readable storage media to various computing / processing devices, or downloaded via a network, such as the Internet, local area network, wide area network, and / or wireless network, to an external computer or external storage device. The network may include copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to the computer-readable storage media in the respective computing / processing device.

[0064] Computer program instructions used to perform the operations of this disclosure may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, status setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, etc., and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, electronic circuitry, such as programmable logic circuitry, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), is personalized by utilizing the status information of the computer-readable program instructions to implement various aspects of this disclosure.

[0065] The computer program product described herein can be implemented specifically through hardware, software, or a combination thereof. In one alternative embodiment, the computer program product is specifically embodied in a computer storage medium; in another alternative embodiment, the computer program product is specifically embodied in a software product, such as a software development kit (SDK), etc.

[0066] Various aspects of this disclosure are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. 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-readable program instructions.

[0067] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that, when executed by the processor of the computer or other programmable data processing apparatus, they create means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner; thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0068] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions executed on the computer, other programmable data processing apparatus, or other device to perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0069] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction containing one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than those shown in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0070] The above description is merely a preferred embodiment of this disclosure and is not intended to limit this disclosure. Any modifications or equivalent substitutions made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A risk control method, characterized in that, include: Obtain the status data of the target merchant; Based on the status data, the target merchant level of the target merchant is determined; Based on the relationship between merchant level and risk control rules, determine the target risk control rules associated with the target merchant level; Risk control is carried out on the target merchant based on the target risk control rules.

2. The risk control method according to claim 1, characterized in that, The step of determining the target merchant level of the target merchant based on the status data includes: Based on preset trigger conditions that are based on merchant attribute data and / or merchant behavior data, the target merchant level of the target merchant is automatically and dynamically evaluated and adjusted.

3. The risk control method according to claim 1, characterized in that, The method further includes: In response to manual instructions from risk control personnel, the target merchant level of the target merchant is adjusted.

4. The risk control method according to any one of claims 1 to 3, characterized in that, The method further includes: Provides multiple predefined, configurable rule condition units; Receive user configuration instructions, the user configuration instructions including at least one rule condition unit selected from the plurality of predefined configurable rule condition units and a logical operator; In response to the user configuration instruction, the selected at least one rule condition unit is combined using the logical operator to generate an executable risk control rule.

5. The risk control method according to claim 4, characterized in that, The user configuration instructions also include the effective scope and effective nodes for configuring the risk control rules; the effective scope includes merchant level and product type, and the effective nodes include merchant registration, before transaction, after transaction, and before payment.

6. The risk control method according to claim 4, characterized in that, The user configuration instruction further includes configuring a release condition for the risk control rule, and the method further includes: When implementing risk restriction measures corresponding to the target risk control rule, the risk restriction measures are lifted in response to the target merchant meeting the lifting conditions.

7. The risk control method according to any one of claims 1 to 3, characterized in that, The risk control of the target merchant based on the target risk control rules includes: If the target risk control rule is met, risk restriction measures corresponding to the target risk control rule shall be implemented.

8. The risk control method according to any one of claims 1 to 3, characterized in that, The status data includes merchant attribute data and / or merchant behavior data; the merchant attribute data includes merchant type, merchant network access duration, merchant authentication status, etc.; the merchant behavior data includes the merchant's transaction volume within a preset time period, the number of transaction users within a preset time period, the transaction-to-loan ratio within a preset time period, etc.

9. The risk control method according to any one of claims 1 to 3, characterized in that, The method further includes: Configure and store personalized risk control rules for specific merchants; The determination of the target risk control rules associated with the target merchant level includes: If the target merchant is the specific merchant, then the personalized risk control rule is determined to be the target risk control rule.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the risk control method according to any one of claims 1 to 9.

Images