Risk control policy node traffic processing method, system, device and medium

Abstract

This application relates to the fields of financial technology and risk control technology, and in particular to a method, system, device, and medium for processing traffic of risk control strategy nodes, in order to improve the efficiency and accuracy of risk control decisions. The method includes: identifying the strategy set unit to be verified; intercepting the original requests of the risk control strategy nodes; classifying the intercepted traffic into target traffic related to the strategy set unit based on business rules, user attributes, and request characteristics, where the relevant characteristics are the business attributes, node associations, user features, or request logic of the traffic, matching the verification requirements of the strategy set unit; executing a traffic replication strategy based on the classification results: if overall verification of the strategy set unit is selected, the execution traffic of all risk control strategy nodes within the strategy set unit is replicated; if verification of specific nodes is selected, only the execution traffic of the single or multiple risk control strategy nodes selected by the user is replicated; and sending the replicated traffic to an asynchronous processing queue for bypass verification of the strategy set unit.

Description

Technical Field

[0001] This application relates to the fields of financial technology and risk control technology, and in particular to a method, system, device and medium for processing traffic at a risk control strategy node. Background Technology

[0002] In current financial operations, a single risk control decision-making process needs to rely on the collaborative completion of multiple risk control strategy nodes with different functions. For example, from user identity verification to risk value calculation and then to the final decision output, multiple nodes need to be executed sequentially or in conjunction.

[0003] Existing technologies have key limitations in supporting multi-node collaborative risk control decisions: multiple risk control strategy nodes involved in the decision-making process typically exist independently only according to their functional types; furthermore, the representation of relationships between nodes is relatively simplified, generally only recording direct call information between nodes. This limitation directly leads to the system's inability to accurately determine the appropriate execution order of all nodes during risk control strategy scheduling, easily resulting in deviations in the timing of some node executions and incomplete calls between related nodes. This, in turn, reduces the efficiency of risk control decisions and may even lead to inaccurate decision results, failing to meet the stability and reliability requirements of risk control systems in financial scenarios. Summary of the Invention

[0004] This application provides a method, system, device, and medium for traffic processing of risk control strategy nodes, mainly to solve the technical problem of reduced efficiency in traditional risk control decision-making, and even inaccurate decision results.

[0005] A method for handling traffic at a risk control strategy node, comprising: The strategy set unit to be verified is determined. The strategy set unit includes multiple risk control strategy nodes with business relevance. The strategy set unit records the execution dependency relationship and organizational hierarchy information between each risk control strategy node. The organizational hierarchy information is used to describe the hierarchical relationship between each risk control strategy node or each sub-set unit within the strategy set unit. Intercept the original requests of the risk control strategy node. The original request is the initial business request that triggers the risk control process in the financial business scenario. Based on business rules, user attributes, and request characteristics, the intercepted traffic is classified into target traffic related to the policy set unit. The related characteristics are the business attributes, node associations, user characteristics, or request logic of the traffic, which match the verification requirements of the policy set unit. The traffic replication strategy is executed based on the classification results: if the strategy set unit is selected for overall verification, the execution traffic of all risk control strategy nodes within the strategy set unit is replicated; if the specific node is selected for verification, only the execution traffic of the single or multiple risk control strategy nodes selected by the user is replicated. The copied traffic is sent to an asynchronous processing queue for bypass verification of the policy set unit.

[0006] A traffic processing system for risk control strategy nodes includes a strategy set unit management and scheduling module, which comprises: The strategy processing submodule is used to determine the strategy set unit to be verified. The strategy set unit includes multiple risk control strategy nodes with business relevance. The strategy set unit records the execution dependency relationship and organizational hierarchy information between each risk control strategy node. The organizational hierarchy information is used to describe the hierarchical relationship between each risk control strategy node or each sub-set unit within the strategy set unit. The traffic processing submodule is used to intercept the original requests of risk control strategy nodes. The original requests are the initial business requests that trigger the risk control process in financial business scenarios. Based on business rules, user attributes, and request characteristics, the intercepted traffic is classified into target traffic related to the strategy set unit. The related characteristics are the business attributes, node associations, user characteristics, or request logic of the traffic, which match the verification requirements of the strategy set unit. Based on the classification results, the traffic replication strategy is executed: if the strategy set unit is selected for overall verification, the execution traffic of all risk control strategy nodes within the strategy set unit is replicated; if the specific node is selected for verification, only the execution traffic of the single or multiple risk control strategy nodes selected by the user is replicated. The replicated traffic is sent to the asynchronous processing queue for bypass verification of the strategy set unit.

[0007] A computer device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement a traffic processing method for a risk control strategy node of any of the foregoing.

[0008] A computer-readable storage medium storing a computer program that, when executed by a processor, implements a traffic processing method for a risk control strategy node as described in any of the preceding claims.

[0009] One of the solutions provided in this application offers a traffic processing method for risk control strategy nodes. Through business-related combination and hierarchical organization, dispersed risk control strategy nodes are integrated into a logically unified set of units. This addresses the fragmentation problem of independent management of individual nodes and simplifies the maintenance process of complex risk control systems. A dependency graph constructed using a directed acyclic graph clearly presents the direct and indirect dependencies between nodes, fundamentally avoiding execution deadlocks caused by node dependencies and ensuring the rigor of the risk control process logic. Furthermore, the modular organization allows strategy changes to be implemented only on the relevant nodes within the set of units. Combined with the dependency graph, the impact of changes can be quickly assessed, reducing interference with the overall risk control system. This enables accurate determination of the appropriate execution order of all nodes, reducing situations such as execution timing deviations of some nodes and incomplete calls to related nodes, thereby improving the efficiency and accuracy of risk control decisions and meeting the requirements of financial scenarios for the stability and reliability of risk control systems and decisions. Attached Figure Description

[0010] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the description of the embodiments of this application will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 This is a flowchart illustrating a traffic processing method for a risk control strategy node in one embodiment of this application; Figure 2 This is a flowchart illustrating traffic replication in a traffic processing method for a risk control strategy node according to an embodiment of this application; Figure 3 This is a schematic diagram of the structure of a traffic processing system for a risk control strategy node in one embodiment of this application; Figure 4 This is a schematic diagram of the structure of a computer device according to one embodiment of this application. Detailed Implementation

[0012] To make the technical problems, technical solutions, and beneficial effects solved by 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.

[0013] This application provides a traffic processing system and method for a risk control strategy node, wherein the traffic processing system for the risk control strategy node mainly includes the following core technical components or modules: An innovative strategy set unit concept was designed, organizing related risk control strategy nodes into logical sets to achieve modular management and batch verification of risk control strategy nodes. The strategy set unit management and scheduling engine supports package-level version management, dependency analysis, and impact assessment. The system maintains metadata information for strategy set units, including a list of strategy nodes, dependency graphs, version history, and performance metrics. The strategy set unit also supports nested structures and inheritance relationships, enabling hierarchical management of complex strategy systems.

[0014] A traffic replication architecture can be designed based on the proxy and decorator patterns, accurately replicating the execution traffic of specific nodes without affecting the original decision-making process. Traffic replication supports two modes: policy set unit bypass and specified node bypass. Policy set unit bypass replicates traffic to all policy nodes within the entire policy set unit, while specified node bypass allows users to select a specific node for precise verification. The replication process employs an asynchronous, non-blocking mode, ensuring zero interference with the original business process.

[0015] In one embodiment, a traffic processing system for risk control strategy nodes is provided. Based on business relevance, multiple risk control strategy nodes are combined to form a strategy organization model. The strategy organization model includes a list of strategy nodes, node types, node configuration parameters, and organizational hierarchy information. The organizational hierarchy information is used to describe the hierarchical relationship between each risk control strategy node or each sub-unit within a strategy set unit. The strategy set unit is formed by combining risk control strategy nodes with business relevance. Then, based on the strategy organization model, the full lifecycle processing of the strategy set unit can be realized.

[0016] In one embodiment, such as Figure 2 As shown, a traffic processing method for a risk control strategy node is provided, which further includes the following steps: S100. Determine the strategy set unit to be verified. The strategy set unit includes multiple risk control strategy nodes with business relevance. The strategy set unit records the execution dependency relationship and organizational hierarchy information between each risk control strategy node. The organizational hierarchy information is used to describe the hierarchical relationship between each risk control strategy node or each sub-set unit within the strategy set unit. S101. Execute traffic interception on the original request of the risk control strategy node. The original request is the initial business request that triggers the risk control process in the financial business scenario. S102. Based on business rules, user attributes, and request characteristics, the intercepted traffic is classified into target traffic related to the policy set unit. The related characteristics are the business attributes, node associations, user characteristics, or request logic of the traffic, which match the verification requirements of the policy set unit. S103. Execute the traffic replication strategy based on the classification results: S1031. If you choose to perform overall verification on the strategy set unit, then copy the execution traffic of all risk control strategy nodes within the strategy set unit. S1032. If you choose to verify a specific node, then only the execution traffic of the single or multiple risk control strategy nodes selected by the user will be copied. S104. Send the copied traffic to the asynchronous processing queue for bypass verification of the policy set unit.

[0017] In this embodiment, the strategy set unit (e.g., a "package") is a management unit formed by combining multiple risk control strategy nodes with business relevance. It is used to achieve modular organization, batch management, and unified verification of risk control strategies. The strategy set unit includes multiple risk control strategy nodes with business relevance. The strategy set unit internally records the execution dependencies and organizational hierarchy information between each risk control strategy node. The organizational hierarchy information describes the hierarchical relationships between each risk control strategy node or sub-set unit within the strategy set unit. For example, in determining business relevance, related strategy nodes need to be screened. For example, in a financial credit risk control scenario, risk control strategy nodes with business relevance are screened, such as nodes related to identity verification, credit assessment, risk calculation, and decision-making, ensuring that the node combination revolves around the same risk control objective (e.g., personal loan approval risk control).

[0018] The original request is the initial business request that triggers the risk control process in a financial business scenario. It contains core information such as user identity, business type, and request parameters, and serves as the data source for the execution of risk control strategy nodes, such as personal loan approval requests and credit card transaction requests. Capturing the original request data without interrupting the original request processing ensures that subsequent copying and verification operations do not affect the original business process, achieving non-intrusive traffic interception. Target traffic refers to the intercepted traffic that matches the verification requirements of the strategy set unit. It must meet the requirements that the business attributes, node associations, user characteristics, or request logic are consistent with the core functions of the strategy set unit, excluding irrelevant business traffic. Based on the traffic copying scope rules determined by the verification requirements, it is divided into two categories: overall verification of the strategy set unit (copying traffic from all nodes within the set) and specific node verification (copying only traffic from one or more nodes selected by the user), corresponding to bypass and specified node bypass modes.

[0019] The asynchronous processing queue is a buffer component used to temporarily store replication traffic. It transmits replication traffic to the bypass verification environment in an asynchronous, non-blocking manner, avoiding the replication operation from consuming the processing resources of the original request. End-to-end tracing refers to associating the original request traffic and the replication traffic through a globally unique identifier (such as TraceID), recording the complete link from request initiation to node execution, ensuring the traceability of the traffic processing process, and realizing distributed tracing.

[0020] For example, in a personal loan approval scenario, a strategy set unit (credit risk control package) is formed based on business relevance, containing 5 core nodes: data collection node A (collecting user identity / income data), identity verification node B (verifying identity authenticity), credit assessment node C (calculating credit score), risk calculation node D (outputting risk level), and decision judgment node E (outputting approval result); a dependency graph is constructed: A→B→C→D→E, clarifying the execution logic of each node; the traffic processing logic of this embodiment needs to provide real production traffic support for the bypass verification of the credit risk control package to ensure that the verification results are consistent with the actual business scenario.

[0021] First, traffic interception is performed on the original requests to the risk control strategy nodes. A dual interception scheme of application layer + network layer can be adopted to ensure complete capture of the original request data, wherein: Application layer interception: Based on AOP (Aspect-Oriented Programming) technology, traffic capture logic can be inserted before and after the execution of the core interface of the credit approval business without modifying the original business code, and capture data such as request headers (such as user ID, request time) and request bodies (such as user identity information, application amount); Network layer interception: The network packets of this interface can be captured at the kernel level using the TC (TrafficControl) tool, as a supplement to application layer interception, to prevent traffic loss caused by application layer anomalies; The interception operation adopts a seamless mode, meaning that the original request flows normally to the data collection node A, and traffic capture is only a mirror copy, without blocking or modifying the original request content, thus ensuring the original business process (such as when a user submits an approval request, risk control processing can be started without waiting for the interception to complete).

[0022] Based on the verification requirements of the credit risk control package, target traffic is filtered from the following dimensions: Business attributes: Only retain personal credit approval requests, and exclude irrelevant business traffic such as credit card bill inquiries and loan repayments; Node association: Requests that need to go through all nodes of the credit risk control package (A→B→C→D→E) are retained, while simplified process requests that only trigger some nodes are excluded (such as internal test requests that only trigger nodes A and B). User characteristics: Retain real user requests (verified by user ID format, excluding test account IDs). Categorized execution and filtering: The system automatically performs multi-dimensional matching on the intercepted traffic. For example, traffic that meets the criteria of interface path / credit / apply + need to execute the full AE node + user ID in real format is determined to be target traffic; traffic that does not meet any of the criteria (such as only executing AB nodes) is marked as "non-target traffic" and will not enter the subsequent replication process, but will be directly discarded to save resources.

[0023] Scenario 1: Overall Validation of the Strategy Set Unit. Validation Requirements: The system needs to verify the compliance of draft rules for all nodes (A→B→C→D→E) within the credit risk control package, and replicate the execution traffic of all nodes within the package. Based on the dependency graph, the system captures complete execution data of the target traffic at each node: including the data collected by A, the verification results by B, the credit score by C, the risk level by D, and the approval results by E. The replication process maintains logical consistency: for example, if the target traffic collects user income of 8000 yuan at node A, the replicated traffic simultaneously retains this data, ensuring that subsequent replication executions at nodes B and C are based on the same input; a replicated traffic list is generated, clearly indicating the overall validation – including nodes A / B / C / D / E – to avoid missing nodes.

[0024] Scenario 2: Specific Node Verification. Only the draft version rules of credit assessment node C and risk calculation node D within the credit risk control package need to be verified (such as adjusting the credit score calculation logic of C and the risk level threshold of D), without copying traffic from other nodes; users select the nodes (C and D) to be verified through the system configuration interface. Only capture the execution data of the target traffic at nodes C and D: including the input of C (output of A / B), the output of C (credit score), the input of D (output of C), and the output of D (risk level). Do not copy the traffic data of nodes A, B, and E. Generate a list of replicated traffic, marking specific node verification - only including nodes C / D to avoid invalid replication. Encapsulate half of the replicated traffic in the above scenario into a standardized data format (such as JSON) according to the node execution order, including node identifier, input and output data, and timestamp; send it to the Apache Kafka asynchronous processing queue, which is partitioned by policy set unit ID (such as the partition "lebao_credit" for credit risk control), to ensure that replicated traffic is delivered to the bypass verification environment in an orderly manner; the processing of the original request and the replicated traffic is completely decoupled: the original request proceeds normally to node E to output the approval result (such as approval passed), and the replicated traffic waits for bypass verification in the queue, without affecting each other; assign a globally unique TraceID (such as "Trace_20240601_12345") to each original request, and the replicated traffic inherits this TraceID and adds a replication identifier (such as copy=true). The system records the complete link associated with TraceID: Original traffic link: User initiates request → A → B → C → D → E → Output result (TraceID=Trace_20240601_12345); Replicated traffic link: Asynchronous queue reception → Bypass environment A (Scenario 1 only) → Bypass environment B (Scenario 1 only) → Bypass environment C → Bypass environment D → Bypass environment E (Scenario 1 only) → Verification result storage; By entering TraceID in the system link tracing interface, you can simultaneously view the node execution status, time consumption, and input / output data of both the original and replicated traffic, which is convenient for subsequent comparison and verification of results and troubleshooting.

[0025] In this embodiment, the asynchronous, non-blocking traffic interception and replication mechanism ensures that the processing speed and success rate of the original request (such as credit approval) are not affected. For example, the original request still outputs results in the normal time (≤500 milliseconds), avoiding user waiting or business interruption due to traffic replication. The target traffic filtering mechanism ensures that only real production traffic (such as real user credit applications) that matches the policy set unit is used for verification, and the verification results are more in line with the actual business scenario. Specific node verification only replicates the traffic of selected nodes (such as CD), which reduces the amount of traffic data compared to full node replication and reduces the resource consumption of asynchronous queues and bypass environments; at the same time, end-to-end tracking can quickly locate abnormal nodes of replicated traffic (such as missing data in C node replication), reducing investigation time and improving verification efficiency.

[0026] The following section primarily focuses on the policy set unit management and scheduling module within the traffic processing system of this risk control strategy node, introducing its corresponding processing methods, such as... Figure 1 As shown in the embodiment of this application, a traffic processing method for a risk control strategy node is provided. Before step 100, that is, before determining the strategy set unit to be verified, the method includes the following steps: S10. Based on business relevance, multiple risk control strategy nodes are combined to form a strategy organization model. The strategy organization model includes a list of strategy nodes, node types, node configuration parameters, and organizational hierarchy information. The organizational hierarchy information is used to describe the hierarchical relationship between each risk control strategy node within a strategy set unit or between each sub-set unit. The strategy set unit is formed by combining risk control strategy nodes with business relevance. S20. Construct a dependency graph for the strategy organization model, represented by a directed acyclic graph. The dependency structure is used to describe the direct and indirect dependencies between risk control strategy nodes. Direct dependencies represent single-level dependencies between risk control strategy nodes based on direct call relationships, while indirect dependencies represent multi-level dependency links formed across multiple risk control strategy nodes. S30. Schedule and process risk control strategy nodes based on dependency graph.

[0027] A strategy organization model is a standardized model describing the structure of strategy set units. It includes a list of strategy nodes, node types, node configuration parameters, and organizational hierarchy information, serving as a digital representation of strategy set units. Organizational hierarchy information defines the internal structural relationships within strategy set units, clarifying the hierarchical affiliation between risk control strategy nodes or sub-units, and can be used to support nested hierarchical management.

[0028] A dependency graph is a visual model constructed in the form of a directed acyclic graph (DAG) to accurately describe the dependency relationships between risk control strategy nodes, ensuring that there are no circular conflicts in the execution logic of the nodes. Direct dependencies are single-level dependencies established between risk control strategy nodes based on direct invocation behavior. For example, node B can only be triggered after node A completes its execution; thus, they constitute a direct dependency. Indirect dependencies are multi-level dependency chains formed across multiple risk control strategy nodes. For example, if node A depends on node B, and node B depends on node C, then node A and node C constitute an indirect dependency.

[0029] In this embodiment, a strategy organization model is first formed based on business relevance. During this process, related strategy nodes need to be selected. For example, in a financial credit risk control scenario, risk control strategy nodes with business relevance are selected, such as nodes related to identity verification, credit assessment, risk calculation, and decision-making, ensuring that the node combination revolves around the same risk control objective (such as personal loan approval risk control).

[0030] The core elements of the model may include: The strategy node list lists all node identifiers and core functions included in the set, such as identity verification nodes, income assessment nodes, and fraud detection nodes; The node type indicates the functional type of each node, such as identity verification, credit assessment, risk calculation, etc. The node configuration parameters record the operating parameters of each node, such as risk threshold, calculation weight, data input and output format, etc. Organizational hierarchy information determines the hierarchical relationship between nodes and can support nested structures. For example, a credit assessment subset can be used as a first-level node, which includes second-level nodes such as income assessment nodes and debt calculation nodes.

[0031] The above elements are integrated into a standardized strategy organization model, stored in the system database, and associated with a unique identifier for easy subsequent management.

[0032] Analyze the execution logic of each node in the strategy organization model, clarifying direct dependencies. For example, the decision-making node must wait for the risk calculation node's output before execution, thus forming a direct dependency. Derive indirect dependencies through these direct dependency links; for instance, the decision-making node indirectly depends on the data collection node through the risk calculation node. Construct a dependency graph with nodes as vertices and dependencies as directed edges. For example, the vertices are arranged in the order of data collection node → identity verification node → credit assessment node → risk calculation node → decision-making node, with the edges following the dependency order to ensure the graph is free of loops (i.e., there is no path from a node back to itself). Check if the graph meets the requirement of directed acyclicity. If circular dependencies are found (e.g., node A depends on node B, and node B depends on node A), adjust the node logic or... Decompose dependencies to ensure compliance with the dependency graph. Based on the dependency graph, define the execution order rules for nodes: downstream nodes can only start after all preceding dependent nodes (directly or indirectly dependent upstream nodes) have completed execution. Finally, schedule risk control strategy nodes based on this dependency graph. For example, when a user credit approval request is received, the dependency graph corresponding to the strategy organization model is invoked, triggering node execution in the order of upstream node → downstream node. For example, the data collection node is executed first, followed by the identity verification node and credit assessment node, and finally the decision judgment node. During this process, the execution status of each node (e.g., pending execution, executing, successful execution, failed execution) can be synchronized in real time, and the executable status of subsequent nodes is dynamically updated based on the dependency graph to ensure consistency between scheduling logic and dependencies.

[0033] As can be seen, this embodiment provides a method for handling traffic of risk control strategy nodes. By combining business-related elements and organizing hierarchically, it integrates scattered risk control strategy nodes into a logically unified set of units. This addresses the fragmentation problem of individual node management and simplifies the maintenance process of complex risk control systems. The dependency graph constructed from a directed acyclic graph clearly presents the direct and indirect dependencies between nodes, fundamentally avoiding execution deadlocks caused by node dependencies and ensuring the rigor of the risk control process logic. Furthermore, the modular organization allows strategy changes to be implemented only on the relevant nodes within the set of units. Combined with the dependency graph, the impact of changes can be quickly assessed, reducing interference with the overall risk control system and meeting the dual requirements of stability and flexibility in financial risk control scenarios.

[0034] It should be noted that this invention innovatively proposes the concept of a strategy set unit, organizing related strategy nodes into logical sets to achieve modular management, version control, and batch verification of strategies. The strategy set unit supports nested structures and dependency analysis, providing a systematic management solution for complex risk control systems. Compared to traditional methods, management efficiency is improved by more than double, and the impact analysis time for strategy changes is reduced from hours to minutes.

[0035] In one embodiment, step S30, namely, scheduling the risk control strategy nodes based on the dependency graph, includes the following steps: S31. Analyze the dependency constraints between nodes in the dependency graph using the topological sorting algorithm to generate a basic execution sequence that satisfies the condition of executing the preceding dependent nodes first and the subsequent dependent nodes. S32. Calculate the earliest execution time, latest execution time, and path length of each risk control strategy node in the basic execution sequence to determine the optimal execution sequence; S33. Perform dependency conflict detection on the risk control strategy nodes in the optimal execution sequence, and classify the risk control strategy nodes that meet the conditions into a set that can be executed in parallel. S34. Dynamically group the set of parallel executions based on node resource requirements, node business relevance, and node dependency status. S35. When a group satisfies the conditions that all the prerequisite nodes of all nodes in the group have been executed and the system resources are adapted, the execution process of the group is started.

[0036] In this embodiment, the topology sorting algorithm is an algorithm that traverses the dependency graph (directed acyclic graph). By following the rule of prioritizing the execution of preceding dependent nodes, it generates a node execution order without dependency conflicts, which is the core idea for determining the basic execution sequence. The earliest execution time is the earliest time a risk control strategy node can start immediately after all preceding dependent nodes have completed execution; this needs to be calculated by combining the execution time of preceding nodes and the data transmission time between nodes. The latest execution time is the latest time a risk control strategy node can delay starting to avoid affecting the execution progress of subsequent nodes; it is determined by reverse derivation of the critical path (longest execution path). The path length is the total execution time of a node's execution path in the dependency graph, i.e., the sum of the execution time of all nodes on the path and the waiting time between nodes, used to identify the critical path. After dependency conflict detection, a set of risk control strategy nodes with no direct / indirect dependencies is identified. These nodes can be executed in parallel within the same time period, improving overall processing efficiency. Dynamic grouping is a flexible grouping of the set of nodes that can be executed in parallel based on node resource requirements (CPU, memory, etc.), business relevance (such as belonging to the credit assessment module), and dependency status (whether the preceding node has been completed), ensuring that the execution resources of the nodes within the group are adapted and there are no conflicts.

[0037] To facilitate understanding, a specific scenario is used as an example. In this embodiment, the strategy nodes of a personal credit risk control scenario (such as data collection node A, identity verification node B, income assessment node C, debt calculation node D, risk scoring node E, and decision-making node F) are combined to form a strategy organization model (named Credit Risk Control Package). After analysis, the node dependencies are "A→B, A→C, B→E, C→D, D→E, E→F", forming a directed acyclic graph without closed loops. The dependency graph is traversed according to the priority rule of preceding dependent nodes. Specifically, the logic is as follows: first, nodes without preceding dependencies (only data collection node A) are selected and used as... The sequence begins by removing node A and its edges (A→B, A→C). At this point, node B (identity verification) and node C (income assessment) are added to the sequence, having no prior dependencies. Node B and its edges (B→E) and node C and its edges (C→D) are removed. Node D (liability calculation) is added to the sequence, having no prior dependencies. Node D and its edges (D→E) are removed. Node E (risk scoring) is added to the sequence, having no prior dependencies. Finally, decision node F is added, generating the basic execution sequence: A→[B,C]→D→E→F (square brackets indicate parallel nodes with no dependencies). All nodes in the sequence are confirmed to have prior dependencies, with no dependency conflicts. For example, node E's prior nodes B and D are both preceding it, conforming to the execution logic. Based on historical execution data, the execution time for each node is set (in milliseconds): A=100, B=80, C=120, D=60, E=150, F=50; data transmission time between nodes is ignored.

[0038] Calculate the earliest execution time: A: Earliest = 0 (no prerequisites); B: Earliest = A execution completion time = 100; C: Earliest = A execution completion time = 100; D: Earliest = C execution completion time = 100 + 120 = 220; E: Earliest = max(Completion time of B, completion time of D) = max(100+80=180,220) = 220; F: Earliest completion time = E completion time = 220 + 150 = 370.

[0039] Calculate the latest execution time (reverse derivation, based on the latest execution time of F = earliest execution time = 370): F: Latest = 370; E: Latest = F Latest - F Duration = 370 - 50 = 320; D: Latest = Latest E - E Time = 320 - 150 = 170 (D completion time must be ≤ E earliest start time 220, here 170 ≤ 220, valid). C: Latest = Latest D - D Time Spent = 170 - 60 = 110; B: Latest = ELatest - ETime = 320 - 150 = 170; A: Latest = min(B latest, C latest) - its own time = min(170, 110) - 100 = 10 (must be ≥0 to be valid).

[0040] Path length analysis reveals the critical path (longest-running path) to be "A→C→D→E→F" (total execution time = 100+120+60+150+50 = 480 milliseconds). Priority should be given to ensuring the execution resources of critical path nodes. Meanwhile, non-critical path node (B) has time redundancy (latest execution time 170 - earliest execution time 100 = 70 milliseconds), allowing for flexible adjustment of its start time, but ensuring that it does not affect the execution of node E. The final optimal execution sequence remains A→[B,C]→D→E→F, but the critical path node must be prioritized for scheduling.

[0041] Traverse the nodes in the optimal execution sequence and determine whether there are direct / indirect dependencies between the nodes. If there are no dependencies, they can be classified into a set that can be executed in parallel.

[0042] In the sequence, A has no prior dependencies, executes independently, and has no parallel nodes; B and C: No direct dependency (B is a prerequisite for A, and C is a prerequisite for A), no indirect dependency (B does not depend on C, and C does not depend on B), no conflict, and are classified as the set that can be executed in parallel {B,C}. D is preceded by C, and can only be executed after C is completed; there are no parallel nodes. E is preceded by B and D, and can only be executed after B and D are completed; there are no parallel nodes. F is preceded by E, and can only be executed after E is completed; there are no parallel nodes.

[0043] The output can be executed in parallel: {B, C}, and the remaining nodes are executed serially.

[0044] Next, the set of parallelizable executions is dynamically grouped based on multi-dimensional conditions. Grouping criteria analysis: Node resource requirements: B (identity verification) requires 10% CPU usage and 50MB memory; C (revenue assessment) requires 15% CPU usage and 80MB memory. The system currently has ≥30% idle CPU and ≥200MB memory to meet resource matching requirements. Node business relevance: B and C both belong to the pre-credit assessment verification module, and their business logic is highly related, so they are suitable to be grouped together; Node dependency state: Both B and C depend on A. After A is executed, both can start, and their dependency states are the same.

[0045] The parallel execution set {B, C} is grouped into the same execution group (Group 1), and the remaining serial nodes (A, D, E, F) are grouped separately according to their execution order (Group 2: A; Group 3: D; Group 4: E; Group 5: F).

[0046] Finally, the group execution process is started when the conditions are met: Group execution condition determination: Group 2 (A): No prerequisites, sufficient system resources (initial state), execution starts, execution takes 100 milliseconds to complete; Group 1 (B, C): The preceding dependent node A must have been completed (triggered after A is completed) and the system resources must be adequate (idle CPU ≥ 25%, memory ≥ 130%, resources are released after A is completed, and the conditions are met). Parallel execution is started. B takes 80 milliseconds and C takes 120 milliseconds (the total time of the group is based on the longer one, C, i.e., 120 milliseconds). Group 3 (D): Requires that the preceding dependent node C has been completed (triggered after C is completed) and resources are adapted (80MB of memory is released after C is completed, and the free resources are sufficient), start execution, which takes 60 milliseconds; Group 4 (E): Requires that the preceding dependent nodes B and D have both completed execution (B completes at 100+80=180 milliseconds, D completes at 100+120+60=280 milliseconds, triggering based on D's completion time) and resources are in place before starting execution, which takes 150 milliseconds. Group 5 (F): Requires that the preceding dependent node E has been completed (E is triggered at 280+150=430 milliseconds) and the resources are adapted before starting execution, which takes 50 milliseconds.

[0047] It should be noted that during the above process, the execution status of each group can be tracked in real time. If a group fails to execute (e.g., C times out), the execution of subsequent dependent groups (D, E, F) will be suspended and handled according to the exception handling logic. If all groups execute successfully, the entire risk control strategy scheduling is completed.

[0048] As can be seen, in this embodiment, topological sorting ensures compliance with the execution order, while identifying parallelizable nodes (such as B / C) to achieve parallel execution. Compared with fully serial execution (total time A→B→C→D→E→F = 100+80+120+60+150+50 = 560 milliseconds), the total time after parallel execution is shortened to 480 milliseconds, improving efficiency by approximately [percentage missing]. Dynamic grouping combined with resource demand adaptation avoids resource waste (such as B / C sharing idle resources without the need for separate redundancy), which meets the high-concurrency processing needs of financial scenarios (such as peak periods for credit approval).

[0049] Critical path analysis (e.g., identifying A→C→D→E→F as the longest path) allows for priority resource allocation, preventing delays at critical nodes from causing overall process timeouts. Calculating the latest execution time provides flexibility for non-critical nodes (e.g., B), ensuring overall progress is not affected while adapting to system resource fluctuations and reducing the risk of execution anomalies. Relying on conflict detection and dynamic grouping, dispersed nodes are integrated according to conflict-free and highly correlated principles. The scheduling logic shifts from managing individual nodes to group management, making it particularly suitable for complex risk control packages containing dozens of nodes (e.g., cross-business line integrated risk control strategies). This significantly reduces management costs and achieves the core goal of batch package management.

[0050] In one embodiment, after constructing a dependency graph represented by a directed acyclic graph for the strategy organization model, the method further includes the following steps: S40. Based on the location of risk control strategy nodes in the dependency graph, direct dependencies, and indirect dependencies, identify key nodes and perform monitoring on key nodes; S50. When a node failure is detected, determine the scope of the failure based on the direct and indirect dependencies of the key nodes, and perform fault isolation on the risk control strategy nodes within the scope of the failure. S60: Based on the preset recovery strategy, perform restart, service migration or data repair on the faulty node, and switch to the standby node when a backup node exists.

[0051] Critical nodes are risk control strategy nodes that occupy a core path in the dependency graph (e.g., common prerequisites for all nodes, numerous downstream nodes) or play a decisive role in the continuity of the overall risk control process. Their failure directly affects the execution of multiple subsequent nodes. Node failure refers to an abnormal state that occurs during the execution of a risk control strategy node, including execution timeouts, data output errors, resource consumption exceeding limits, and service unresponsiveness, causing the node to fail to output valid results. The scope of impact refers to the set of downstream nodes that a node directly or indirectly depends on when it fails; that is, the range of nodes covered by the failure through the dependency chain. Fault isolation refers to the operation of logically isolating the faulty node and its affected nodes from normally executing nodes to prevent the failure from spreading to unaffected nodes and ensure that some risk control processes can still proceed normally. Pre-defined recovery strategies are pre-defined faulty node repair plans, including node restart, service migration (transferring the tasks of the faulty node to other available nodes), data repair (repairing abnormal data required for node execution), and backup node switching (using pre-deployed backup nodes to replace the faulty node).

[0052] Taking personal loan approval risk control scenario as an example, a strategy organization model is formed based on business relevance combination for personal loan approval risk control scenario, which includes 5 core risk control strategy nodes: data collection node A (collects user identity and income data), identity verification node B (verifies the authenticity of user identity), credit assessment node C (calculates user credit score), risk calculation node D (outputs risk level based on credit score), and decision judgment node E (outputs approval result based on risk level); after constructing the dependency graph (directed acyclic graph): the node dependency logic is A→B→C→D→E, where A is the common predecessor of all nodes (directly depends on B, indirectly depends on C, D, and E), D is the direct predecessor of E, and there is no circular dependency between nodes; Specifically, based on the paths and node influence range of the dependency graph, key nodes are selected using the following rules: Common upstream node: A is the direct / indirect upstream of all downstream nodes (B, C, D, E). If A fails, the entire risk control process cannot be started and is identified as a critical node. Nodes with broad downstream coverage: D is directly associated with E (the only downstream node) and is a core link in the critical path A→B→C→D→E. If D fails, E cannot execute and is therefore identified as a critical node. Non-critical nodes were excluded: B is only directly related to C, and C is only directly related to D. The impact of the fault is limited to only one downstream node, so it was determined to be a non-critical node. The critical nodes were finally identified as: data acquisition node A and risk calculation node D.

[0053] For nodes A and D, core operational metrics are collected in real time. These metrics may include execution time (threshold: ≤200 milliseconds), execution success rate (threshold: ≥99.9%), CPU utilization (threshold: ≤30%), memory usage (threshold: ≤100MB), and data output integrity (must include all fields required by downstream nodes). Metric data is refreshed every 100 milliseconds. If a metric exceeds its threshold for three consecutive periods (e.g., the execution time of node D reaches 250 milliseconds for three consecutive periods), the system automatically triggers an alarm (e.g., a pop-up window in the operation interface, log flags), and synchronously records initial fault information (fault node identifier, fault time, abnormal metric value). For example, if risk calculation node D fails to execute due to missing data input (not receiving the credit score field output by node C), and the system detects that the execution success rate of node D drops to 0%, it triggers the fault handling process.

[0054] The downstream node of D is only the decision-making node E (which directly depends on the output of D), and there are no other indirect downstream nodes; the scope of influence is defined as the faulty node D and its downstream node E, i.e., {D,E}. A, B, and C are not within the scope of influence because they do not depend on D.

[0055] Through the system's state isolation mechanism, nodes D and E are marked as fault-isolated, suspending the acceptance of new execution requests. Specifically, for newly received credit approval requests, nodes A, B, and C can still execute normally (completing data collection, identity verification, and credit assessment). However, after reaching node C, because D is in an isolated state, the process automatically pauses at the risk calculation stage, preventing the execution of D and E from being triggered. This releases the CPU and memory resources occupied by D (e.g., terminating D's execution process) to prevent faulty nodes from consuming resources and affecting the normal operation of other nodes (such as A, B, and C). The system node status dashboard is updated in real time, marking D and E as isolated and A, B, and C as normal, allowing maintenance personnel to intuitively understand the scope of the fault.

[0056] By combining the monitoring logs and the execution record of D, the cause of the failure was located: the credit score field output by C had an incorrect data format (it should be a numeric type but it was a character type), which caused D to be unable to parse it, thus causing the execution to fail.

[0057] Execute the default recovery strategy: Step 1: Data Repair (targeting the root cause of the fault): Automatically trigger the data format verification and repair logic of node C, convert the character credit score output by C into a numerical value (e.g., "750" → 750), and re-push the repaired data to D; Step 2: Node restart (for node D): After the data repair is completed, the execution process of node D is automatically restarted, the abnormal execution state of D is cleared, and its ability to receive requests is restored; Step 3: Backup node switching (alternative solution): If D still fails to execute after restarting (e.g., node process is corrupted), the pre-deployed backup node of D (configured with the primary node and synchronizes data in real time) is activated, and the data pushed by C is automatically routed to the backup node, which performs risk calculation. D (or the backup node) successfully receives the repaired data, outputs the risk level normally (e.g., low risk), restores the execution success rate to the set target, and all monitoring indicators meet the threshold requirements; switches the fault isolation status of D and E to the normal state, restores the complete process of new requests (A→B→C→D→E), and automatically triggers the supplementary execution of D for requests that were suspended in the risk calculation stage during the fault, ensuring the continuation of the process.

[0058] As can be seen, in this embodiment, by monitoring key nodes (such as A and D in the example above) in real time, alarms can be triggered in the early stages of node anomalies (such as D's execution time exceeding the limit), preventing the failure from escalating to the point of complete inability to execute; this significantly shortens the fault response time, meeting the high availability requirements of financial risk control scenarios (such as the need for continuous and stable operation of credit approval processes). Fault isolation only isolates {D, E}, while A, B, and C can still process requests normally, preventing a single node failure from causing the entire process to stop; for example, during a fault, new requests can complete data collection and identity verification, and risk calculation can be directly resumed after D recovers, reducing user waiting time and improving business continuity. The preset recovery strategy clearly defines the steps of data repair → node restart → backup switch, eliminating the need for manual troubleshooting; for example, after D fails, data format repair and node restart are automatically completed, significantly reducing credit approval business losses caused by node failures.

[0059] In one embodiment, after step S10, that is, after combining multiple risk control strategy nodes to form a strategy organization model based on business relevance, the following steps are also included: S70. Select any two versions of the strategy set unit for comparison to identify differences in strategy nodes and dependencies. Differences in strategy nodes include newly added or deleted node identifiers and types, and adjustments to the node execution order; differences in dependencies include newly added or deleted dependency links, and changes in the version of dependency nodes. S80. Output a structured difference comparison list, which includes the identified differences in policy nodes and dependencies.

[0060] In this embodiment, the strategy set unit version is an iterative version of the same strategy set unit formed at different development stages. Each version contains a combination of strategy nodes and dependencies at a specific time, such as V1.0 being the initial version and V2.0 being the functional optimization version.

[0061] Strategy node differences refer to the changes in risk control strategy nodes across different versions of the strategy collection unit. This includes the identification and type of newly added or deleted nodes, as well as adjustments to the node execution order. It is one of the core dimensions of version differences. Dependency relationship differences refer to the changes in dependency links between nodes across different versions of the strategy collection unit. This includes the addition or deletion of dependency links, as well as changes to the versions of dependent nodes. It is a key comparison dimension to ensure consistency in execution logic.

[0062] A structured difference comparison list is a standardized document that organizes the identified differences in strategy nodes and dependencies into a preset format (such as a table or hierarchical list). It includes the difference type, the nodes / links involved, and the change details, making it easy to trace version changes intuitively.

[0063] For example, for personal loan approval scenarios, two iterative versions of strategy set units (credit risk control package) are constructed, where: Version V1.0: contains 4 core nodes, with the dependency relationship as follows: data collection node A → identity verification node B → credit assessment node C → decision judgment node D; Version V2.0: based on V1.0, it is optimized, adds risk control functions, and adjusts some node logic; both versions have formed a standardized strategy organization model and a directed acyclic graph dependency relationship graph, and have the basic data for version comparison.

[0064] In this embodiment, two versions of the strategy set unit are selected and the comparison scope is determined. The two versions to be compared are Credit Risk Control Package V1.0 (baseline version) and V2.0 (optimized version). The core metadata of the two versions is extracted to ensure consistency in the comparison benchmark. Version identifiers: V1.0 (released: January 2024), V2.0 (released: June 2024). Strategy set unit identifier: uniformly set as Credit Risk Control Package (ID: LB_Credit_001); Business scenario: All are personal loan approvals, excluding unnecessary comparison items due to differences in scenarios.

[0065] The system automatically traverses the policy node lists of the two versions, and combines this with manual confirmation to identify node additions, deletions, and attribute changes. New node: V2.0 adds a multi-borrowing detection node E (type: risk calculation) to supplement the risk assessment of whether there is multi-platform lending. V1.0 did not have this node. Node deletion: V2.0 deletes manual review trigger node F (original type: decision judgment) from V1.0, because the function of this node has been integrated into decision judgment node D; Node type adjustment: V2.0 changes the type of credit assessment node C in V1.0 from basic assessment to precise assessment, with corresponding internal calculation logic optimization (such as adding credit report weight parameters). Execution order adjustment: In V1.0, credit assessment node C directly depends on identity verification node B. In V2.0, credit assessment node C must first wait for the multi-borrowing detection node E to complete execution. The execution order is adjusted synchronously with the dependency relationship (details of dependency differences will be explained in the subsequent section).

[0066] The above node differences will be temporarily stored in the format of difference type-node identifier-node type-change details to prepare for subsequent list generation.

[0067] Dependency link comparison: Based on two versions of the directed acyclic graph dependency relationship graph, the addition, deletion and adjustment of dependency links are identified through path traversal algorithm: New dependency links: V2.0 adds two links: multiple borrowing detection node E → credit assessment node C and data collection node A → multiple borrowing detection node E. Because credit assessment node C needs to use the detection results of node E, and node E needs to use the user borrowing data collected by node A; Deleting dependent links: V2.0 deletes two links from V1.0: credit assessment node C → manual review trigger node F and manual review trigger node F → decision judgment node D, because node F has already been deleted; Version change of dependent nodes: In V2.0, the version of the credit assessment node C that the decision judgment node D depends on has been upgraded from C_v1 in V1.0 to C_v2 in V2.0 (due to the adjustment of the node C type). The version difference of dependent nodes needs to be marked.

[0068] By simulating the execution of the dependency logic of the two versions, it was confirmed that the above dependency differences would not lead to circular dependencies (e.g., E→C, A→E, B→C still form an acyclic graph in V2.0), thus ensuring the accuracy of difference identification.

[0069] The system uses a hierarchical table structure, categorized into two main modules: strategy node differences and dependency relationship differences. Each module contains specific difference items. Add a change impact notice at the end of the list. For example, if the newly added node E requires additional data collection from the user lending platform, it is necessary to confirm whether the data source is ready. Adjustments to the dependency links may increase the execution time of V2.0 by about 100ms, providing a decision-making reference for version upgrades.

[0070] Traditional version comparisons require manual analysis of each node and dependency, easily overlooking details. This implementation uses a structured comparison to centrally present scattered changes (such as adding node E or adjusting node C type), allowing operations personnel to quickly grasp the core differences between versions without having to read through the entire configuration, thus improving version management efficiency. The structured list clearly marks dependency changes (such as adding an E→C link) and impact warnings (such as increased processing time), enabling early identification of potential problems (such as missing data source for node E causing node C execution failure), avoiding anomalies in risk control processes after version upgrades due to unknown dependency changes, and ensuring business stability. The list records the complete change trajectory from V1.0 to V2.0. If a version rollback is needed (such as reverting to V1.0 due to defects in V2.0), deleted nodes (such as node F) and dependency links (such as C→F) can be quickly restored based on the list without redesign, meeting the management requirements of traceable and rollbackable versions in financial risk control scenarios.

[0071] In this embodiment, after step S10, that is, after combining multiple risk control strategy nodes to form a strategy organization model based on business relevance, the following steps are also included: S90. Classify the strategy nodes within the strategy set unit according to their business functions, including identity verification, credit assessment, risk calculation, and decision-making. S100. Classify the strategy nodes within the strategy set unit according to risk type, including credit risk, operational risk, market risk, and compliance risk. S110. Classify the policy nodes within the policy set unit according to their execution priority; S120. Configure corresponding functional classification labels, risk classification labels, and priority classification labels for the strategy nodes in the classified strategy set unit.

[0072] Business function classification categorizes nodes based on their core business role in risk control strategies, covering identity verification, credit assessment, risk calculation, and decision-making. This is the core classification dimension that distinguishes what each node does. Risk type classification categorizes nodes based on the risk attributes they control, covering credit risk, operational risk, market risk, and compliance risk. This is the classification dimension that clarifies what risks each node protects against. Execution priority classification prioritizes nodes based on their impact on the continuity of the risk control process (e.g., highest, high, medium, low), ensuring that key nodes receive resources and execute first. Classification tags are standardized markers used to identify the node classification results. Each node corresponds to three types of tags (functional classification tag, risk classification tag, and priority classification tag), supporting quick query and batch management based on tags.

[0073] For example, in the personal loan approval scenario, a strategy organization model (credit risk control package) is formed based on business relevance combinations, which includes 6 core risk control strategy nodes: Data collection node A (collects basic data such as user identity, income, and loan records); Identity verification node B (verifies the authenticity of the user's ID card and facial recognition); Credit assessment node C (calculates user credit score by combining income and credit history); Multiple borrowing detection node E (checks whether the user has outstanding loans on multiple platforms); Risk calculation node D (outputs risk level based on credit score and multiple borrowing results); Decision-making node F (outputs approval / rejection / manual review result based on risk level); A standardized structure for the strategy organization model has been built (including node list, type, and configuration parameters), and basic data for classification and label configuration has been provided.

[0074] The strategy nodes are categorized according to business functions. The core characteristics of the four categories are clearly defined: Identity Verification: Focuses on confirming the authenticity of a user's identity; input is identity information, output is valid / invalid identity; Credit Assessment: Focuses on quantifying a user's credit level; input is data such as income and credit history, output is credit score / credit rating; Risk Calculation: Focuses on identifying specific risky behaviors; input is specific data (such as loan records), output is whether the risk has been identified; Decision Making: Focuses on outputting the final business decision; input is risk level / credit score, output is the approval result. Match the core functions and classification rules of each node one by one to complete the classification. Identity Verification: Identity Verification Node B (verifies the authenticity of the user's identity and outputs a valid identity result); Credit Assessment: Credit Assessment Node C (calculates the credit score and outputs a credit score of 750 or equivalent); Risk Calculation: Multiple Loan Detection Node E (checks for multiple platform loans and outputs whether multiple loans exist or not); Decision Judgment: Decision Judgment Node F (outputs the approval result, and since data collection node A is a basic support node, it is temporarily classified as basic data and does not affect the four core classifications); Classification Result Confirmation: Display the classification results through the system interface to ensure that the functional classification of each node is consistent with the business logic (e.g., the multiple loan detection of node E does indeed fall under the risk calculation category), with no overlap or misclassification.

[0075] The strategy nodes are categorized according to risk type. The control objectives for four types of risks are clearly defined: Credit risk: controlling default risk caused by insufficient user repayment ability, such as low credit score; Operational risk: controlling risks caused by user or system operations, such as false identity or multiple borrowing; Market risk: controlling risks caused by market fluctuations; Compliance risk: controlling risks of violating regulatory requirements (not involved in this scenario, but reserved for future classification). Node Classification Execution: Based on the risk attributes of node prevention and control, the following classifications are completed: Credit Risk Category: Credit Assessment Node C (Credit score directly reflects the ability to fulfill obligations, preventing default risk); Operational Risk Category: Identity Verification Node B (preventing fraudulent identity operations), Multiple Borrowing Detection Node E (preventing operational risks of users concealing their borrowing behavior); Data Collection Node A and Decision Judgment Node F: Provide basic support for overall risk prevention and control, and are not currently classified into a specific risk type; Classification Result Verification: Invite risk control business experts to review and confirm that the multiple borrowing detection at Node E is indeed an operational risk (rather than a credit risk), avoiding confusion of risk attributes.

[0076] Strategy nodes are categorized according to execution priority. Priority can be determined based on the impact of node failure on the process: Highest priority: Node failure causes the entire process to fail to start, such as the basic data collection node; High priority: Node failure causes core risk control logic to be interrupted, such as risk calculation and decision-making nodes; Medium priority: Node failure only affects some risk control dimensions and can be compensated for by other nodes, such as the credit assessment node; Low priority: Node failure has little impact on core decisions, such as auxiliary verification nodes (not involved in this scenario). Node classification and execution: Based on the node's position in the dependency graph (A→B→C→E→D→F), priority is determined: Highest priority: Data collection node A (no basic data for A, all...) (Downstream nodes cannot execute); High priority: Decision-making node F (outputs the final approval result; failure directly affects business output), risk calculation node D (D's risk level is the core input of F); Medium priority: Identity verification node B (if B fails, other identity verification methods can be used as compensation), credit assessment node C (if C fails, other credit data can be referenced), multiple borrowing detection node E (if E fails, the risk level weight can be reduced); Priority conflict coordination: If there is a dispute over node priority (e.g., nodes D and F are both high priority), the principle of "downstream node priority is not lower than upstream node" will be followed to confirm that both are high priority, and resources will be guaranteed synchronously during subsequent scheduling.

[0077] Configure corresponding labels for the categorized nodes. The label format definition can adopt a standardized dimension-specific value format to ensure that the labels are semantically clear and recognizable. Function category tags: prefixed with "-", such as "function-identity verification", "function-credit assessment"; Risk classification tags: prefixed with "risk-", such as "risk-credit risk", "risk-operational risk"; Priority category labels: prefixed with priority-, such as priority-highest, priority-medium; Tag configuration execution: Batch configure 3 types of tags for each node.

[0078] In this embodiment, tags are bound to node identifiers and stored in the metadata of the strategy organization model, supporting the retrieval of nodes by tags (such as searching for risk-operation risk, which can quickly filter out nodes B and E).

[0079] Tag-based categorization transforms node searching from browsing all nodes one by one to tag-based retrieval. For example, when adjusting operational risk control nodes, searching for "risk - operational risk" quickly locates nodes B and E, eliminating the need to traverse all six nodes, thus improving management efficiency and achieving the effect of improved batch management efficiency. Execution priority categorization clearly designates A as the highest priority, ensuring the system allocates resources (such as CPU and memory) to A first, preventing process delays caused by A's execution latency. Simultaneously, the high priority settings for D and F ensure that core risk calculation and decision-making processes are not consumed by low-priority tasks, meeting the high availability requirements of financial risk control. Risk type categorization allows nodes with different risk dimensions to be adjusted independently. For example, when regulators require strengthened operational risk control, only the rules for nodes B and E need to be optimized (such as upgrading facial recognition algorithms or expanding the scope of loan platform verification), without modifying the credit risk node C, reducing interference with the overall process and improving the flexibility of risk control strategies.

[0080] In one embodiment, after step S20, that is, after constructing the dependency graph represented by a directed acyclic graph for the strategy organization model, the following steps are further included: S130. By traversing the paths of the directed acyclic graph, detect whether there is a closed path that starts from a certain node and returns to that node. If it exists, it is determined to be a circular dependency. S140. Compare the actual version number of the dependent node with the version range required by the policy set unit. If the actual version number exceeds the required version range, it is determined that the versions are incompatible. S150. Trigger an early warning for detected conflicts, output a conflict details list, which includes the conflict type, the identifier of the involved node, conflict path or version incompatibility information, and suspend the execution scheduling of the policy set unit until the conflict is resolved and the execution scheduling is restarted.

[0081] In this embodiment, circular dependency refers to a closed-loop path in the risk control strategy node dependency graph that starts from a certain node, passes through several dependency links, and returns to that node. This violates the core constraints of directed acyclic graphs and can lead to deadlock in node execution logic. Version incompatibility refers to a situation where the version range of the upstream dependent node required by the downstream node does not match the actual version of the upstream node (e.g., requiring V1.0-V1.2, but actually using V2.0), causing the dependent node to be unable to provide data or services to the downstream node normally. The conflict details list is a standardized document used to record key information about dependency conflicts, including the conflict type (circular dependency / version incompatibility), the identifier of the involved node, and details of the conflict path or version difference, providing a clear basis for conflict resolution. Conflict warning: When circular dependency or version incompatibility is detected, the system triggers a warning mechanism (such as an interface pop-up, log marking, and alarm notification) to promptly remind operations or development personnel to handle the conflict.

[0082] For example, for personal loan approval scenarios, a strategy organization model (credit risk control package) is constructed, initially containing 5 core nodes and dependencies: data collection node A (V1.0) → identity verification node B (V1.0) → credit assessment node C (V1.0) → risk calculation node D (V1.0) → decision judgment node E (V1.0); the initial dependency graph is an acyclic graph with no conflicts; due to adjustments in business requirements, a new data completion node F (V1.0) is added and some dependency logic is adjusted. A conflict detection process needs to be executed based on the adjusted dependency graph to ensure that there are no dependency risks before scheduling.

[0083] First, traverse the directed acyclic graph to check for circular dependencies. Dependency adjustment scenario: To supplement missing user data, add new data to complete node F, and adjust the dependency logic as follows: Data acquisition node A → Data completion node F (F needs to be completed using the initial data from A); Data completion node F → Identity verification node B (B needs the data completed by F); Identity verification node B → data completion node F (misconfiguration: it is assumed that B needs to send the verification result back to F for secondary completion); after adjustment, the dependency link forms A→F→B→F, which has a potential closed loop.

[0084] A path traversal algorithm (depth-first traversal) can be used to trace the dependency links starting from each node: Starting from node F, the traversal path is F→B→F. It is found that starting from F, it can return to itself, forming a closed loop; the closed loop path F→B→F is recorded, and the nodes involved are marked as data completion node F and identity verification node B; because there is a closed loop path that can return to a certain node, it is determined to be a circular dependency conflict.

[0085] The system compared the versions of dependent nodes and detected version incompatibility. In the strategy organization model of risk calculation node D, the version range of the dependent credit assessment node C is explicitly marked as V1.0-V1.1 (because D's logic only adapts to the output format of this version of C). The system reads the current version of credit assessment node C as V1.2 (because the credit score calculation logic was upgraded in the previous optimization, D's dependency configuration was not updated synchronously). Comparing D's required V1.0-V1.1 with C's actual V1.2, it was found that the actual version exceeded the required range, making it impossible to ensure that C's output format matches D's input requirements, thus determining a version incompatibility conflict.

[0086] The system pushes alarm notifications to maintenance personnel in real time (such as pop-up windows on the operation interface and alarm messages on WeChat Work), and marks dependency conflicts: circular dependency + version incompatibility; the alarm level (high risk), the time of the conflict, and the policy set unit involved (Credit Risk Control Package ID: LB_Credit_001) can be recorded in the system log simultaneously.

[0087] Output a list in a structured format, categorized by conflict type, involved nodes, conflict details, and impact description. An example is shown below. The execution scheduling of the strategy set unit is suspended until the conflict is resolved. The system automatically switches the execution status of the credit risk control package from pending scheduling to conflict pause, rejecting new business requests (such as personal credit approval requests). Received requests are temporarily stored in the queue and do not trigger node execution. The system adds a solution suggestion to the conflict details list: Circular dependency resolution: Delete the erroneous dependency link B→F, retain F→B (F completes the data and passes it to B, B does not need to respond to F), ensuring the link is A→F→B→C→D→E, without closed loops. Version incompatibility resolution: Two solutions are available: ① Downgrade C to version V1.1; ② Update the dependency configuration of D, expand the version range of C to V1.0-V1.2, and adapt it to the output format of V1.2; After the operation and maintenance personnel make the adjustments as suggested, the system will re-execute the conflict detection (traversing the path + version comparison). After confirming that there are no conflicts, the status of the package will be switched to schedulable, and the reception of new requests and execution of nodes will be restored.

[0088] In this embodiment, by traversing the DAG before scheduling, closed-loop conflicts are identified in advance to avoid business interruptions caused by execution deadlocks (such as the credit approval process being stuck), thus achieving the core objective of risk prevention and control.

[0089] If version incompatibility is not detected, downstream nodes (such as D) will report errors because they cannot parse upstream data (such as the V1.2 output of C). Rectification requires rolling back the version or refactoring the logic. This embodiment compares versions in advance, shifting the rectification time from after execution to before scheduling, reducing rectification costs and meeting the low-cost operation and maintenance requirements of financial risk control. Scheduling is suspended when conflicts are not resolved to avoid cascading failures (such as D's execution failure causing E to be unable to make decisions). At the same time, the structured checklist clearly defines the resolution direction, eliminating the need for operations personnel to check dependent logic one by one, shortening conflict resolution time and improving system availability.

[0090] As can be seen from the above embodiments, the strategy set unit directly addresses the pain points of traditional verification through its core functions. The strategy set unit combines related strategy nodes into logical sets, enabling batch verification with clear boundaries, avoiding the risk diffusion caused by changes to a single node in traditional methods. It also supports nested structures, allowing for layered verification of complex strategies and precise control over the scope of risk. Adhering to semantic versioning specifications, the strategy set unit can maintain a complete version history and branch management (main branch, development branch, etc.). If rule defects are found during verification, it can quickly roll back to a stable historical version, preventing risk escalation. The strategy set unit manages node dependencies using a directed acyclic graph (DAG), automatically identifying circular dependencies, version conflicts, and other issues before verification, proactively avoiding verification omissions. It can also quickly assess the impact of changes to a single node on the entire strategy set unit, ensuring verification covers all related scenarios. The strategy set unit supports synchronous verification of batch strategy nodes, combined with intelligent scheduling algorithms (topology sorting, critical path analysis), ensuring the verification process aligns with actual execution logic, avoiding logical breaks caused by traditional distributed verification, and improving the consistency of verification results with production scenarios.

[0091] It should be noted that the above embodiments mainly describe the functions or implementation of the traffic processing system of the risk control strategy node provided in this application, as well as some other components of the system. Below, other core components or modules of the traffic processing system of the risk control strategy node will be described in a unified manner.

[0092] The precise replication strategy enables flexible traffic replication design, supporting two replication modes: strategy set unit bypass and specified node bypass. The strategy set unit bypass mode performs unified traffic replication across all strategy nodes within the entire strategy set unit, ensuring the overall verification effectiveness of the strategy set. During replication, the execution order and dependencies between nodes are maintained to guarantee logical consistency of the replicated traffic. The specified node bypass mode allows users to precisely select specific strategy nodes for traffic replication, providing more granular verification control. Replication granularity supports different levels of precision, including request-level, session-level, and user-level replication, to meet the verification needs of various business scenarios. Replication timing employs two modes: real-time replication and batch replication. Real-time replication provides immediate verification feedback, while batch replication optimizes system performance and resource utilization.

[0093] For example, a data integrity guarantee mechanism is provided to ensure the integrity and consistency of data during the replication process, preventing data loss, damage, or leakage. Data verification employs a multi-layered verification mechanism, including technologies such as CRC checksum, MD5 hash, and digital signature, to ensure the accuracy of data transmission. Version control adds version identifiers and timestamps to the replicated data, supporting version tracking and historical backtracking. Data compression uses an adaptive compression algorithm, selecting the optimal compression method based on data characteristics to reduce storage space and transmission bandwidth. Encryption protection encrypts sensitive data, employing a hybrid encryption scheme combining AES-256 symmetric encryption and RSA asymmetric encryption to ensure data security. The data cleaning function automatically identifies and filters invalid, duplicate, and malformed data, improving the quality of replicated data.

[0094] For example, asynchronous processing queue management can employ a high-performance asynchronous processing architecture to ensure that traffic replication operations do not block the original business process. For instance, asynchronous processing queues can be built on Apache Kafka to provide high throughput and low latency message processing capabilities. Queue partitioning strategies can perform hash partitioning based on business identifiers to ensure the ordered processing of related messages. Message persistence persists queue data to disk to prevent data loss and system crashes. Backpressure control mechanisms monitor queue length and processing speed, automatically adjusting the message sending rate when the system load is too high to prevent system overload. Message retry mechanisms automatically retry messages that fail to process, supporting exponential backoff and maximum retry limits. Dead-letter queues handle messages that cannot be processed normally, providing manual intervention and troubleshooting mechanisms.

[0095] For example, state isolation and context management are utilized to achieve complete state isolation between replicated traffic and original traffic, ensuring that bypass verification does not affect the data state of the production environment. For instance, state isolation can employ virtualization technology to create an independent execution context for each replication session, including variable space, session state, and cached data. The context switching mechanism supports rapid context creation, destruction, and switching operations, minimizing performance overhead. Specifically, the state synchronization function securely replicates the state data from the production environment to the verification environment when needed, ensuring the accuracy of verification. Memory management employs object pooling and memory pooling technologies to optimize memory allocation and reclamation efficiency, preventing memory leaks and the impact of garbage collection. Session management maintains the lifecycle of the replication session, including session creation, state updates, and session cleanup operations.

[0096] For example, comprehensive performance optimization and resource control are leveraged to ensure the stable operation of the traffic replication system under high concurrency scenarios. CPU optimization employs multithreading and coroutine techniques to improve CPU utilization and processing concurrency. I / O optimization utilizes non-blocking I / O and an event-driven model to reduce I / O latency. Memory optimization includes techniques such as memory pooling, object caching, and garbage collection tuning to reduce peak memory usage. Network optimization employs connection pooling, batch transmission, and protocol optimization to improve network transmission efficiency. Resource limiting controls the upper limits of resource usage for traffic replication, including limits on CPU utilization, memory usage, and network bandwidth, preventing impact on the resource availability of the main business. Adaptive adjustment algorithms dynamically adjust replication parameters and processing strategies based on system load and performance indicators.

[0097] For example, monitoring and fault handling are provided to establish a complete monitoring system and fault handling mechanism to ensure the stability and reliability of the traffic replication system. Real-time monitoring collects key performance indicators of the system, including replication success rate, processing latency, error rate, and resource usage. An alarm mechanism promptly issues alarm notifications when indicators are abnormal, supporting multi-level alarms and escalation strategies. Fault detection employs health checks and heartbeat monitoring to promptly detect system faults and performance anomalies. An automatic recovery mechanism includes recovery strategies such as service restart, failover, and data repair. Fault isolation isolates faulty components to prevent the fault from spreading and affecting the entire system. Detailed logging records system operation logs and fault information, supporting problem troubleshooting and performance analysis.

[0098] For example, it provides comprehensive security and compliance protection and management to ensure the security and compliance of the traffic replication process. Access control employs multi-factor authentication and fine-grained permission management to ensure that only authorized users can operate the traffic replication function. Data anonymization automatically identifies and anonymizes sensitive data, including sensitive information such as ID card numbers, mobile phone numbers, and bank card numbers, ensuring data privacy protection. Audit logs record all replication operations and data access behaviors, supporting compliance audits and security tracing. The compliance check function checks the compliance of data processing according to relevant laws and standards, providing compliance reports and recommendations. Security scanning regularly performs security vulnerability scans and penetration tests to promptly identify and remediate security issues.

[0099] For example, it provides a flexible architecture that offers scalability and maintainability, supporting horizontal scaling and feature upgrades. Modular design encapsulates different functions in independent modules, supporting independent development, testing, and deployment of these modules. The plug-in mechanism supports dynamic loading of custom replication strategies and processing logic, extending functionality without modifying the core code. Configuration-based management configures system parameters and rules, supporting dynamic modification and hot updates. Version management supports smooth system upgrades and rollbacks, ensuring the security of system updates. Documentation management maintains complete technical documentation and operation manuals, supporting system maintenance and knowledge transfer. The testing framework provides unit testing, integration testing, and performance testing capabilities, ensuring system quality and stability.

[0100] Regarding the multi-dimensional random sampling algorithm module The multi-dimensional random sampling module is a key technical component used to ensure the statistical validity and representativeness of bypass verification results. This multi-dimensional random sampling algorithm module, based on probability theory, statistics, and machine learning, designs three different sampling strategies: random sampling based on the last digit of the User Identifier (UID), random sampling within a specified UID last digit range, and interval sampling based on random numbers. This provides flexible user segmentation and traffic control mechanisms for different business scenarios.

[0101] For example, the UID last digit random sampling algorithm is based on the hash consistency principle. It randomly samples the last digit of the user's identifier to ensure the consistency and repeatability of the sampling results. The algorithm first extracts the last digit of the user's UID, uses modulo operation to map the user to ten buckets from 0 to 9, and then determines the number of buckets to select based on a set sampling ratio (e.g., 1%-99%). The mapping relationship between the sampling ratio and bucket selection adopts a linear distribution strategy to ensure the uniformity of sampling. The hash function can use the CRC32 algorithm to enhance randomness and avoid sampling bias caused by the regular distribution of UIDs. The algorithm supports dynamic adjustment of the sampling ratio to achieve real-time optimization of the sampling strategy. The consistency guarantee mechanism ensures the stability of the same user's attribution in multiple samplings, avoiding inconsistencies in user experience.

[0102] For example, a specified interval random sampling algorithm is used to provide more refined sampling control, supporting user-defined combinations of multiple UID tail number intervals for sampling. Interval definitions support various forms such as closed intervals, open intervals, and half-open intervals, such as [[12,34],[40,88]] indicating selection of users whose tail numbers fall within the ranges of 12-34 and 40-88. The interval verification algorithm checks the validity of intervals, including interval boundary legality, interval overlap detection, and coverage calculation. The interval optimization algorithm automatically merges adjacent and overlapping intervals, simplifying interval representation and improving processing efficiency. The sampling weight mechanism supports assigning different weights to different intervals, enabling non-uniform sampling and focusing on specific user groups. The interval dynamic adjustment function allows runtime modification of interval configurations, supporting flexible adjustments to the sampling strategy.

[0103] For example, the random number interval sampling algorithm, based on a pseudo-random number generator, achieves more flexible sampling control, supporting combinations of arbitrary numerical intervals. The pseudo-random number generation employs a hybrid strategy combining a linear congruential generator (LCG) and the Mersenne Twister algorithm to ensure the quality and period length of the random numbers. Random number mapping maps continuous random numbers from 0 to 1 to a discrete integer space from 0 to 99, assigning a random number identifier to each user. The interval matching algorithm determines whether a user's random number falls within a specified numerical interval; for example, [[2,5],[8,20]] indicates that users whose random numbers fall within the range of 2-5 or 8-20 are selected. Random seed management supports both fixed and dynamic seed modes. Fixed seeds ensure the repeatability of sampling, while dynamic seeds provide better randomness. Sampling uniformity testing uses statistical methods such as the chi-square test and the KS test to verify the randomness and uniformity of the sampling results.

[0104] For example, sampling quality control and optimization establishes a comprehensive sampling quality assessment and optimization mechanism to ensure the statistical validity of sampling results. Sample representativeness testing assesses the representativeness of the sampling by comparing the sample distribution with the population distribution. Bias detection algorithms identify potential systematic biases in the sampling process, including selection bias, time bias, and geographical bias. Analysis of variance assesses the variance differences among different sampling strategies, providing a statistical basis for selecting sampling methods. Sample size calculation is based on statistical power analysis, determining the minimum sample size requirement according to the expected effect size and significance level. Sampling efficiency optimization improves computational and storage efficiency in the sampling process through algorithm improvement and parameter tuning.

[0105] Regarding the bypass execution engine and state isolation module The bypass execution engine and state isolation module form the core execution environment for secure verification of draft version rules. Through virtualization technology and state isolation mechanisms, they provide an independent, secure, and controllable execution space for bypass verification. Based on advanced technologies such as containerization, sandbox isolation, and resource management, this bypass execution engine and state isolation module ensures that the bypass verification process has no impact on the production environment.

[0106] For example, the virtual execution environment is constructed using lightweight container technology to create isolated execution environments, allocating independent computing resources and runtime space for each side-channel verification task. Container images can be built on Alpine Linux, containing the necessary runtime environment and dependent libraries, with image size optimized to a minimum to improve startup speed. Resource constraints are implemented through cgroups to control the container's CPU, memory, network, and disk I / O resource usage, preventing side-channel execution from impacting the performance of the main application. Network isolation employs virtual network technology, allocating independent network namespaces for the side-channel execution environment and preventing access to external networks. File system isolation is achieved through the Union File System (UnionFS), providing an independent writable layer to ensure that file modifications do not affect the host system.

[0107] For example, state synchronization and data consistency achieve secure synchronization of the production environment state to the verification environment, ensuring the accuracy and reliability of verification. State snapshot technology creates a snapshot of the production environment's state at a specific point in time, including database state, cache state, and session state. Data anonymization automatically anonymizes sensitive data, ensuring that the verification environment does not contain any real sensitive information. Incremental synchronization only synchronizes changed state data, improving synchronization efficiency and reducing resource consumption. Consistency checks ensure the integrity and accuracy of synchronized data through checksums and comparisons. Version control adds version identifiers to synchronized state data, supporting version tracking and historical rollback.

[0108] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0109] In one embodiment, a traffic processing system for a risk control strategy node is provided, which corresponds one-to-one with the traffic processing method for a risk control strategy node in the above embodiments. For example... Figure 3 As shown, the traffic processing system for the risk control strategy node includes a strategy set unit management and scheduling module, which includes: The strategy processing submodule 301 is used to determine the strategy set unit to be verified. The strategy set unit includes multiple risk control strategy nodes with business relevance. The strategy set unit records the execution dependency relationship and organizational hierarchy information between each risk control strategy node. The organizational hierarchy information is used to describe the hierarchical relationship between each risk control strategy node or each sub-set unit within the strategy set unit. The traffic processing submodule 302 is used to intercept the original requests of risk control strategy nodes. The original requests are the initial business requests that trigger the risk control process in financial business scenarios. Based on business rules, user attributes, and request characteristics, the intercepted traffic is classified into target traffic related to the strategy set unit. The related characteristics are the business attributes, node associations, user characteristics, or request logic of the traffic, which match the verification requirements of the strategy set unit. Based on the classification results, a traffic replication strategy is executed: if the strategy set unit is selected for overall verification, the execution traffic of all risk control strategy nodes within the strategy set unit is replicated; if a specific node is selected for verification, only the execution traffic of the single or multiple risk control strategy nodes selected by the user is replicated. The replicated traffic is sent to an asynchronous processing queue for bypass verification of the strategy set unit.

[0110] It should be noted that, in addition to the modules mentioned above, the traffic processing system of this risk control strategy node also includes the following modules: Time window management and scheduling module The time window management and scheduling module is responsible for the time control and task scheduling of bypass verification tasks. Through precise time management and intelligent scheduling strategies, it ensures that verification tasks are executed according to the predetermined plan, providing the system with flexible time control capabilities.

[0111] For example, a precise time control mechanism is provided, based on distributed time synchronization technology, to achieve millisecond-level time precision control. Time synchronization employs a combination of Network Time Protocol (NTP) and Precise Time Protocol (PTP) to ensure time consistency in a distributed environment. Time zone processing supports time zone conversion and daylight saving time adaptation for global deployments, providing a standardized time representation. Time window definition supports both absolute and relative time modes; absolute time specifies specific start and end times, while relative time is based on the relative offset of the triggering event. Scheduled task scheduling is based on the Quartz scheduling framework, supporting complex time configurations using Cron expressions. Time drift detection monitors system time drift and automatically performs time correction and synchronization.

[0112] For example, intelligent scheduling strategy optimization is provided, designing multiple scheduling strategies to adapt to different business scenarios and performance requirements. For instance, the priority scheduling mentioned in the previous embodiments allocates execution priorities based on the importance and urgency of tasks, with high-priority tasks enjoying priority execution. Resource-aware scheduling considers the availability of system resources, increasing concurrency when resources are sufficient and reducing task load when resources are scarce. Load-balancing scheduling distributes tasks across multiple execution nodes, avoiding single-node overload and uneven resource distribution. Delayed scheduling strategies reserve resources for important tasks by delaying the execution of non-critical tasks. Adaptive scheduling dynamically adjusts scheduling parameters and strategies based on historical execution data and performance indicators.

[0113] Validation report generation and analysis module The verification report generation and analysis module is a platform for summarizing and analyzing bypass verification results. It can provide users with comprehensive, accurate, and intuitive verification reports and decision support through big data processing technology and intelligent analysis algorithms.

[0114] For example, big data processing and aggregation can be based on the Apache Spark big data processing framework to achieve efficient processing and analysis of massive amounts of validation data. Data collection adopts a Lambda architecture that combines streaming and batch processing, supporting real-time data processing and historical data analysis. Data aggregation generates summary metrics across various dimensions through multi-dimensional grouping and statistics, including success rate, error rate, and performance metrics. Data cleaning and preprocessing remove outliers and noise, improving the accuracy of analysis results. Data compression and storage optimization reduce storage space usage and query latency.

[0115] For example, machine learning and data mining techniques can be integrated to provide in-depth data analysis and business insights. Anomaly detection algorithms identify anomalous patterns and potential problems in validation results. Trend analysis predicts the development trend of validation metrics through time series analysis. Comparative analysis provides detailed comparisons between different versions and strategies. Root cause analysis identifies the root causes of problems through correlation analysis and causal inference. Impact assessment quantifies the degree of impact of strategy changes on business metrics.

[0116] Specific limitations regarding the traffic processing system for the risk control strategy node can be found in the above section on the limitations of the traffic processing method for the risk control strategy node, and will not be repeated here. Each module in the aforementioned traffic processing system for the risk control strategy node can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can call and execute the corresponding operations of each module.

[0117] In one embodiment, such as Figure 4As shown, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the traffic processing method of the risk control strategy node in the above embodiments, for example... Figure 1 S10-S30, as shown, will not be described again here to avoid repetition. Alternatively, when the processor executes the computer program, it implements the functions of each component / module in this embodiment of the traffic processing system based on risk control strategy nodes; to avoid repetition, these will not be described again here.

[0118] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When executed by a processor, the computer program implements the traffic processing method of the risk control strategy node in the above embodiment, for example... Figure 1 S10-S30, as shown, will not be described again here to avoid repetition. Alternatively, when the computer program is executed by the processor, it implements the functions of each component / module in this embodiment of the traffic processing system for the risk control strategy node; to avoid repetition, this will not be described again here.

[0119] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A method for processing traffic at a risk control strategy node, characterized in that, include: A strategy set unit to be verified is determined. The strategy set unit includes multiple risk control strategy nodes with business relevance. The strategy set unit records the execution dependency relationship and organizational hierarchy information between each risk control strategy node. The organizational hierarchy information is used to describe the hierarchical relationship between each risk control strategy node or each sub-set unit within the strategy set unit. Intercept the original request of the risk control strategy node, where the original request is the initial business request that triggers the risk control process in a financial business scenario; Based on business rules, user attributes, and request characteristics, the intercepted traffic is classified into target traffic related to the policy set unit. The relatedness represents the business attributes, node associations, user characteristics, or request logic of the traffic, which matches the verification requirements of the policy set unit. The traffic replication strategy is executed based on the classification results: if the overall verification of the strategy set unit is selected, the execution traffic of all risk control strategy nodes within the strategy set unit is replicated; if the verification of a specific node is selected, the execution traffic of only the single or multiple risk control strategy nodes selected by the user is replicated. The copied traffic is sent to an asynchronous processing queue for bypass verification of the policy set unit.

2. The method according to claim 1, characterized in that, Before determining the set of policies to be verified, the method further includes: Based on business relevance, multiple risk control strategy nodes are combined to form a strategy organization model, which includes a strategy node list, node type, node configuration parameters, and organizational hierarchy information. A dependency graph represented by a directed acyclic graph is constructed for the strategy organization model. The dependency structure is used to describe the direct and indirect dependencies between risk control strategy nodes. The direct dependency represents a single-level dependency between risk control strategy nodes based on direct call relationships, and the indirect dependency represents a multi-level dependency link formed across multiple risk control strategy nodes. The risk control strategy nodes are scheduled based on the dependency graph.

3. The method according to claim 2, characterized in that, After combining multiple risk control strategy nodes based on business relevance to form a strategy organization model, it includes: A dependency graph represented by a directed acyclic graph is constructed for the strategy organization model. The dependency structure is used to describe the direct and indirect dependencies between risk control strategy nodes. The direct dependency represents a single-level dependency between risk control strategy nodes based on direct call relationships, and the indirect dependency represents a multi-level dependency link formed across multiple risk control strategy nodes. The dependency constraints between nodes in the dependency graph are analyzed by a topological sorting algorithm to generate a basic execution sequence that satisfies the condition that the preceding dependent nodes are executed first and the subsequent dependent nodes are executed later. Calculate the earliest execution time, latest execution time, and path length of each risk control strategy node in the basic execution sequence to determine the optimal execution sequence; Dependency conflict detection is performed on the risk control strategy nodes in the optimal execution sequence, and the risk control strategy nodes that meet the conditions are classified into a set that can be executed in parallel. The set of parallel executables is dynamically grouped based on node resource requirements, node business relevance, and node dependency status. When a group meets the conditions that all the prerequisite nodes of all nodes in the group have been executed and the system resources are adapted, the execution process of that group is started.

4. The method according to claim 2, characterized in that, After constructing a dependency graph represented by a directed acyclic graph for the strategy organization model, the method further includes: Based on the location, direct dependencies, and indirect dependencies of the risk control strategy nodes in the dependency graph, key nodes are identified and monitored. When a node failure is detected, the scope of the failure node is determined based on the direct and indirect dependencies of the key nodes, and the risk control strategy nodes within the scope of the failure are isolated. Based on a preset recovery strategy, the faulty node is restarted, service migrated, or data repaired, and the system switches to the standby node when a backup node exists.

5. The method according to claim 2, characterized in that, After combining multiple risk control strategy nodes based on business relevance to form a strategy organization model, it also includes: Compare any two versions of the strategy set units to identify differences in strategy nodes and dependencies. The differences in strategy nodes include the identifiers and types of newly added or deleted nodes and adjustments to the execution order of nodes. The differences in dependencies include newly added or deleted dependency links and changes in the versions of dependency nodes. Output a structured difference comparison list, which includes the identified differences in the policy nodes and dependencies.

6. The method according to claim 2, characterized in that, After combining multiple risk control strategy nodes based on business relevance to form a strategy organization model, it also includes: The strategy nodes within the strategy set unit are categorized by business function, including identity verification, credit assessment, risk calculation, and decision-making. The strategy nodes within the strategy set unit are classified according to risk type, including credit risk, operational risk, market risk, and compliance risk. The policy nodes within the policy set unit are classified according to their execution priority. Configure corresponding functional classification labels, risk classification labels, and priority classification labels for the strategy nodes within the classified strategy set unit.

7. The method according to claim 2, characterized in that, After constructing the dependency graph represented by a directed acyclic graph for the strategy organization model, the method further includes: By traversing the paths of the directed acyclic graph, we can detect whether there is a closed path that starts from a certain node and returns to that node. If such a path exists, it is determined to be a circular dependency. Compare the actual version number of the dependent node with the version range required by the policy set unit. If the actual version number exceeds the required version range, it is determined to be a version incompatibility. A warning is triggered for detected conflicts, and a conflict details list is output. The conflict details list includes the conflict type, the identifier of the involved node, the conflict path or version incompatibility information, and the execution scheduling of the policy set unit is suspended until the conflict is resolved and the execution scheduling is restarted.

8. A traffic processing system for a risk control strategy node, characterized in that, The system includes a strategy set unit management and scheduling module, which comprises: The strategy processing submodule is used to determine the strategy set unit to be verified. The strategy set unit includes multiple risk control strategy nodes with business relevance. The strategy set unit records the execution dependency relationship and organizational hierarchy information between each risk control strategy node. The organizational hierarchy information is used to describe the hierarchical relationship between each risk control strategy node or each sub-set unit within the strategy set unit. The traffic processing submodule is used to intercept the original requests of the risk control strategy nodes. The original requests are the initial business requests that trigger the risk control process in the financial business scenario. Based on business rules, user attributes, and request characteristics, the intercepted traffic is classified into target traffic related to the strategy set unit. The relatedness represents the business attributes, node associations, user characteristics, or request logic of the traffic, matching the verification requirements of the strategy set unit. Based on the classification results, a traffic replication strategy is executed: if the strategy set unit is selected for overall verification, the execution traffic of all risk control strategy nodes within the strategy set unit is replicated; if specific nodes are selected for verification, only the execution traffic of the single or multiple risk control strategy nodes selected by the user is replicated. The replicated traffic is sent to an asynchronous processing queue for bypass verification of the strategy set unit.

9. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the traffic processing method of the risk control strategy node according to any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the traffic processing method of the risk control strategy node according to any one of claims 1 to 7.

Images