A fund clearing method based on dynamically constructed directed acyclic graph

Abstract

This invention discloses a fund clearing method based on dynamically constructed directed acyclic graphs (DAGs). The method includes: receiving a transaction request containing transaction context information; selecting a clearing strategy based on this information and instantiating a clearing strategy DAG in memory; traversing and executing the rule templates corresponding to each node according to the topological order of the DAG; collecting atomic accounting instructions generated by all nodes during the traversal; and submitting the instructions to the core accounting system for execution after the traversal is complete. This invention, by deconstructing the clearing logic into a dynamically constructed DAG, achieves separation of business logic and execution engine, improving business flexibility and system performance. It can be used to handle complex transaction scenarios with high concurrency and changing rules, while simplifying auditing and reducing fund processing risks.

Description

Technical Field

[0001] This invention relates to the fields of financial technology and e-commerce technology, specifically to a fund clearing and processing technology applied to large-scale, high-concurrency online transaction scenarios, and particularly to a fund clearing method based on dynamically constructed directed acyclic graphs. Background Technology

[0002] With the rapid development of e-commerce and the digital economy, large online trading platforms face a massive number of concurrent transaction requests during periodic large-scale promotional events. In these complex transaction scenarios, the platform's fund clearing system not only needs to handle a huge volume of payment requests, but also needs to perform real-time splitting, aggregation, and allocation of each transaction's funds, involving multiple participants, based on dynamic and complex business rules.

[0003] Traditional fund clearing system designs often have limitations in their technical solutions. One common approach is a T+1 batch processing model, which cannot meet the real-time settlement needs of modern e-commerce, impacting merchants' cash flow efficiency. Another approach uses hard-coding to embed business logic into the program code. In large-scale promotional activities, marketing strategies are complex and varied, often requiring rapid adjustments based on real-time sales data, and sometimes even dynamically launching new marketing tactics during the event.

[0004] Systems employing hard-coded logic suffer from the following shortcomings when addressing such needs. First, they lack flexibility in business response. Every change in business rules requires code modification, functional testing, and system deployment, a lengthy process that cannot meet the demands of rapid business iteration. Second, they are prone to performance bottlenecks. Some solutions based on database stored procedures or simple rule engines become performance bottlenecks when facing high-concurrency transactions due to complex rule matching and calculation logic, hindering effective horizontal scaling and potentially causing system response delays or service interruptions. Finally, the systems face higher processing risks and maintenance costs. Numerous complex conditional judgments are intertwined, reducing code readability and maintainability. Even minor modifications can lead to unexpected financial errors and potential losses. This complexity increases exponentially, especially when a transaction involves multiple parties sharing revenue, making subsequent auditing and troubleshooting difficult.

[0005] Therefore, a new technical solution is needed to address the technical challenge of balancing business flexibility, system stability, and financial accuracy in complex scenarios with high concurrency and volatile rules. Summary of the Invention

[0006] This invention aims to solve the technical problems of existing fund clearing technology when dealing with complex transaction scenarios with large scale, high concurrency, and dynamic and ever-changing rules, such as inflexible business response, prominent system performance bottlenecks, high maintenance costs, and high risks in fund processing.

[0007] To achieve the above objectives, this invention provides a fund settlement method based on dynamically constructed directed acyclic graphs, comprising:

[0008] Receive transaction requests sent by terminal devices that contain transaction context information;

[0009] Based on the transaction context information, a liquidation strategy is selected from a pre-configured rule base; and based on the nodes defined by the liquidation strategy and the dependencies between nodes, a directed acyclic graph (DAG) of liquidation strategy is instantiated in the server's memory, wherein each node corresponds to a preset rule template.

[0010] According to the topological order of the DAG of the liquidation strategy, the traversal starts from the node with an in-degree of zero; for each node traversed, a rule execution engine is called to execute the rule template corresponding to that node, and the execution output of that node is used as the input of all its downstream nodes.

[0011] During the traversal of the DAG, all atomic accounting instructions generated by the nodes are collected, and after the traversal is completed, the set of atomic accounting instructions is submitted to an accounting core system for execution.

[0012] Furthermore, the present invention also provides an electronic device, comprising: a memory, a processor, and a computer program stored in the memory, wherein when the processor executes the computer program, it implements the method described in any of the preceding embodiments.

[0013] Furthermore, the present invention also provides a computer-readable storage medium having a computer program stored thereon, wherein when the computer program is executed by a processor, it implements the method described in any of the preceding claims.

[0014] The beneficial effects of this invention are as follows: By deconstructing complex clearing business logic into a directed acyclic graph (DAG) composed of rule template nodes, and dynamically constructing and executing this graph based on the real-time context of each transaction, the separation of business logic and execution engine is achieved. Business personnel can adjust and deploy new clearing strategies in a configurable manner, improving business flexibility and shortening the update cycle of business rules. Simultaneously, the in-memory construction and traversal execution of the clearing strategy DAG avoids frequent database interactions and logical judgment overhead, improving the system's ability to handle high-concurrency transactions, helping to reduce single-transaction settlement latency, and improving system performance. Furthermore, the DAG structure clarifies the fund processing path, simplifying auditing and troubleshooting, while the atomicity and template nature of the rules ensures the reusability and consistency of the logic, helping to reduce the risk of fund processing errors caused by logical errors. Attached Figure Description

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

[0016] Figure 1 This is a system architecture topology diagram provided according to an embodiment of the present invention.

[0017] Figure 2 This is a flowchart of a fund clearing method provided according to an embodiment of the present invention.

[0018] Figure 3 This is a schematic diagram of the structure of a directed acyclic graph (DAG) for a specific liquidation strategy according to an embodiment of the present invention.

[0019] Figure 4 This is a structural block diagram of an electronic device according to an embodiment of the present invention. Detailed Implementation

[0020] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0021] Example 1

[0022] This embodiment provides a fund clearing method based on dynamically constructed directed acyclic graphs. This method typically runs in a distributed system deployed on a server cluster. (Refer to...) Figure 1 Logically, the system can be divided into several core service modules, including transaction access gateway 101, rule configuration center 102, clearing strategy engine 103, and distributed accounting core 104.

[0023] Transaction access gateway 101, serving as the system's unified entry point, is responsible for receiving payment success notifications from upstream business systems. This notification is typically a structured data packet, such as in JSON format, containing basic information necessary for clearing, such as a unique transaction serial number, total transaction amount, payment channel information, buyer ID, seller ID, and a product list. A crucial field is the transaction context information, which, in the form of a set of key-value pairs, carries the specific business attributes of this transaction. This information is essential for subsequently selecting a clearing strategy.

[0024] The rule configuration center 102 is a persistent storage and management service, implemented using a distributed key-value database to store and manage liquidation business logic. In this embodiment, the complex liquidation logic is deconstructed into a four-layer nested architecture, stored in the rule base, specifically including an atomic rule layer, a business rule layer, a rule template layer, and a liquidation strategy layer. The atomic rule layer defines indivisible, basic accounting operations. The business rule layer consists of one or more atomic rules, used to implement a specific, reusable business logic. The rule template layer is a parameterized encapsulation of business rules, forming standardized nodes that can be invoked by the liquidation strategy. Each node in the subsequently constructed liquidation strategy DAG corresponds to a rule template at this layer. The liquidation strategy layer consists of multiple rule template nodes and their dependencies, defining the overall structure of a complete directed acyclic graph (DAG) of the liquidation process.

[0025] The clearing strategy engine 103 is the core of the technical solution of this invention, and it is responsible for the dynamic construction and execution of the clearing strategy DAG. After receiving a transaction request forwarded by the transaction access gateway 101, the clearing strategy engine 103 performs a series of operations.

[0026] The distributed ledger core 104 is responsible for the final accounting operation. It receives a set of atomic accounting instructions generated by the clearing strategy engine 103 and ensures that these instructions are executed atomically and consistently within a distributed transaction. To guarantee data consistency, this module can be implemented based on a distributed database that supports ACID properties and uses two-phase commit or a distributed consensus protocol to ensure the atomicity of transactions and data consistency.

[0027] Reference Figure 2The specific process S200 of this embodiment is as follows:

[0028] Step S201: Receive a transaction request containing transaction context information. The transaction access gateway 101 receives a transaction success request sent by the upstream business system, which contains key transaction context information.

[0029] Step S202: Select a liquidation strategy and instantiate a liquidation strategy DAG. Upon receiving a request, the liquidation strategy engine 103 first performs strategy routing. Specifically, it extracts at least one business identifier from the transaction context information, which may include one or more of the following: activity ID, merchant ID, user level, or payment channel. Then, it uses the extracted business identifier combination as a query key to match it in a pre-built, in-memory strategy mapping table stored in a hash table structure. This strategy mapping table records the mapping relationship between business identifier combinations and liquidation strategy identifiers. Based on the matched liquidation strategy identifier, the liquidation strategy engine 103 retrieves and loads the corresponding liquidation strategy configuration data from the rule configuration center 102. After obtaining the liquidation strategy configuration data, the engine instantiates a liquidation strategy directed acyclic graph (DAG) in the server's memory. To improve performance, this instantiation process can utilize a pre-allocated object pool to create the required number of node and edge objects. Based on the configuration data, each node in the DAG is configured with its corresponding rule template ID, and its initial execution status is set to "pending". Dependencies between nodes are established by constructing an adjacency list. Specifically, each node object contains an out-degree list to store all its downstream node references and an in-degree counter to record the number of its upstream nodes.

[0030] In an optional implementation, a risk assessment step may be included before this step. Before instantiating the DAG, the system may invoke a risk control model based on the transaction context information to determine the risk level of the current transaction. When the determined risk level is higher than a preset threshold, the system may dynamically insert at least one rule template node related to risk management into the node set defined by the selected liquidation strategy, thereby forming an enhanced liquidation strategy DAG, and then perform subsequent instantiation of this enhanced DAG.

[0031] Step S203: Traverse and execute nodes according to the topological order of the DAG. After the DAG is instantiated, the liquidation strategy engine 103 begins traversing and executing according to the topological order. This traversal process is implemented as follows: First, an execution queue is initialized, and all nodes in the DAG with an in-degree counter of zero are added to the execution queue. Then, while the execution queue is not empty, a current node is cyclically retrieved from the queue, and the rule execution engine is called to execute that node. After the current node is executed, all downstream nodes in its out-degree list are traversed, and the in-degree counter of each downstream node is decremented by one. After decrementing, if the in-degree counter of any downstream node becomes zero, that downstream node is added to the execution queue. This loop continues until the execution queue is empty. To manage data transfer between nodes, the engine maintains a thread-safe shared data context implemented with a hash map for each DAG execution process. When the rule execution engine executes a current node, it reads the output data of all its upstream nodes from this shared data context as the input parameters for the current node. After the current node completes its execution, its output data is encapsulated into a standard data transfer object and written to the shared data context for downstream nodes to read and use. To ensure processing security, the method also includes an exception handling mechanism. If any node fails to execute during the traversal, the rule execution engine will immediately interrupt the entire traversal process and trigger a pre-defined compensation logic. This compensation logic will perform a corresponding reversal or rollback operation based on the type of the failed node and the current state in the shared data context.

[0032] Step S204: Collect and submit atomic accounting instructions. Throughout the DAG traversal, whenever a node executes successfully and its logic includes an accounting operation, it generates one or more atomic accounting instructions. These instructions are continuously collected. An atomic accounting instruction is structured data that includes at least: payer account identifier, payee account identifier, transaction currency, transaction amount, and a business transaction number for traceability. After all nodes in the DAG have been traversed, the clearing strategy engine 103 encapsulates the collection of all atomic accounting instructions into a transaction and submits it to the distributed ledger core system 104 for execution. After execution, the clearing strategy DAG instantiated in memory is destroyed to release the occupied memory resources.

[0033] This embodiment will be illustrated using a specific transaction scenario as an example. Scenario description: A user purchases a pre-sale item from Brand A that participates in a "300 RMB off for every 300 RMB spent across stores" promotion. The original price of the item is 350 RMB, the user pays a 50 RMB deposit, and the remaining balance is 300 RMB. The platform charges a 5% commission on this product category. First, strategy selection and DAG construction are performed. The transaction request context contains relevant activity identifiers. The liquidation strategy engine routes to a preset liquidation strategy based on this and constructs a DAG in memory as follows: Figure 3 The example shown is a DAG instance. This DAG contains node A (pre-sale deposit processing), node B (promotional discount processing), node C (platform commission calculation), and node D (final settlement). Its dependencies are: B depends on A, C depends on B, and D depends on both B and C. Then, the DAG is traversed and executed. Initially, only node A has an in-degree of 0 and is added to the execution queue. Node A is executed, processing the logic of converting a 50 yuan deposit into payment. After execution, the in-degree of node B, the downstream node of node A, is decremented by 1, becoming 0. Therefore, node B is added to the queue, and node A outputs "Amount to be distributed is 300 yuan" to the shared data context. Node B is executed, reading the amount to be distributed (300 yuan) from the context. Based on the activity rules, it calculates the platform discount that should be distributed for this product to be 40 yuan and generates an instruction: compensate 40 yuan from the platform marketing cost account to the merchant's pending settlement account. After execution, the in-degree of downstream nodes C and D of node B is decreased by 1, and the in-degree of node C becomes 0, so it is added to the queue. Node B outputs "Commission base amount is 310 yuan" to the context. Node C is executed, reading the commission base amount of 310 yuan from the context, calculating the commission as 15.5 yuan based on its parameters, and generating an instruction: transfer 15.5 yuan from the merchant's pending settlement account to the platform's commission income account. After execution, the in-degree of downstream node D of node C is decreased by 1, becoming 0, so node D is added to the queue. Node D is executed, performing final settlement. It reads relevant data from the context, calculates the merchant's final settlement amount as (300 + 40) - 15.5 = 324.5 yuan, and generates an instruction: transfer 324.5 yuan from the merchant's pending settlement account to the merchant's available balance account. Finally, the instruction is submitted. After the traversal is complete, all atomic accounting instructions generated in the above process are collected as a set and submitted to the accounting core 104 for atomic execution.

[0034] Example 2

[0035] This embodiment provides an electronic device, which may be a server, a node in a server cluster, a personal computer, a mobile terminal, etc. (Refer to...) Figure 4 The internal structure of the electronic device 400 may include a processor 401, a memory 402, and a bus 403 for connecting these components.

[0036] The processor 401 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.

[0037] The memory 402 may be a read-only memory (ROM), random access memory (RAM), flash memory, hard disk, or other media capable of storing information. The memory 402 stores computer programs or instructions.

[0038] The processor 401 can implement all or part of the steps of the fund clearing method based on dynamically constructed directed acyclic graph described in Embodiment 1 by reading and executing the computer program stored in the memory 402. For example, processor 401 can execute instructions to achieve the following functions: a functional module configured as a transaction access gateway, used to receive transaction requests containing transaction context information sent by terminal devices; a functional module configured as a clearing strategy engine, used to select a clearing strategy from a pre-configured rule base according to the transaction context information, and instantiate a clearing strategy directed acyclic graph (DAG) in the server's memory according to the nodes defined by the clearing strategy and the dependencies between nodes, where each node corresponds to a preset rule template; also implemented by the clearing strategy engine module, used to traverse the clearing strategy DAG according to the topological order, starting from the node with an in-degree of zero, and for each node traversed, call a rule execution engine to execute the rule template corresponding to that node, and use the execution output of that node as the input of all its downstream nodes; also implemented by the clearing strategy engine module, used to collect atomic accounting instructions generated by all nodes during the traversal of the DAG, and submit the set of atomic accounting instructions to an accounting core system for execution after the traversal is completed.

[0039] Those skilled in the art will understand that Figure 4 The structure shown is for illustrative purposes only. The electronic device 400 may also include other necessary components, such as input / output interfaces, communication modules, etc.

[0040] Furthermore, the present invention also provides a computer-readable storage medium storing a computer program that, when executed by a processor, can implement the steps of any of the methods described in Embodiment 1. The storage medium may be non-volatile, such as the aforementioned memory 402, or a USB flash drive, portable hard drive, optical disc, etc.

[0041] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention 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; and these 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 the present invention.

Claims

1. A method for funds settlement based on dynamically constructing a directed acyclic graph, characterized in that, include: Receive a transaction request sent by a terminal device, which contains transaction context information; Based on the transaction context information, a liquidation strategy is selected from a pre-configured rule base; and based on the nodes defined by the liquidation strategy and the dependencies between nodes, a directed acyclic graph (DAG) of liquidation strategy is instantiated in the memory of a server, wherein each node corresponds to a preset rule template. According to the topological order of the DAG of the liquidation strategy, the traversal starts from the node with an in-degree of zero; for each node traversed, a rule execution engine is called to execute the rule template corresponding to that node, and the execution output of that node is used as the input of all its downstream nodes. During the traversal of the DAG, all atomic accounting instructions generated by the nodes are collected, and after the traversal is completed, the set of atomic accounting instructions is submitted to an accounting core system for execution.

2. The method of claim 1, wherein, The step of selecting a liquidation strategy based on the transaction context information specifically includes: Extract at least one business identifier from the transaction context information, wherein the business identifier includes one or more of the following: activity ID, merchant ID, user level, or payment channel; The business identifier is used as a query key to match a pre-built policy mapping table stored in a hash table structure. The policy mapping table records the mapping relationship between combinations of business identifiers and liquidation policy identifiers. Based on the matched liquidation policy identifier, the corresponding liquidation policy configuration data is retrieved from and loaded from the rule base, which is deployed in a distributed key-value database.

3. The method of claim 2, wherein, The step of instantiating a liquidation policy DAG in the server's memory specifically includes: Multiple node objects and edge objects are created in the memory using a pre-allocated object pool; Based on the liquidation strategy configuration data, configure a rule template ID for each node and initialize its execution status to "pending". Directed edges between nodes are established by constructing an adjacency list. Each node object contains an out-degree list for storing all its downstream node references and an in-degree counter for recording the number of its upstream nodes. The instantiated liquidation strategy DAG is destroyed after execution to release memory resources.

4. The method of claim 1, wherein, The step of traversing the DAG according to the topological order of the liquidation strategy specifically includes: Initialize an execution queue and add all nodes in the DAG with an in-degree of zero to the execution queue; When the execution queue is not empty, perform the following operations in a loop: retrieve a current node from the execution queue and execute it; After the current node has finished executing, traverse all its downstream nodes and decrement the in-degree count of each downstream node by one. If the in-degree count of any downstream node becomes zero after being decremented by one, then that downstream node is added to the execution queue.

5. The method of claim 4, wherein, The step of executing the rule template corresponding to the node further includes: To maintain a thread-safe shared data context implemented with hash mapping for this DAG execution process; When executing the current node, the rule execution engine reads the output data of its upstream node from the shared data context as input parameters; After the current node completes its execution, the generated output data is encapsulated into a standard data transfer object and written into the shared data context. The method further includes that if the execution of any node fails, the rule execution engine interrupts the traversal process and triggers a preset compensation logic. The compensation logic performs a corresponding reversal or rollback operation based on the type of the failed node and the current state in the shared data context.

6. The method of claim 1, wherein, The rule base is organized into a four-level nested architecture, which includes: The atomic rule layer defines indivisible accounting operations; The business rules layer consists of one or more atomic rules, used to implement a specific business logic; The rule template layer is a parameterized encapsulation of business rules, and the nodes correspond to the rule templates in this layer; The liquidation strategy layer, consisting of multiple rule template nodes and their dependencies, defines the overall structure of the DAG.

7. The method of claim 1, wherein, The atomic accounting instruction is a structured data, which includes at least: a payer account identifier, a payee account identifier, a transaction currency, a transaction amount, and a transaction serial number.

8. The method of claim 1, wherein, Before the step of instantiating a liquidation policy DAG in the server's memory, the method further includes: Based on the transaction context information, a risk control model is invoked to determine the risk level of the current transaction; When the risk level is higher than a preset threshold, at least one rule template node related to risk management is dynamically inserted into the node set defined by the liquidation strategy to form an enhanced liquidation strategy DAG and then instantiate it.

9. An electronic device, comprising: A memory, a processor, and a computer program stored on the memory, characterized in that, when the processor executes the computer program, it implements the method as described in any one of claims 1-8.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1-8.

Images