A transaction risk control method and system based on process management

Abstract

The application discloses a transaction risk control method and system based on process management, and the method comprises the following steps: receiving a risk control request carrying transaction data and a request context; determining a process identifier based on the request context, and obtaining risk control input data and constructing a rule execution context according to a risk control data model configuration associated with the process identifier; a rule execution engine loads and parses a rule chain definition from a rule configuration center according to the process identifier, drives a plurality of risk control component nodes to process the context to output a risk control result, and records execution data; wherein the rule chain definition is stored in a configuration mode and is separated from an application program, when rule publishing and updating trigger reloading, the rule execution engine selects the rule chain according to the version number for subsequent requests. Thus, real-time risk control in the transaction process is realized, the running period is quickly adjusted, a traceable record is formed, and the problems of lagging bypass / after risk control and difficulty in iteration of rule solidification are solved.

Description

Technical Field

[0001] This application relates to the field of computer software technology, and in particular to a transaction risk control method and system based on process management. Background Technology

[0002] With the rapid development of online transactions such as internet payments, e-commerce orders, account transfers, and digital lending, the transaction chain is characterized by high concurrency, low latency, long chains, and multiple participating systems. At the same time, risky behaviors targeting transaction scenarios, such as fraud, theft, exploitation, and malicious arbitrage, have become more diversified and covert. This necessitates that transaction systems typically conduct comprehensive assessments of multi-dimensional information, including user, device, account, funds, and behavior, during transaction execution. They must then make risk management decisions at appropriate times, such as blocking, downgrading, secondary verification, or allowing the transaction to proceed, thereby ensuring the security of funds and business operations while also considering user experience.

[0003] In existing technologies, common implementations of transaction risk control solutions mainly include: First, using post-analysis or bypass-based rule engines / risk control systems to decouple risk identification from the main transaction process in terms of architecture. This approach typically performs rule judgments after the transaction is completed or outside the transaction chain. While convenient for independent construction and iteration, it often suffers from problems such as delayed decision-making, difficulty in achieving strong intervention at precise stages of transaction execution, and insufficient utilization of dynamic context during the transaction process, making it difficult to respond promptly to new types of fraud and rapidly changing risk patterns. Second, embedding fixed risk control checkpoints within several nodes of the transaction process, executing some rules upfront in the transaction chain. Although this approach can achieve upfront interception to a certain extent, since risk control points and rule logic are often fixed in the process nodes in the form of code, strategy adjustments usually require code modification, re-release, or linkage with multiple system upgrades. At the same time, the tendency to enable checks across all systems in pursuit of "stability" leads to unnecessary computation and resource consumption, increased chain latency, and additional disturbances to low-risk transactions, affecting overall system efficiency and user experience.

[0004] Therefore, in the real-time decision-making and intervention within the transaction risk control process, the decoupling of risk control strategies from the main transaction process leads to delays in risk identification and handling, the static solidification of risk control points and rule logic makes it difficult to quickly iterate and adapt to new risks, and the waste of resources and decline in user experience caused by the full execution of checks for the sake of conservatism have become urgent problems to be solved. Summary of the Invention

[0005] This application provides a transaction risk control method and system based on process management, aiming to solve the problems in the real-time decision-making and intervention within the transaction risk control process of existing technologies, such as the decoupling of risk control strategies and the main transaction process, which leads to the lag in the time of risk identification and handling; the static solidification of risk control points and rule logic, which makes it difficult to quickly iterate and adapt to new risks; and the waste of resources and decline in user experience caused by the full execution of checks for the sake of conservatism.

[0006] Firstly, a transaction risk control method based on process management, the method comprising:

[0007] Receive a transaction risk control request, the transaction risk control request carrying transaction data and request context information;

[0008] Determine the process identifier corresponding to the transaction risk control request based on the request context information;

[0009] Risk control input data is obtained based on the risk control data model configuration associated with the process identifier;

[0010] A rule execution context object is constructed based on the aforementioned risk control input data;

[0011] The rule execution engine loads the rule chain definition corresponding to the process identifier based on the process identifier, and parses the rule chain definition to drive multiple risk control component nodes to process the rule execution context object to obtain the risk control result;

[0012] Output the risk control results and record the execution data corresponding to the risk control results;

[0013] The rule chain definition is stored in a configurable form in the rule configuration center and is separated from the application. When the rule configuration center publishes an updated rule chain definition and triggers reload, the rule execution engine selects the rule chain definition based on the rule version number to process the incoming transaction risk control request.

[0014] Optionally, in the above scheme, after determining the process identifier, the method includes:

[0015] Based on the business type, event type, model type identifier and / or rule hit information in the request context information, one or more risk control data models to be used in this transaction risk control request are dynamically determined, and the one or more risk control data models are associated with the process identifier.

[0016] Optionally, in the above scheme, obtaining risk control input data includes:

[0017] Based on the field extraction rules configured in the risk control data model, field values ​​are located and extracted from the transaction data and / or external data sources to form structured input data;

[0018] The structured input data is validated based on the data structure constraints corresponding to the risk control data model.

[0019] After the verification is passed, the structured input data is preprocessed to obtain the risk control input data.

[0020] Optionally, in the above scheme, the field extraction rules include JSONPath rules, and the fields are located and their values ​​are extracted from the transaction data according to the JSONPath rules.

[0021] In the above scheme, optionally, the data structure constraints are generated through JSONSchema, and the validation includes: field type validation, field format validation, field value range validation, required field validation, and field dependency validation; when the validation fails, the rule chain processing for this transaction risk control request is terminated and an error message is returned.

[0022] Optionally, in the above scheme, the preprocessing is performed through a preprocessing extension plugin, and the preprocessing extension plugin performs the following operations:

[0023] Call external interfaces to supplement dynamic data;

[0024] Map business fields to internal standard fields and / or perform unit conversions;

[0025] Calculate derived variables based on extracted fields;

[0026] Mask and / or encrypt sensitive fields.

[0027] Optionally, in the above scheme, loading and parsing the rule chain definition includes:

[0028] Read the rule chain definition stored in JSON format from the database;

[0029] The rule chain definition is parsed according to the domain-specific language (DSL).

[0030] The multiple risk control component nodes are driven to execute according to the component node arrangement relationship formed by the THEN, WHEN and / or SWITCH logical operators in the DSL.

[0031] Optionally, in the above scheme, when the rule chain definition indicates the existence of parallel orchestration, it includes:

[0032] Risk control component nodes that are declared to be executed in parallel based on the WHEN keyword;

[0033] Create a separate copy of the rule execution context object for each transaction risk control request;

[0034] After parallel execution is completed, the data generated by parallel execution is merged, and the merged data is written to the rule execution context object.

[0035] Optionally, in the above scheme, the method further includes:

[0036] In the rule configuration center, a rule chain list and a script table are maintained respectively. The rule chain list is used to store rule chain definitions, and the script table is used to store dynamic script components.

[0037] After publishing the rule chain definition and / or dynamic script component in the rule management backend, a reload notification is sent to the risk control microservice via an HTTP request;

[0038] Upon receiving the reload notification, the risk control microservice triggers the rule execution engine to reload the rule chain definition and / or dynamic script components.

[0039] Write the request identifier into the rule execution context object, and write at least a portion of the contents of the rule execution context object into the execution flow table.

[0040] Secondly, a transaction risk control system based on process management includes:

[0041] The risk control microservice is used to receive transaction risk control requests, determine process identifiers, obtain risk control input data based on the risk control data model configuration associated with the process identifiers, construct rule execution context objects, and output risk control results.

[0042] The rule configuration center is used to store the rule chain definitions corresponding to the process identifier and supports publishing and updating them, and is also used to store dynamic script components;

[0043] The rule execution engine is used to load and parse the rule chain definition based on the process identifier, so as to drive multiple risk control component nodes to process the rule execution context object;

[0044] The execution pipeline storage module is used to store execution data corresponding to risk control results;

[0045] The rule chain definition is stored in a configurable form and separated from the application. When the rule chain definition is updated and reloaded, the rule execution engine selects the rule chain definition based on the rule version number to handle the incoming transaction risk control request.

[0046] Compared with the prior art, this application has at least the following beneficial effects:

[0047] This application, based on further analysis and research of existing technical problems, recognizes that existing technologies suffer from several issues in real-time decision-making and intervention within the transaction risk control process. These include: decoupling risk control strategies from the main transaction process, leading to delays in risk identification and handling; static and fixed risk control points and rule logic hindering rapid iteration to adapt to new risks; and resource waste and decreased user experience caused by conservative full-scale checks. This application addresses these issues by determining the corresponding process identifier based on the request context upon receiving a transaction risk control request. Based on this identifier, a rule chain definition matching the process identifier is loaded from a rule configuration center separate from the application. The rule execution engine then parses the rule chain and drives multiple risk control component nodes to complete processing within the same rule execution context object, outputting the risk control result. Therefore, risk control decisions are generated in real-time during the transaction request processing along the path of "process identifier—rule chain—component execution," rather than relying on post-event analysis or bypass judgment outside the main transaction process. This ensures that the decision-making time is synchronized with the transaction request and can be completed within the process. Furthermore, this solution clearly defines the rule chain definition... The rules are stored in a configurable form and separated from the application. When an update is released in the rule configuration center and a reload is triggered, the engine selects the rule chain based on the version number for subsequent requests. This means that rule adjustments can be completed in runtime without statically embedding risk control logic in the transaction node code, thus meeting the rapid iteration needs under changing risk patterns and avoiding adjustment delays caused by static point fixation. Furthermore, this solution requires the construction and transmission of rule execution context objects and the recording of execution data corresponding to the results. This ensures that the execution process and results of each request's rule chain have a traceable data carrier, facilitating the verification and review of risk assessments. In summary, through the combination of "loading and executing configurable rule chains by identifier within the process, runtime reload and version switching, and contextual penetration and execution data recording," this solution can address the problems in the background technology, such as the processing delays caused by the decoupling of risk control and the main process, the difficulty in rapid iteration and adaptation due to the static fixation of risk control points and rule logic, and the resulting inflexible control of risk within the process. Attached Figure Description

[0048] Figure 1 A flowchart illustrating a transaction risk control method based on process management, provided as an embodiment of this application;

[0049] Figure 2 A functional block diagram of a process management-based transaction risk control system provided in one embodiment of this application;

[0050] Figure 3 A timing diagram of the rule engine side is provided for one embodiment of this application. Detailed Implementation

[0051] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0052] In one embodiment, such as Figure 1 As shown, a transaction risk control method based on process management is provided, including the following steps:

[0053] Receive a transaction risk control request, the transaction risk control request carrying transaction data and request context information;

[0054] Determine the process identifier corresponding to the transaction risk control request based on the request context information;

[0055] Risk control input data is obtained based on the risk control data model configuration associated with the process identifier;

[0056] A rule execution context object is constructed based on the aforementioned risk control input data;

[0057] The rule execution engine loads the rule chain definition corresponding to the process identifier based on the process identifier, and parses the rule chain definition to drive multiple risk control component nodes to process the rule execution context object to obtain the risk control result;

[0058] Output the risk control results and record the execution data corresponding to the risk control results;

[0059] The rule chain definition is stored in a configurable form in the rule configuration center and is separated from the application. When the rule configuration center publishes an updated rule chain definition and triggers reload, the rule execution engine selects the rule chain definition based on the rule version number to process the incoming transaction risk control request.

[0060] In this embodiment, after determining the process identifier, the method includes:

[0061] Based on the business type, event type, model type identifier and / or rule hit information in the request context information, one or more risk control data models to be used in this transaction risk control request are dynamically determined, and the one or more risk control data models are associated with the process identifier.

[0062] In this embodiment, obtaining risk control input data includes:

[0063] Based on the field extraction rules configured in the risk control data model, field values ​​are located and extracted from the transaction data and / or external data sources to form structured input data;

[0064] The structured input data is validated based on the data structure constraints corresponding to the risk control data model.

[0065] After the verification is passed, the structured input data is preprocessed to obtain the risk control input data.

[0066] In this embodiment, the field extraction rules include JSONPath rules, and the fields are located and their values ​​are extracted from the transaction data according to the JSONPath rules.

[0067] In this embodiment, the data structure constraints are generated using JSONSchema, and the validation includes: field type validation, field format validation, field value range validation, required field validation, and field dependency validation; when the validation fails, the rule chain processing for this transaction risk control request is terminated and an error message is returned.

[0068] In this embodiment, the preprocessing is performed through a preprocessing extension plugin, and the preprocessing extension plugin performs the following operations:

[0069] Call external interfaces to supplement dynamic data;

[0070] Map business fields to internal standard fields and / or perform unit conversions;

[0071] Calculate derived variables based on extracted fields;

[0072] Mask and / or encrypt sensitive fields.

[0073] In this embodiment, the loading and parsing rule chain definition includes:

[0074] Read the rule chain definition stored in JSON format from the database;

[0075] The rule chain definition is parsed according to the domain-specific language (DSL).

[0076] The multiple risk control component nodes are driven to execute according to the component node arrangement relationship formed by the THEN, WHEN and / or SWITCH logical operators in the DSL.

[0077] In this embodiment, when the rule chain definition indicates the existence of parallel orchestration, it includes:

[0078] Risk control component nodes that are declared to be executed in parallel based on the WHEN keyword;

[0079] Create a separate copy of the rule execution context object for each transaction risk control request;

[0080] After parallel execution is completed, the data generated by parallel execution is merged, and the merged data is written to the rule execution context object.

[0081] In this embodiment, the method further includes:

[0082] In the rule configuration center, a rule chain list and a script table are maintained respectively. The rule chain list is used to store rule chain definitions, and the script table is used to store dynamic script components.

[0083] After publishing the rule chain definition and / or dynamic script component in the rule management backend, a reload notification is sent to the risk control microservice via an HTTP request;

[0084] Upon receiving the reload notification, the risk control microservice triggers the rule execution engine to reload the rule chain definition and / or dynamic script components.

[0085] Write the request identifier into the rule execution context object, and write at least a portion of the contents of the rule execution context object into the execution flow table.

[0086] In one feasible implementation, the transaction risk control method runs under a microservice architecture, including at least a risk control microservice, a rule configuration center, and a rule execution engine. The risk control microservice provides a risk decision interface (e.g., HTTP / HTTPS or RPC interface) to receive risk control requests carrying transaction data and request context information; the request context information may include fields such as business type, channel source, event type, user / enterprise identifier, model type identifier, and hit rule identifier.

[0087] The risk control microservice determines the process identifier (process ID) based on the request context information. The process identifier can be understood as "the risk control process template applicable to this transaction," and can be mapped from combinations such as "business type + event type + channel." After the process identifier is determined, the risk control microservice performs data preparation according to the risk control data model configuration associated with the process identifier, including field extraction, structuring, validation, and pre-processing, and generates risk control input data (such as a unified Map / JSON object or POJO object) oriented towards rule execution.

[0088] The risk control microservice assembles risk control input data into rule execution context objects, such as EngineContext. These context objects remain unique throughout the lifecycle of a single request and are used throughout the execution process. These objects may include model identifier (GUID), request identifier (reqId), step data (stepData), intermediate outputs from each component, and final decision fields.

[0089] The rule execution engine loads the corresponding rule chain definition from the rule configuration center based on the process identifier. The rule chain definition is stored separately from the application in a configurable form (such as rule chain text saved as JSON in the database). After parsing it, the rule execution engine calls multiple risk control component nodes to execute in sequence or in parallel, and finally forms a risk control result (such as decision codes for release, interception, secondary verification, downgrade and other related information).

[0090] "Recording execution data" can be achieved through two types of data storage: one is the execution trajectory and component logs naturally generated by the rule engine (such as component start / end, time consumption, and exception information); the other is to set up a dedicated result component at the end of the rule chain to write the key fields, intermediate results, and final decisions in the EngineContext into the execution log table for subsequent retrieval and auditing.

[0091] Regarding hot updates of rule chains, after the rule configuration center publishes the updated rule chain definition, it can trigger the risk control microservice to notify the rule execution engine to reload the rules. When reloading, the engine uses version numbers to distinguish between the old and new rule chains, so as to ensure that the same request uses the same version of the rule chain during execution, and new requests use the new version of the rule chain.

[0092] This embodiment separates the rule chain configuration from the application, loads the rule chain with a process identifier and switches it by version during runtime, and transmits and records the execution data of risk control input data in a unified context. This enables risk control decisions to be executed according to the process within the transaction processing chain and supports runtime updates and traceable records, thereby adapting to the problem scenarios of "outside the process / post-event lag, static solidification and difficulty in adjustment" in the background technology.

[0093] This embodiment provides a risk control method applicable to scenarios such as e-commerce, online payment, and financial transactions. Its core objective is to use technical means to identify, assess, and respond to potential risks in real time during transaction execution, thereby ensuring transaction security and reducing fraud losses.

[0094] In existing transaction risk control solutions, the following technical approaches are typically employed to achieve risk management. The following will focus on two background technologies that are closest to the objectives and means of this invention:

[0095] Post-event analysis-based rule engine risk control solution: This is a widely adopted risk control method. This solution typically deploys a separate risk control rule engine outside the core transaction processing chain. When a transaction is completed in the business system, or reaches a key node (such as payment confirmation), the system synchronously or asynchronously sends the transaction data to the risk control engine. The risk control engine performs batch analysis and matching of the data based on preset, fixed static rules (e.g., "single transaction amount greater than 5000 yuan", "same account more than 10 transactions within one hour"). If a risk rule is triggered, the engine returns a risk flag or execution instruction to the business system (e.g., blocking the transaction, requiring secondary verification).

[0096] Implementation process: The transaction is executed in the main business process -> paused at a specific node and the risk control service is invoked -> the risk control engine performs rule matching based on the full amount of data -> the decision result is returned -> the business system decides on subsequent operations based on the result.

[0097] Function Description: This solution can effectively intercept known and well-defined risk patterns and has strong rule interpretability.

[0098] Static risk control solutions based on embedded process nodes: To more closely integrate with business processes, another existing technology attempts to embed risk control points directly into specific nodes of the transaction process. For example, a mandatory risk control checkpoint is set before key steps such as "creating an order," "paying," and "shipping." Each checkpoint has pre-defined corresponding risk control rules.

[0099] Implementation process: The transaction process is executed in the order of preset steps -> when the step with the embedded risk control node is executed, the risk control check of that node is triggered -> the corresponding risk control module is called to perform the check -> the process is determined based on the check result to decide whether to continue to the next node.

[0100] Function Description: This solution initially integrates risk control with business processes, ensuring that risk review must be conducted before critical operations, making it more timely compared to post-event analysis solutions.

[0101] The shortcomings of the "rule engine risk control solution based on post-event analysis" include poor real-time performance and integration with the process: This solution is essentially a "post-event audit" or "bypass detection" system. The risk control process is independent of the main business process, leading to a significant lag in risk intervention. When the risk control engine determines that a transaction is risky, the transaction may have already completed its core steps in the business system, resulting in resource consumption and a poor user experience. The root cause of its shortcomings lies in the decoupling of the risk control system from the business process in its architecture, making it impossible to intervene "within the process" in real time at the precise point of transaction execution.

[0102] Data-driven approach and rigid decision-making: Its rules are usually static, pre-defined, and global, lacking flexible responses to the specific context of individual transactions. Because it mainly relies on data snapshots after completion or at nodes for analysis, it cannot utilize real-time contextual information dynamically generated during the transaction process to adjust risk control strategies, resulting in insufficient ability to cope with new and complex fraud patterns.

[0103] Addressing the shortcomings of "static risk control solutions based on embedded process nodes": rigid risk control strategies and insufficient flexibility. Although this solution embeds risk control points into the process, the risk control points (which step to check) and the rules implemented at each point (what to check) are pre-configured statically during system design or deployment. Once the process is released, the risk control logic becomes fixed. When it is necessary to dynamically enable, disable, or adjust a risk control point based on real-time risk conditions (e.g., a sudden cyberattack), code modification and system redeployment are often required, resulting in extremely slow response times and an inability to meet rapidly changing risk control needs.

[0104] Inaccurate resource allocation negatively impacts user experience: Due to the inability to achieve "real-time control," this solution tends to activate all or most risk control functions at fixed points in all transaction processes—a conservative "better to kill the innocent than let the guilty go free" strategy. This forces a large number of low-risk or normal transactions to undergo unnecessary risk control checks, increasing system processing latency, reducing overall transaction efficiency, and harming the user experience.

[0105] In view of the shortcomings of the existing technologies, such as delayed risk control intervention, disconnect from business processes, and rigid and inflexible risk control strategies, the purpose of this embodiment is to provide a new transaction risk control method based on process management, in order to achieve deep integration of risk control strategies and business execution in terms of time and logic.

[0106] The objectives of this embodiment include: achieving real-time and dynamic adjustment of risk control points; overcoming the drawback of fixed risk control points in existing static embedding schemes, this invention aims to provide the ability to dynamically enable, disable, or adjust specific risk control points (i.e., control actions) during the execution of a transaction process based on real-time risk context, system load, or specific business rules. This allows risk control measures to be precisely applied to necessary stages, avoiding indiscriminate checks on all transactions.

[0107] Achieve real-time intervention embedded in the process: Solve the problem of lagging traditional ex-post risk control solutions. By embedding risk control logic into the definition of the transaction process in the form of configurable units (risk control points), it ensures that the preset control actions can be automatically triggered the moment the transaction is executed to the corresponding process node, thereby achieving real-time risk intervention that is synchronized with the business process.

[0108] Improving risk control efficiency and user experience: Through the above-mentioned dynamic and real-time control mechanism, this invention strives to minimize interference with normal, low-risk transaction processes and shorten unnecessary risk control check time while ensuring transaction security, thereby effectively improving overall transaction processing efficiency and end-user experience.

[0109] The core objective of this embodiment is to construct a flexible, accurate, efficient, and seamlessly integrated intelligent risk control system that combines "front-end process management" with "real-time control" through a technical means.

[0110] This embodiment relates to the field of computer software technology, and in particular to an enterprise-level transaction risk control technology based on a microservice architecture and a rule engine. To overcome the problems of coupling and inability to dynamically update caused by current mainstream risk control implementation methods such as hard coding, this embodiment provides a dynamic transaction risk control solution based on the open-source LiteFlow rule engine, aiming to achieve flexible orchestration, dynamic deployment, and efficient execution of risk control strategies.

[0111] Figure 2 This is a system functional block diagram of the technical solution. The system in this embodiment mainly includes a risk control microservice, a rule configuration center, and a rule execution engine. The risk control microservice receives transaction requests and constructs risk control context information. The rule execution engine is implemented based on LiteFlow, loading pre-arranged rule chain definitions from the rule configuration center. The rule chain is composed of multiple risk control component nodes connected by logical operators. The engine parses the rule chain, calls the corresponding risk control components sequentially or in parallel, and finally integrates the execution results of all components to generate a unified risk control decision. The following are the specific implementation process and technical measures:

[0112] Atomization and componentization of risk control rules. Complex risk control logic is decomposed into atomic rules with single function and clearly defined responsibilities, and each atomic rule is encapsulated as an independent, reusable execution component. For example, all explicit process rule components are required to inherit the LiteFlow framework's NodeComponent abstract class and override its process method, unifying the model's execution entry and exit points. A dedicated EngineContext object for risk control is created as a carrier for data transfer between components. This object is created at the start of the process and persists throughout the entire rule chain execution lifecycle, containing model GUID, event request reqId, step data stepData, etc.

[0113] Visualization and DSL (Domain-Specific Language) orchestration of risk control strategies. Risk control strategies defined by business experts are translated into a Domain-Specific Language (DSL) that the rule engine can understand. Atomic components are connected into complex business process chains using logical operators (THEN, WHEN, SWITCH, etc.). The initial rule chain definition is stored in the database in JSON format, separating the rule file from the application. The risk control strategy is visualized and rendered according to the rules configuration conventions, making it both expressible of complex logic and relatively user-friendly for business personnel.

[0114] A dynamic loading and hot-update mechanism for rule configurations is implemented. By monitoring changes in external configuration sources, the latest rule configurations are loaded into the rule engine in real time without system downtime, achieving second-level updates of risk control strategies. For example, the database includes a table `engine_rule_chain` to store the rule chain content of the risk control model, and a table `engine_rule_script` to store dynamic script components. Custom process rule executors and rule configuration classes are inherited and implemented, enabling them to read rule configurations and script components from the database. In the rule management backend, when a user modifies and publishes a rule, an HTTP request notifies the risk control microservice rule executor to reload the rule. During rule reloading, a version number mechanism is used to ensure that currently processed business logic continues to use the old, stable rule version, while new requests use the new rule, avoiding dirty data and logical inconsistencies.

[0115] Asynchronous parallel execution and context data synchronization. Leveraging LiteFlow's support for parallel orchestration, risk control checkpoints without causal dependencies are executed in parallel. A thread-safe context object resolves data race and merging issues during parallel execution. Specifically, the WHEN keyword is used appropriately in the DSL to declare components requiring parallel execution. Although multiple components execute in parallel, each component operates on the same EngineContext object. To ensure thread safety, ThreadLocal provides an independent copy of the context for each request, and the engine automatically merges the data after the parallel phase ends.

[0116] Enhanced end-to-end decision traceability and monitoring. Leveraging LiteFlow's declarative execution flow, the framework naturally records the execution trajectory of each component. Enhanced logging and monitoring ensure complete traceability of every transaction's risk control decisions. Configure LiteFlow's log level to DEBUG, which automatically enables detailed logging. Require the use of the MDC (MappedDiagnosticContext) thread binding tool in the `process` method of each component to inject `reqId`, event request ID, etc., into the log context and record key information. At the end of the process, add a dedicated `EngineResult` component. This component is responsible for storing the complete `EngineContext` object, including the results of all intermediate steps and the final decision, into a dedicated pipeline table for subsequent querying, auditing, and model optimization.

[0117] Through these five interconnected technical measures, we successfully transformed a static and rigid risk control system into a dynamically orchestrated, reusable, high-performance, and fully traceable intelligent risk control decision-making platform. This is not merely a simple application of the rules engine, but a deep customization and architectural innovation for its application in complex business flows.

[0118] Figure 3 The sequence diagram on the rules engine side illustrates the overall timeline from user operation to rule execution. This process integrates declarative configuration, dynamic verification, and extended processing mechanisms, providing flexible and reliable technical support for risk control decisions in complex business scenarios. Its core steps are broken down as follows.

[0119] Model Definition and Specification Generation. During the risk control strategy design phase, business experts define the risk control data model through business scenario analysis. This model clearly defines the core entities (such as company size, fund usage, and litigation cases) and their attributes required for risk assessment. After the model is built, the system strictly follows the JSON Schema syntax specification to generate corresponding structure definition and validation files, describing data types, formats, enumeration values, dependencies, and other constraints.

[0120] Asynchronous data preprocessing and model routing. When a risk decision request enters the risk control microservice, the system initiates an asynchronous processing flow. First, based on the context information in the request (such as model type `modelType` and the matched rule `ruleJson`), and through pre-agreed model attribution definitions, the system dynamically queries and determines one or more data models required for this risk decision. For example, in the Enterprise Credit System's post-loan risk monitoring, a change in a company's operating status may simultaneously be associated with both the "Company Size Model" and the "Financial Pre-Loan Model".

[0121] Dynamic field extraction and standardization. After determining the target model, the system uses the JSONPath rules defined in the model configuration to accurately locate and extract the required field values ​​from raw, potentially loosely structured request data or external data sources (such as the user center or enterprise database). For example, the JSONPath expression $.improveInfo.corpKind is used to extract enterprise nature information. This step transforms heterogeneous raw data into structured input objects that conform to the model definition.

[0122] Compliance verification and data cleansing. The extracted structured data will be submitted to a JSONSchema specification validator for rigorous verification. The validator will check whether all fields conform to preset rules: whether the type is correct (e.g., whether the amount is a number), whether the format is valid (e.g., date format), whether the value range is within the allowed range, and whether required fields are missing, etc. Any verification failure will immediately interrupt the process and return a clear error message, ensuring that the data flowing into the rules engine is of high quality and compliance, avoiding the problem of "garbage in, garbage out" from the source.

[0123] Flexible pre-processing extension: Given the high complexity of actual business operations, standardized and validated data may still require further processing to meet the execution requirements of rule components. Therefore, the system provides a powerful pre-processing extension mechanism. Developers can insert custom eventHandler plugins at this stage to perform actions such as:

[0124] Real-time data extraction: Call external APIs to supplement dynamic data such as remaining credit limit and overdue tags in real time.

[0125] Parameter mapping and conversion: Map business descriptions (such as payment source descriptions) to internal standard codes (CRM), or convert amounts to units.

[0126] Content enhancement and derivation: Calculate derived variables based on existing fields, such as the ratio of funds used by the enterprise in recent years.

[0127] Data anonymization and encryption: Masking or encrypting sensitive fields to ensure data security.

[0128] Rule execution context assembly and triggering. After the complete data preparation pipeline process described above, a fully data-complete, formatted, and information-enhanced EngineContext object is finally assembled. This object, as the sole input to the rule, is formally submitted to the core executor of the LiteFlow rule engine. The engine loads the corresponding rule chain based on the process ID and begins driving the predefined risk control component sequence to execute sequentially or in parallel, ultimately producing a unified risk decision.

[0129] This time-series design breaks down complex risk control logic into two clear phases: "data preparation" and "rule execution." It achieves strong constraints and self-description through JSONSchema and unlimited flexibility through an extension mechanism. This ensures stable and efficient execution of core rules while perfectly addressing the challenges of diverse, volatile, and complex business data. It is a key technical architecture for realizing an enterprise-level, maintainable, and evolvable risk control system.

[0130] The key point of this embodiment is to transform the traditional "static, retroactive, and isolated" risk control model into a new paradigm that is "dynamic, embedded, and adjustable in real time." Its technological essence lies in the deep integration of "front-end process management" and "real-time control," specifically manifested in the fact that risk control points are embedded in the process definition as first-class citizens and can be dynamically managed during operation.

[0131] This embodiment significantly improves the real-time performance and accuracy of risk control, effectively reducing risk losses and achieving a leap from "post-event analysis" to "real-time intervention during the event." Because risk control actions are precisely triggered within the transaction process, the blocking or challenge of risky transactions can be completed before actual losses occur (such as fund transfers or goods shipments).

[0132] Compared to the shortcomings of the existing technical solution 1, where risk control decisions lag behind the main process, this embodiment can improve the timing of risk transaction identification and handling from "second-level or even minute-level post-event response" to "millisecond-level real-time response within the process." This greatly shortens the attack window, and its prevention and control effect is particularly significant for instantaneous risks such as payment fraud and "wool-pulling" (a term used to describe exploiting promotional offers).

[0133] The system's processing efficiency and resource utilization have been significantly optimized. Through dynamic adjustment capabilities, the system can activate high-computational-complexity risk control points only for high-risk transactions or during high-risk periods, while skipping or performing only lightweight checks for a large number of low-risk transactions.

[0134] Suppose a platform's existing risk control solution (such as the background technical solution 2) executes 5 fixed risk control rules for 100% of transactions, resulting in a total computational load of 100% * 5 units = 500 units. With this invention, through dynamic adjustment, only 20% of high-risk transactions may require the execution of all 5 rules, while the remaining 80% of transactions will execute only one lightweight rule on average. The total computational load then drops to (20% * 5) + (80% * 1) = 1.8 units. Theoretically, the overall computational load of the risk control module can be reduced by more than 60%, which not only saves server CPU and memory resources but also directly reduces the average transaction latency caused by risk control checks.

[0135] The flexibility and adaptability of risk control strategies have been greatly enhanced. The "hot-swappable" dynamic updates of risk control points and strategies have transformed the risk control system from a rigid system into a highly flexible and rapidly iterative intelligent system.

[0136] Example scenario: When a new type of "script attack" is detected, operations and maintenance personnel do not need to shut down the service or release a new version. They can simply use the control center to dynamically enable a new "behavioral trajectory analysis" risk control point for all transaction process "login" nodes in real time. After the attack ends, it can be immediately disabled. This capability shortens the iteration cycle of risk control strategies from the "week / day" level to the "minute / second" level, greatly enhancing the ability to respond quickly to unknown and sudden risks.

[0137] The user experience has been significantly improved, and more precise risk control means a substantial reduction in interference with normal users.

[0138] Since most low-risk transactions no longer require cumbersome secondary verification or security challenges, the success rate of transactions for normal users has increased, and the transaction process is smoother. This directly improves user satisfaction and the platform's service quality, and avoids customer churn caused by "false positives" in risk control strategies.

[0139] The system maintainability and operating costs are reduced. The risk control logic is managed in the form of configurable "points" and is clearly bound to the business process, making the deployment, testing and rollback of risk control rules simple and controllable.

[0140] Feature Analysis: Developers and risk control operations personnel can more intuitively understand and manage risk control logic, reducing system complexity and maintenance difficulty. Simultaneously, due to savings in computing resources and increased development efficiency, enterprise IT operating costs and labor costs are effectively reduced.

[0141] In one embodiment, a transaction risk control device based on process management is provided, comprising:

[0142] The risk control microservice is used to receive transaction risk control requests, determine process identifiers, obtain risk control input data based on the risk control data model configuration associated with the process identifiers, construct rule execution context objects, and output risk control results.

[0143] The rule configuration center is used to store the rule chain definitions corresponding to the process identifier and supports publishing and updating them, and is also used to store dynamic script components;

[0144] The rule execution engine is used to load and parse the rule chain definition based on the process identifier, so as to drive multiple risk control component nodes to process the rule execution context object;

[0145] The execution pipeline storage module is used to store execution data corresponding to risk control results;

[0146] The rule chain definition is stored in a configurable form and separated from the application. When the rule chain definition is updated and reloaded, the rule execution engine selects the rule chain definition based on the rule version number to handle the incoming transaction risk control request.

[0147] The specific implementation details of each module can be found in the above description of the limitations of the process management-based transaction risk control method, and will not be repeated here.

[0148] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

Claims

1. A transaction risk control method based on process management, characterized in that, The method includes: Receive a transaction risk control request, the transaction risk control request carrying transaction data and request context information; Determine the process identifier corresponding to the transaction risk control request based on the request context information; Risk control input data is obtained based on the risk control data model configuration associated with the process identifier; A rule execution context object is constructed based on the aforementioned risk control input data; The rule execution engine loads the rule chain definition corresponding to the process identifier based on the process identifier, and parses the rule chain definition to drive multiple risk control component nodes to process the rule execution context object to obtain the risk control result; Output the risk control results and record the execution data corresponding to the risk control results; The rule chain definition is stored in a configurable form in the rule configuration center and is separated from the application. When the rule configuration center publishes an updated rule chain definition and triggers reload, the rule execution engine selects the rule chain definition based on the rule version number to process the incoming transaction risk control request.

2. The method according to claim 1, characterized in that, After determining the process identifier, the method includes: Based on the business type, event type, model type identifier and / or rule hit information in the request context information, one or more risk control data models to be used in this transaction risk control request are dynamically determined, and the one or more risk control data models are associated with the process identifier.

3. The method according to claim 1, characterized in that, The risk control input data obtained includes: Based on the field extraction rules configured in the risk control data model, field values ​​are located and extracted from the transaction data and / or external data sources to form structured input data; The structured input data is validated based on the data structure constraints corresponding to the risk control data model. After the verification is passed, the structured input data is preprocessed to obtain the risk control input data.

4. The method according to claim 3, characterized in that, The field extraction rules include JSONPath rules, and the fields are located and their values ​​are extracted from the transaction data according to the JSONPath rules.

5. The method according to claim 3, characterized in that, The data structure constraints are generated using JSONSchema, and the validation includes: field type validation, field format validation, field value range validation, required field validation, and field dependency validation; when the validation fails, the rule chain processing for this transaction risk control request is terminated and an error message is returned.

6. The method according to claim 3, characterized in that, The preprocessing is performed through a preprocessing extension plugin, and the preprocessing extension plugin performs the following operations: Call external interfaces to supplement dynamic data; Map business fields to internal standard fields and / or perform unit conversions; Calculate derived variables based on extracted fields; Mask and / or encrypt sensitive fields.

7. The method according to claim 1, characterized in that, The loading and parsing rule chain definition includes: Read the rule chain definition stored in JSON format from the database; The rule chain definition is parsed according to the domain-specific language (DSL). The multiple risk control component nodes are driven to execute according to the component node arrangement relationship formed by the THEN, WHEN and / or SWITCH logical operators in the DSL.

8. The method according to claim 1, characterized in that, When the rule chain definition indicates the existence of parallel orchestration, including: Risk control component nodes that are declared to be executed in parallel based on the WHEN keyword; Create a separate copy of the rule execution context object for each transaction risk control request; After parallel execution is completed, the data generated by parallel execution is merged, and the merged data is written to the rule execution context object.

9. The method according to claim 1, characterized in that, The method further includes: In the rule configuration center, a rule chain list and a script table are maintained respectively. The rule chain list is used to store rule chain definitions, and the script table is used to store dynamic script components. After publishing the rule chain definition and / or dynamic script component in the rule management backend, a reload notification is sent to the risk control microservice via an HTTP request; Upon receiving the reload notification, the risk control microservice triggers the rule execution engine to reload the rule chain definition and / or dynamic script components. Write the request identifier into the rule execution context object, and write at least a portion of the contents of the rule execution context object into the execution flow table.

10. A transaction risk control system based on process management, characterized in that, include: The risk control microservice is used to receive transaction risk control requests, determine process identifiers, obtain risk control input data based on the risk control data model configuration associated with the process identifiers, construct rule execution context objects, and output risk control results. The rule configuration center is used to store the rule chain definitions corresponding to the process identifier and supports publishing and updating them, and is also used to store dynamic script components; The rule execution engine is used to load and parse the rule chain definition based on the process identifier, so as to drive multiple risk control component nodes to process the rule execution context object; The execution pipeline storage module is used to store execution data corresponding to risk control results; The rule chain definition is stored in a configurable form and separated from the application. When the rule chain definition is updated and reloaded, the rule execution engine selects the rule chain definition based on the rule version number to handle the incoming transaction risk control request.

Images