A clearing and posting method and system based on an intelligent rule engine

Abstract

The application discloses a kind of based on intelligent rule engine's clearing and accounting method and system, comprising: by visual interface configuration, including fund item, lending relationship, operation instruction and priority, accounting rule is formed into standardization rule base;Receive and analyze clearing instruction, extract instruction core element;With intelligent rule engine, based on instruction number, business scene, account state multidimensional matching rule, in combination with priority judgment and conflict resolution mechanism, determine accounting rule;Automatic execution fund transfer, generate accounting voucher and record log;Intelligently monitor and automatically dispose to abnormal condition.The application realizes the dynamic configuration and flexible extension of rule by decoupling accounting rule and system code, solves the problems of poor rule expandability, low instruction association accuracy and low abnormal processing efficiency in the prior art, and improves the automation level, accuracy and business adaptation efficiency of clearing and accounting.

Description

Technical Field

[0001] This invention relates to the field of financial data processing technology, specifically to a clearing and settlement method and system based on an intelligent rule engine. Background Technology

[0002] In spot clearing financial agency and settlement business scenarios, fund transfer is the core link connecting transaction completion, fund transfer, and final settlement. Its accuracy and timeliness determine the compliance of clearing business and the security of funds. Fund transfer must strictly follow the lending logic of the fund project, correspond to different business operation instructions (such as fund freezing, unfreezing, handling fee deduction, settlement payment, default compensation, etc.), and adapt to the complex needs of fund transfers in various business scenarios and currencies, as well as various instruction types.

[0003] Currently, in the agency clearing systems of financial clearing institutions, fund transfer processing mainly adopts the traditional model of "hard-coded rules + manual assistance." Under this model, developers need to directly write business rules such as lending rules for various fund projects, corresponding operation instruction association logic, and instruction priorities into the system's core code. Fund transfer operations are triggered by a fixed program flow; when a specific clearing instruction is received, the system executes the fund transfer according to the pre-written code logic. For complex scenarios with multiple instructions triggering simultaneously, such as instruction A2017 corresponding to both freezing and unfreezing fund transfer operations, the system often cannot automatically determine the instruction priority and fund transfer order, requiring manual intervention for judgment and processing.

[0004] However, with the rapid development of financial markets and continuous updates to regulatory policies, the limitations of the aforementioned traditional accounting processing methods have become increasingly apparent. Analysis reveals the following core drawbacks of existing technologies:

[0005] (i) Poor rule scalability and low efficiency in business adaptation; due to the strong coupling between the accounting rules and the system code, any change in business rules requires modification of the core code. When business needs arise, such as adding new funding items, adjusting loan relationships, updating operation instructions, or modifying instruction priorities, developers must perform a full-process operation including code modification, unit testing, integration testing, and system deployment. This hard-coded model results in long rule iteration cycles, high maintenance costs, and an inability to quickly adapt to the needs of business iteration and regulatory policy adjustments.

[0006] (II) Low accuracy of instruction association; In complex clearing business scenarios, there are various complex relationships between instructions and transaction operations: 1) One-to-many relationship: The same instruction (such as the A2017 fund unfreezing and freezing instruction) may correspond to both freezing and unfreezing transaction operations, and the debit and credit relationships of the two transaction operations are opposite. The system has difficulty in automatically identifying which transaction rule should be selected based on the current account status. 2) Many-to-one relationship: The same transaction operation (such as customer handling fee income) may be triggered by multiple instructions (such as the A2031 transaction data enhancement instruction and clearing operation), which need to be executed in a specific order. The system has difficulty in automatically verifying the completion status of each preceding instruction. Fixed processes are difficult to accurately match the relationship between instructions and transaction rules, which can easily lead to problems such as mis-triggered instructions, disordered transaction order, and debit / credit imbalance.

[0007] (iii) Low efficiency in handling anomalies; various anomalies may occur during the accounting process, including but not limited to debit / credit imbalances, insufficient account balances, instruction conflicts, and rule matching failures. Under the current technical model, when an anomaly occurs, it is necessary to manually check the accounting logs, instruction information, and account status one by one to locate the root cause of the problem, and then manually adjust parameters or perform compensation operations. This manual verification method is not only inefficient, but also prone to financial risks due to human error, and cannot form a standardized anomaly handling process.

[0008] (iv) Poor rule reusability; different agency clearing scenarios (such as shipping derivatives clearing, spot clearing, etc.) have similar accounting rule requirements, but because the rules are fixed in the code, they cannot be reused across scenarios. Developers need to develop rule logic separately for each scenario, resulting in system redundancy and repeated development, which increases the complexity and cost of system maintenance.

[0009] (v) Lack of rule visualization and dynamic configuration capabilities; the accounting rules are hidden in the system code, making it impossible for operations and maintenance personnel to intuitively view and verify the completeness and correctness of the rule logic. When it is necessary to review or adjust the rules, it is necessary to rely on developers to operate at the code level, lacking a visual configuration interface for business operations and maintenance personnel. At the same time, rule parameters (such as instruction priority, risk adjustment coefficient, trigger conditions, etc.) cannot be adjusted in real time according to business needs, limiting the flexibility and adaptability of the system. Summary of the Invention

[0010] To address the shortcomings of existing technologies, this invention provides a clearing and accounting method and system based on an intelligent rule engine. By decoupling the accounting rules from the system code, it enables dynamic configuration and flexible expansion of the rules, solving the problems of poor rule scalability, low accuracy of instruction association, and low efficiency of exception handling in existing technologies. This improves the automation level, accuracy, and business adaptability efficiency of clearing and accounting.

[0011] To achieve the above objectives, the present invention provides the following technical solution:

[0012] A clearing and accounting method based on an intelligent rules engine includes the following steps:

[0013] Step S1: Provide a visual configuration interface through the rule configuration module, configure the transaction rules and store them in the rule base. The transaction rules include at least the fund items, loan relationships, associated operation instructions and instruction priorities.

[0014] Step S2: Receive the liquidation operation instruction through the instruction parsing module, extract the core elements of the instruction, verify the instruction, and generate standardized instruction parsing results;

[0015] Step S3: Input the standardized instruction parsing results into the rule base through the intelligent rule engine module, filter the matching accounting rules based on the multi-dimensional matching algorithm, and determine the final accounting order and rules according to the preset instruction priority and conflict resolution mechanism.

[0016] Step S4: The transaction execution module automatically generates transaction vouchers based on the matched transaction rules and instruction parsing results, and performs fund transfer operations according to the debit and credit relationships, while recording transaction logs.

[0017] Step S5: Monitor the accounting process in real time through the exception handling module, trigger the corresponding handling process when an exception is detected, and restart the accounting process after the handling is completed.

[0018] Preferably, in step S3, the multi-dimensional matching algorithm specifically involves: inputting the parsed instruction elements into the rule base, first matching the associated fund project rules according to the instruction number, then filtering the matching results by combining the current business scenario identifier and fund account status, and outputting at least one transaction rule corresponding to the instruction;

[0019] The conflict resolution mechanism includes:

[0020] For scenarios where the same instruction number is associated with multiple transaction rules, the matching rule is automatically selected based on the current status of the fund account: if the fund account is currently not frozen, then the freezing transaction rule is matched; if the fund account is currently frozen, then the unfreezing transaction rule is matched.

[0021] For scenarios where multiple instructions trigger the same accounting rule, verification is performed according to the preset instruction triggering order and completion status: when multiple related instructions meet the triggering conditions, the completion status of each instruction is verified in turn, and the accounting is triggered in the preset order until all the preceding instructions corresponding to the accounting rule are executed.

[0022] For transaction rules that have a mutual exclusion relationship, a mutual exclusion check is performed during rule matching. If the currently matched rule and the rule to be matched have a mutual exclusion relationship, the match is rejected and a conflict log is recorded.

[0023] Preferably, in step S4, before performing the fund transfer operation, the fund transfer execution module performs compliance verification on the fund transfer amount using the following formula: M≤B×K; where M is the fund transfer amount, B is the available balance of the corresponding account, and K is the risk adjustment coefficient;

[0024] When the verification result satisfies M≤B×K, the fund transfer execution module continues to execute the fund transfer operation;

[0025] When the verification result satisfies M > B × K, the transaction execution module suspends the current transaction operation and automatically triggers an anomaly warning, pushing the anomaly information to the anomaly handling module. The anomaly information includes at least the current account balance, the required transaction amount, and the risk adjustment coefficient value.

[0026] Preferably, in step S4, the transaction execution module supports multi-currency transaction scenarios, specifically including:

[0027] When the currency information contained in the instruction parsing result is inconsistent with the account currency specified in the transaction rules, the transaction execution module automatically calls the exchange rate conversion interface to obtain the real-time exchange rate at the time of the transaction or the settlement exchange rate of the day.

[0028] Based on the exchange rate obtained, the amount of funds to be transferred is converted into the currency of the target account, and a converted transaction voucher is generated.

[0029] After currency conversion is completed, fund transfer is executed, and the exchange rate and the amount before and after conversion are recorded to ensure that the amounts of the lender and borrower remain balanced after conversion.

[0030] The converted amount is used as the transaction amount and is subject to compliance verification.

[0031] Preferably, in step S4, the transaction execution module supports both bilateral and chain-like transaction modes; wherein,

[0032] The bilateral transaction mode is as follows: according to the matching transaction rules, the two-way fund transfer between the payer's account and the payee's account is completed simultaneously or sequentially, and the fund settlement of both accounts is directly completed.

[0033] The chain-like settlement process involves triggering multiple fund transfer operations sequentially based on the order of multiple nodes in the settlement chain. After each transfer is completed, the fund balance of that link is verified, and the fund settlement of the entire chain is confirmed to be completed after all links are executed.

[0034] Preferably, the method further includes step S6: rule optimization and iteration; step S6 specifically includes:

[0035] Step S601: Periodically collect transaction logs and anomaly handling records, and construct rule performance evaluation indicators based on the collected data. The rule performance evaluation indicators include at least rule matching accuracy, transaction success rate, and anomaly occurrence rate. When the evaluation indicator of any transaction rule is lower than a preset threshold, the rule is marked as a rule to be optimized.

[0036] Step S602: Based on the evaluation indicators of the rule to be optimized and the associated anomaly handling records, analyze the rule defect types, which include at least unreasonable priority settings, imprecise trigger conditions, and mismatched lending relationships; generate optimization suggestions based on the analysis results, which include at least adjusting instruction priority, modifying trigger conditions, and updating lending relationships;

[0037] Step S603: Modify the rule to be optimized through the visual configuration interface. The modified rule is stored in the rule base as a new version and the historical version is retained to support rule rollback. During the modification process, the new rule is automatically validated for legality. The legality validation includes at least the validation of the loan relationship, the validation of the reasonableness of the instruction association, and the validation of the consistency of the priority logic.

[0038] Step S604: After the new version of the rules passes verification, it is pushed to the test environment for verification; after verification, the new version of the rules is gradually switched to the production environment in a gray-scale release manner to achieve smooth iteration of online accounting rules; the entire iteration process does not require modification of the system core code.

[0039] This invention discloses a clearing and accounting system based on an intelligent rule engine, used to implement the above-mentioned method, comprising:

[0040] The rule configuration module provides a visual configuration interface to receive the transaction rule elements configured by operations and maintenance personnel for different fund projects. The rule elements include at least the fund project name, loan relationship, associated operation instruction number, and instruction priority. The rule configuration module stores the configured transaction rules in a structured manner in the rule library and retains rule configuration logs.

[0041] The instruction parsing module is used to connect to the external clearing system through a standardized interface, receive clearing operation instructions, extract the core elements of the instructions, verify the legality of the instructions, and generate standardized instruction parsing results.

[0042] The intelligent rule engine module has its input end connected to the output end of the instruction parsing module to receive standardized instruction parsing results; its data end is connected to the rule base of the rule configuration module to retrieve and match accounting rules from the rule base; it is used to perform multi-dimensional matching between the instruction parsing results and the rule base, and determine the final accounting rules and accounting order according to the preset instruction priority and conflict resolution mechanism.

[0043] The transaction execution module, whose input end is connected to the output end of the intelligent rule engine module, is used to receive matching transaction rules and instruction parsing information, automatically generate transaction vouchers, and execute fund transfer operations according to loan relationships. The transaction execution module has a built-in amount verification unit for verifying the compliance of transaction amounts. The transaction execution module is also used to record transaction logs, which include at least instruction information, rule matching results, loan amounts, account balance changes, and transaction completion time.

[0044] The exception handling module, whose input end is connected to the exception signal output end of the accounting execution module, is used to monitor exceptions in real time during the accounting execution process. The exceptions include at least the following: loan imbalance, insufficient account balance, instruction conflict, and rule matching failure. The exception handling module is used to automatically trigger the corresponding handling process according to the exception type and provides a manual intervention interface for compliance personnel to view exception details and make manual adjustments.

[0045] The rule maintenance module connects to the rule base of the rule configuration module, the log recording end of the accounting execution module, and the output end of the exception handling module. It is used to statistically analyze accounting data and exception handling records, identify rule defects, and provide a visual rule modification interface. It supports dynamic iteration by modifying rules without modifying the core system code.

[0046] Preferably, the rule configuration module has a built-in rule verification unit;

[0047] The rule verification unit is used to automatically verify the configured rule elements in real time when the operation and maintenance personnel configure the accounting rules through the visual configuration interface.

[0048] The verification content of the rule verification unit shall include at least one or more of the following verifications:

[0049] Loan relationship legality verification: Verify whether the configured debit and credit accounts comply with the preset accounting subject specifications and fund flow logic, and ensure that the account types of both the borrower and lender match the business attributes of the fund project;

[0050] Command association rationality verification: Verify whether the association between the configured operation command and the fund project conforms to the business rules, including verifying whether a single command can be associated with multiple fund projects, whether multiple commands can be associated with the same fund project, and verifying the mutual exclusion relationship between commands;

[0051] Priority logic consistency verification: When multiple operation instructions are associated with the same funding project, or when multiple instructions can trigger the same transaction, verify whether there is a logical conflict in the configured instruction priority, including verifying whether there is a priority circular dependency and whether the priority setting is unique in the same scenario.

[0052] When the rule verification unit detects that there is an anomaly in the configured rule element, it generates an error message on the visual configuration interface, blocks the current rule saving operation, and guides the operation and maintenance personnel to correct the rule element.

[0053] Once the verification is successful, the rule configuration module will store the configured transaction rules in a structured manner in the rule base.

[0054] Preferably, the transaction execution module includes:

[0055] The amount verification unit is used to verify the compliance of the transaction amount before executing the fund transfer operation; the amount verification unit is configured with the verification formula: M≤B×K; where M is the transaction amount, B is the available balance of the corresponding account, and K is the risk adjustment coefficient, which is assigned a value according to the account qualification or business type.

[0056] When M≤B×K, the amount verification unit outputs a verification pass signal, allowing the transaction execution module to continue executing the fund transfer operation;

[0057] When M > B × K, the amount verification unit outputs a verification failure signal, suspends the transaction execution, and sends an abnormal warning signal to the abnormal handling module. The abnormal warning signal includes at least the current account balance, the required transaction amount, and the risk adjustment coefficient information.

[0058] The multi-currency conversion unit is used to automatically call an external exchange rate conversion interface in multi-currency transaction scenarios to obtain the real-time exchange rate at the time of the transaction, and convert the funds to be transferred into RMB according to the real-time exchange rate to ensure the balance of the amounts between the lender and borrower; the multi-currency conversion unit is also used to record the original currency amount, the conversion exchange rate, and the converted RMB amount in the transaction log.

[0059] The mode execution unit is used to select and execute the corresponding transaction logic based on the transaction mode identifier in the instruction parsing result.

[0060] When the transaction mode is bilateral, the execution unit directly completes the fund transfer between the payer's account and the payee's account and generates bilateral transaction vouchers.

[0061] When the transaction mode is chain mode, the mode execution unit triggers multiple fund transfer operations in sequence according to the preset settlement chain order, and verifies the fund balance of each link after each fund transfer is completed to ensure that the fund transfers in each link of the chain are accurate.

[0062] Preferably, the exception handling module includes:

[0063] An anomaly monitoring unit, whose input end is connected to the anomaly signal output end of the accounting execution module, is used to capture anomaly signals in real time during the accounting execution process, classify and mark the captured anomaly signals, and generate standardized anomaly events.

[0064] An automatic handling unit, whose input end is connected to the output end of the anomaly monitoring unit, is used to receive the standardized abnormal events and automatically trigger corresponding handling procedures for different abnormal types according to a preset abnormal handling strategy.

[0065] The manual intervention unit is connected to the anomaly monitoring unit and the accounting execution module, respectively. It provides a visual intervention interface for compliance personnel to view anomaly details and manually adjust rule parameters or accounting parameters through the intervention interface. After manual confirmation, it sends a restart command to the accounting execution module.

[0066] The log recording unit has its input terminals connected to the output terminals of the anomaly monitoring unit, the automatic handling unit, and the manual intervention unit, respectively, and is used to record anomaly details and handling processes to form an anomaly handling log.

[0067] This invention provides a clearing and accounting method based on an intelligent rule engine. It offers the following advantages: The rule configuration module decouples accounting rules from system code, allowing operations personnel to directly configure and modify rules through a visual interface without modifying core code or redeploying. The rule iteration cycle is shortened from several days to several hours, significantly improving business adaptation efficiency and reducing maintenance costs.

[0068] Through a multi-dimensional matching algorithm, priority determination mechanism, and conflict resolution mechanism, the intelligent rule engine accurately matches funds and operational instructions. For complex scenarios such as cross-freezing / unfreezing transfers and multiple instruction triggers, it automatically determines rules and order, effectively mitigating risks associated with fund transfers.

[0069] It achieves fully automated processing from instruction parsing, rule matching, transaction execution to anomaly handling, supporting automatic multi-currency conversion and automatic transaction processing in bilateral / chain modes. The automatic diagnostic function of the anomaly handling module significantly reduces the workload of manual verification and lowers the probability of human error.

[0070] By customizing rule parameters and flexibly configuring trigger conditions and priorities, different agency clearing business needs can be quickly adapted. The rule operation and maintenance module supports data-driven rule performance analysis, defect identification, and online modification, enabling rule iteration without system reconstruction. Attached Figure Description

[0071] To more clearly illustrate the technical solutions in this invention or the prior art, the accompanying drawings used in the description of the prior art will be briefly introduced below.

[0072] Figure 1 Flowchart of the clearing and accounting method based on the intelligent rule engine of this invention;

[0073] Figure 2 This invention presents a module architecture diagram of a clearing and accounting system based on an intelligent rule engine.

[0074] Figure 3 Internal logic diagram of the intelligent rule engine module in this invention;

[0075] Figure 4 Workflow diagram of the exception handling module in this invention;

[0076] Figure 5 The internal logic diagram of the accounting execution module in this invention. Detailed Implementation

[0077] To make the objectives, technical solutions, and advantages of the present invention clearer, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings.

[0078] Example 1, as Figures 1 to 5 As shown, this embodiment provides a clearing and settlement method based on an intelligent rule engine, including the following steps:

[0079] Step S1: Visual configuration and storage of accounting rules

[0080] Operations and maintenance personnel can pre-configure and store transaction rules in the rule base through the visual configuration interface provided by the rule configuration module. The configuration interface is presented in form, where operations and maintenance personnel fill in elements such as the fund project name, debit account, credit account, associated operation instruction number, and instruction priority.

[0081] Taking customer fund freezing as an example, the operations and maintenance personnel select "Customer Frozen Funds" as the fund item in the interface, select "Customer Current Account" as the debit account, and select "Deposit Account" as the credit account. In the associated instruction field, they enter two instruction numbers, A2010 and A2017, and set the priority of instruction A2010 to be higher than that of instruction A2017. The system automatically recognizes the priority relationship between these two instructions and displays it visually on the interface.

[0082] For customer fund unfreezing transactions, the operations and maintenance personnel configure the lending relationship as "Debit: Deposit account, Credit: Customer current account", and the associated operation commands are A2011 and A2017. The A2011 command is set to have a higher priority than the A2017 command. At the same time, a mutual exclusion rule is configured to make it clear that this rule is mutually exclusive with the customer's fund freezing rule, that is, the same fund cannot trigger both freezing and unfreezing transactions at the same time.

[0083] For customer commission income business, the loan relationship is configured as "Debit: Customer current account, Credit: Deposit account", and the associated operation instruction is A2031 to send transaction data enhancement instruction and clearing operation. The trigger condition is set as "first receive A2031 instruction to complete transaction data verification, and then execute clearing operation to trigger transaction processing", to ensure the integrity of the commission income business logic.

[0084] For the final settlement amount of the customer, the lending relationship is configured as "Debit: Deposit account, Credit: Customer current account", and the associated operation instruction is A2032 payment notification. This instruction is further configured to support two transaction modes: bilateral mode and chain mode. The system will automatically select the corresponding transaction logic according to the mode identifier carried in the payment notification.

[0085] For customer default compensation business, the loan relationship is configured as "Debit: Deposit Account, Credit: Current Account", the associated operation instruction is A2012 fund transfer instruction, the trigger condition is set as "the default judgment result arrives simultaneously with the A2012 instruction", and the transfer amount is set to not exceed the available balance of the deposit account.

[0086] During each configuration process, the rule verification unit built into the rule configuration module automatically verifies the legality of the configuration content. Verification includes: whether the loan relationship conforms to accounting subject standards, whether the instruction association is reasonable (e.g., whether a single instruction can be associated with multiple funding items, and whether multiple instructions can be associated with the same funding item), and whether there are logical conflicts in priority settings (e.g., whether there are circular dependencies). If the verification finds a problem, the system generates an error message on the interface, guiding the operations and maintenance personnel to correct it before saving.

[0087] After configuration, the system stores the transaction rules in a structured manner in the rule base and indexes them by fund item, instruction type, and business scenario for easy retrieval later. Simultaneously, the system automatically retains rule configuration logs, recording the configurer's account, configuration time, modified content, and version number to ensure traceability of rule changes.

[0088] Step S2: Receiving and parsing liquidation instructions

[0089] The instruction parsing module interfaces with the core clearing system and the IMIX interface of the foreign exchange trading center through standardized interfaces, receiving various clearing operation instructions in real time. This module has multiple built-in interface adapters, enabling it to handle instruction data from different sources and in different formats.

[0090] Taking the receipt of fund unfreezing and freezing instructions A2017 as an example, the instruction parsing module first breaks down the original instruction, extracting core elements such as instruction number, fund account information, fund amount, currency, trigger time, and business scenario identifier. Assume the received instruction content is: Instruction type A2017, fund account is customer A's account (account number 123456), fund amount is one million RMB, trigger time is 10:30 AM on the same day, and business scenario identifier is spot clearing.

[0091] After extraction, the instruction parsing module performs a validity check on the instruction. The check includes: whether the instruction format conforms to preset specifications, whether the fund account exists in the system, whether the account status is normal (e.g., whether the account is frozen or closed), and whether the currency is supported. If all checks pass, a standardized instruction parsing result is generated and temporarily stored in memory in a structured data format for subsequent modules to use.

[0092] If the verification fails, for example, if the fund account specified in the instruction does not exist, the instruction parsing module will directly push an error alert to the error handling module. The error alert includes the error type, error reason, and original instruction information so that maintenance personnel can quickly locate the problem.

[0093] Step S3: Intelligent rule matching and priority determination

[0094] The standardized instruction parsing results generated in step S2 are input into the rule base through the intelligent rule engine module. A multi-dimensional matching algorithm is executed to filter out applicable accounting rules and determine the final accounting order based on preset priorities and conflict resolution mechanisms.

[0095] Taking instruction A2017 as an example, this instruction is associated with both customer frozen funds and customer unfrozen funds rules. The intelligent rule engine module first searches the rule base by instruction number A2017 and finds two candidate rules. Subsequently, the module further filters based on the business scenario identifier "Spot Clearing" and the fund account status in the instruction parsing results. By querying the account status interface, the module obtains that the current account status is "not frozen," and based on this, automatically determines that the customer frozen funds rule should be matched, rather than the customer unfrozen funds rule.

[0096] Regarding instruction priority handling, assuming the system receives instructions A2010 (fund freeze) and A2017 (fund unfreeze and freeze) sequentially within the same time period, and both instructions apply to the same account, the intelligent rule engine module, based on preset priority rules (instruction A2010 has higher priority than instruction A2017), determines to execute the freeze transaction corresponding to instruction A2010 first. Instruction A2017 will be processed only after instruction A2010 is completed. If the account status changes to "frozen" during the execution of instruction A2010, instruction A2017 will automatically match the unfreeze rule instead of the freeze rule to avoid rule conflicts.

[0097] In scenarios where multiple instructions trigger the same transaction, taking customer transaction fee revenue as an example, this transaction can only be triggered if the A2031 instruction is received and the clearing operation is completed simultaneously. When matching rules, the intelligent rule engine module detects that the rule is associated with two triggering conditions. Therefore, it will not immediately trigger the transaction upon receiving only the A2031 instruction. Instead, it waits for the clearing operation instruction to arrive, verifies that both instructions have been received and are in normal condition, and then outputs the matching result to the transaction execution module.

[0098] For rules with mutually exclusive relationships, such as rules for freezing customer funds and rules for unfreezing customer funds, the intelligent rule engine module performs mutual exclusion checks during matching. If a freezing rule has already been matched, the system will reject any matching request for an unfreezing rule for the same fund and record the conflict log for subsequent auditing.

[0099] Step S4: Automated execution of the accounting process

[0100] The accounting execution module automatically generates accounting vouchers based on the accounting rules matched in step S3 and the instruction parsing information generated in step S2, and performs fund transfer operations according to the loan relationship, while recording detailed accounting logs.

[0101] Taking the matched customer frozen funds rule as an example, the lending relationship is "Debit: Customer Current Account, Credit: Deposit Account". The transaction execution module automatically generates a debit voucher: Customer Current Account (Account Number 123456) deducts one million yuan; credit voucher: Deposit Account (Account Number 654321) increases by one million yuan.

[0102] Before executing a fund transfer, the amount verification unit uses a preset verification formula to verify the compliance of the transaction amount. Assuming the customer's available balance in their current account is 1.5 million yuan, and the risk adjustment coefficient K is set to a default value of 1.0, if the transaction amount of 1 million yuan is less than or equal to 1.5 million yuan, the verification passes, and the transfer continues. If the account balance is only 800,000 yuan, the verification fails, the system suspends the transaction, and triggers an anomaly warning.

[0103] In multi-currency transaction scenarios, assuming a USD-settled A2032 payment notification instruction is received, while the account currency specified in the transaction rules is RMB, the multi-currency conversion unit of the transaction execution module automatically calls an external exchange rate conversion interface to obtain the real-time exchange rate at the time of the transaction (assuming the USD / CNY exchange rate is 7.15), converting the USD 100,000 to be transferred into RMB 715,000. The converted RMB amount is then used as the transaction amount for compliance verification. After conversion, the transaction voucher records both the original currency amount and the converted amount, along with the exchange rate used.

[0104] For bilateral transaction processing, taking the bilateral settlement in payment notification A2032 as an example, the transaction execution module directly completes the fund transfer between the accounts of the two parties. Assuming that settlement party A needs to pay settlement party B one million yuan, the module simultaneously generates a debit voucher for account A and a credit voucher for account B, completing the two-way transfer in one go, and recording it as bilateral mode in the transaction log.

[0105] For chain-based accounting, taking a multi-level settlement chain A→B→C→D as an example, the accounting execution module triggers fund transfers sequentially according to the chain order: first, the transfer from A to B is executed, verifying the fund balance at this stage; then, the transfer from B to C is executed, again verifying the fund balance; finally, the transfer from C to D is executed. After each transfer is completed, the module records the accounting voucher and balance change for that stage. After all stages are completed, the fund settlement of the entire chain is confirmed to be complete.

[0106] After the transaction is completed, the module synchronously records a complete transaction log, including: original instruction information, rule matching results, accounts and amounts of both lenders and borrowers, changes in account balances, transaction completion time, exchange rate (if any), transaction mode (bilateral or chained), etc., to ensure that every transaction is traceable.

[0107] Step S5: Monitoring and Handling of Anomalies in Accounting Transactions

[0108] The exception handling module monitors the accounting process in real time, automatically capturing, classifying, and handling various anomalies. This embodiment illustrates this with three typical exception scenarios as examples.

[0109] Scenario 1: Insufficient account balance

[0110] Suppose that upon receiving the A2012 default compensation instruction, the transaction execution module matches the customer's default compensation rules, with the loan relationship being "Debit: Deposit Account, Credit: Current Account," and the transaction amount being 800,000 yuan. The amount verification unit checks the available balance of the deposit account and finds that it is only 500,000 yuan. In the verification formula M≤B×K, where M is 800,000 yuan, B is 500,000 yuan, and K is 1.0, the verification fails.

[0111] The anomaly monitoring unit detects an insufficient balance signal, generates a standardized anomaly event, marks the anomaly type as "insufficient account balance," and includes information such as the current account balance, the required transaction amount, and the account identifier. The automatic handling unit, according to a preset strategy, suspends the current transaction execution and sends a fund replenishment reminder to the operations and maintenance terminal. Simultaneously, it pushes the anomaly information to the manual intervention interface for compliance personnel to view.

[0112] Once the funds are replenished, compliance personnel will confirm and send a restart command through the manual intervention interface, and the fund transfer module will re-execute the fund transfer operation.

[0113] Scenario 2: Rule matching failed

[0114] Suppose a new type of liquidation instruction is received, the corresponding fund item of which has not yet been configured in the rule base. The intelligent rule engine module searches the rule base but fails to find any matching rule, returning a matching failure signal.

[0115] The anomaly monitoring unit detects a rule matching failure signal, generates a standardized anomaly event, marks the anomaly type as "rule matching failure," and attaches detailed information about the instruction (instruction number, fund account, amount, etc.). The automatic processing unit reviews the instruction elements against the rule base configuration, analyzes the cause of the failure, and generates rule optimization suggestions, prompting maintenance personnel to add corresponding accounting rules for the instruction.

[0116] Compliance personnel can view anomaly details and optimization suggestions through a manual intervention interface and decide whether to add new rules based on business needs. If a new rule is added, the rule configuration process will begin, without requiring modification to the core code.

[0117] Scenario 3: Lending Imbalance

[0118] In a multi-currency transaction scenario, if the currency conversion interface returns an incorrect exchange rate due to network latency, resulting in an imbalance between the converted loan and borrowing amounts, the transaction execution module will detect this discrepancy before executing the transfer, triggering a loan-borrowing imbalance anomaly.

[0119] The anomaly monitoring unit captures the anomaly and generates a standardized anomaly event. The automatic handling unit automatically checks the exchange rate conversion process, finds anomalies in the exchange rate data, locates the root cause as an external interface response timeout, and provides a correction solution: reconvert using the settlement exchange rate of the day instead of the real-time exchange rate.

[0120] After the compliance personnel confirm the revised plan, they trigger a retry through the manual intervention interface. The transaction execution module then calls the exchange rate interface again, completes the correct conversion, and executes the transfer.

[0121] Step S6: Rule Optimization and Iteration

[0122] The rules operation and maintenance module regularly compiles transaction data and anomaly handling records, and constructs a rules performance evaluation index system, including indicators such as rule matching accuracy, transaction success rate, and anomaly occurrence rate.

[0123] Suppose that statistics show that the failure rate of a certain type of default compensation payment is significantly higher than that of other rules. Further analysis of the abnormal logs reveals that the main reason for the failure is "the triggering condition is not met", that is, the default judgment result and the A2012 instruction did not arrive in strict synchronization, and the time difference between the two exceeded the system's tolerance range.

[0124] The rule maintenance module marked the rule as a rule to be optimized and analyzed the defect type as "unrigorous triggering conditions". Based on the analysis results, the module generated optimization suggestions: relax the triggering conditions, allowing the default judgment result and the A2012 instruction to arrive successively within a preset time window (such as five seconds) to trigger the payment.

[0125] The operations and maintenance personnel can locate the rule through the visual configuration interface and modify the trigger condition parameters online, changing the arrival time from synchronous to arrival within a five-second time window. During the modification process, the rule verification unit automatically performs legality checks on the new rule, including the legality of the loan relationship, the rationality of the instruction association, and the consistency of priority logic. After the verification passes, the new version rule is stored in the rule base in an incrementing version number manner, while historical versions are retained to support rule rollback.

[0126] After the new version of the rules passes verification, it is pushed to the test environment for validation. Testers simulate default scenarios to verify that the new rules can correctly trigger payment processing without introducing new problems. After successful validation, the new version of the rules is gradually switched to the production environment using a canary release approach. It is first implemented in a small-scale business traffic environment, and after observing for a period of time without any anomalies, it is then fully switched over. The entire iteration process does not require modification of the core system code, nor does it require redeployment of the system.

[0127] Step S7: Filing and Reporting of Accounting Records

[0128] After the accounting process is completed, the system automatically archives and stores the accounting vouchers, accounting logs, instruction information, and exception handling records. The archived data is stored in separate databases and tables according to time, and multiple indexes are created to ensure that the data can be retrieved quickly.

[0129] Meanwhile, the system regularly generates standardized transaction reports, summarizing and statistically analyzing data by funding project, instruction type, and time frame. The report format conforms to the reporting standards stipulated by regulatory agencies and supports automatic data submission to the regulatory system, eliminating the need for manual processing.

[0130] In addition, the system provides a file query interface, allowing compliance personnel to quickly locate the complete record of any historical transaction by combining search criteria such as transaction date, fund account, fund item, and instruction number. This includes transaction vouchers, operation logs, and abnormal handling records, meeting the needs of auditing and compliance verification.

[0131] This invention provides a visual configuration interface through a rule configuration module, completely decoupling the accounting rules from the system's core code. Operations personnel do not need programming skills to configure rule elements such as fund items, loan relationships, associated instructions, and priorities through the interface forms. Once configured, the rules are structured and stored in the rule base, dynamically retrieved during system runtime. Therefore, when business departments need to add new fund items (such as customer subsidies), adjust loan relationships (such as modifying accounts due to changes in accounting policies), or update operation instructions (such as adding the A2050 instruction), operations personnel only need to modify the configuration interface, eliminating the need to go through the traditional full-process development cycle of "requirements analysis - code modification - system testing - deployment." The rule iteration cycle is shortened from several days or even weeks in the traditional model to several hours, significantly improving business adaptation efficiency. At the same time, since no core code modification is required, the risk of introducing new defects due to code changes is avoided, reducing system maintenance costs. Furthermore, the rule configuration log retains information such as the configurer, configuration time, and modification content, ensuring that rule changes are traceable and meeting audit compliance requirements.

[0132] Through its multi-dimensional matching algorithm, priority determination mechanism, and conflict resolution mechanism, the intelligent rule engine module accurately handles instruction association issues in complex scenarios. For scenarios involving simultaneous freezing and unfreezing of accounts, the module automatically matches the corresponding rule based on the account's current status (unfrozen or frozen), avoiding potential errors caused by manual judgment in traditional methods. For scenarios where multiple instructions trigger the same transaction (e.g., receiving fee income simultaneously from instruction A2031 and clearing operations), the module verifies the completion status of multiple instructions, ensuring all preconditions are met before triggering the transaction, preventing errors due to missing instructions. For rules with mutually exclusive relationships (e.g., a single fund cannot be frozen and unfrozen simultaneously), the module performs mutual exclusion checks during matching, rejecting conflicting rule matches and recording the conflict in a log. This effectively mitigates risks such as accidental instruction triggering, loan imbalances, and incorrect fund transfers, ensuring the security of clearing funds and the compliance of clearing operations. Furthermore, the conflict log provides data support for subsequent auditing and rule optimization.

[0133] The fund transfer execution module automates fund transfers, supporting various complex logics such as multi-currency conversion, bilateral mode, and chained mode. For multi-currency scenarios, it automatically calls the exchange rate conversion interface to obtain real-time exchange rates and complete the conversion, eliminating the need for manual exchange rate queries and input, thus avoiding calculation errors that may occur during manual conversion. For the bilateral mode of A2032 payment notifications, the module directly completes the fund transfer between the two accounts; for the chained mode, the module triggers multiple fund transfers sequentially according to the settlement chain, verifying fund balance after each link, achieving fully automated multi-level settlement processing. Furthermore, the exception handling module automatically monitors, classifies, and handles exceptions. For insufficient account balance exceptions, the module automatically pauses the fund transfer and sends a fund replenishment reminder; for rule matching failure exceptions, the module backtracks the instruction elements and generates rule optimization suggestions; for debit / credit imbalance exceptions, the module automatically checks the exchange rate conversion process and locates the root cause of the problem. Simultaneously, the manual intervention interface provides exception details viewing and manual adjustment functions to ensure that complex exceptions can be handled promptly. This significantly reduces the workload of manual verification and lowers the probability of human error. The response time for handling anomalies has been reduced from several hours to minutes, effectively ensuring the continuity of clearing operations.

[0134] Through standardized storage of the rule base and statistical analysis by the rule operation and maintenance module, cross-scenario reuse and dynamic iteration of rules are achieved. The rule base is indexed by funding project, instruction type, and business scenario. Different business scenarios, such as shipping derivatives clearing and spot clearing, can share the same transaction rules, eliminating the need for separate development for each scenario. For example, a rule for freezing customer funds can be applied to multiple clearing products simultaneously; simply marking the applicable business scenario in the rule is sufficient. The rule operation and maintenance module regularly analyzes rule performance indicators, identifies rule defects, and generates optimization suggestions. Operation and maintenance personnel can modify rules online through a visual interface. After automatic verification and testing, the modified rules are smoothly transitioned to the production environment through a canary release. This avoids system redundancy caused by repeatedly developing similar transaction logic for each business scenario in the traditional model, reducing code maintenance costs. The dynamic iteration capability of the rules enables the system to quickly respond to business changes and regulatory policy adjustments without system reconstruction, providing technical support for the continuous development of clearing business.

[0135] Through a visual configuration interface, rule configuration logs, and transaction record archiving, the entire lifecycle of rules is visualized and managed traceably. Operations personnel can intuitively view all currently effective transaction rules through the visual configuration interface, including elements such as the funding item, loan relationship, associated instructions, and priority for each rule, without needing to consult development documentation or developers. The rule configuration log records detailed information for every rule change, including the operator, operation time, and change content, ensuring the traceability of the rule change process. The transaction record archiving system retains transaction vouchers, transaction logs, and anomaly handling records, maintaining them for at least twenty years as required by regulations, and supports multi-dimensional retrieval.

[0136] Example 2: This invention discloses a clearing and settlement system based on an intelligent rule engine. This system includes six core modules: a rule configuration module, an instruction parsing module, an intelligent rule engine module, a settlement execution module, an exception handling module, and a rule maintenance module. These modules cooperate to form a complete closed loop for clearing and settlement operations. Wherein:

[0137] The rule configuration module is the system's rule definition entry point, responsible for transforming the rule knowledge of business personnel into structured data that the system can recognize. This module provides a graphical, visual configuration interface, allowing operations and maintenance personnel to configure, modify, delete, and query accounting rules without writing code.

[0138] In practice, when a business department requests a new funding item, operations and maintenance personnel log into the rule configuration module and fill in the rule elements sequentially in the visual interface. Taking the "Customer Frozen Funds" rule as an example, operations and maintenance personnel need to specify the following: the funding item name is "Customer Frozen Funds"; the lending relationship is set to "the debit is the customer's current account, and the credit is the deposit account"; the associated operation instructions are "A2010 Funds Freeze Instruction" and "A2017 Funds Unfreeze and Freeze Instruction"; the instruction priority is set to "A2010 instruction has higher priority than A2017 instruction"; at the same time, a mutual exclusion rule is configured to clarify that this rule is mutually exclusive with the "Customer Unfreeze Funds" rule, and the same fund cannot trigger both freezing and unfreezing transactions simultaneously.

[0139] The rule configuration module has a built-in rule verification unit that automatically performs multiple checks before maintenance personnel save the rules. The loan relationship validity check verifies whether the configured debit and credit accounts conform to the preset accounting subject specifications, ensuring that the debit account type matches the business attributes of the funding item. The instruction association rationality check verifies whether the association between the configured operation instructions and the funding item conforms to business rules, including checking whether a single instruction can be associated with multiple funding items, whether multiple instructions can be associated with the same funding item, and whether there are mutual exclusion relationships between instructions. The priority logic consistency check verifies whether there are logical conflicts in the configured instruction priorities when the same funding item is associated with multiple operation instructions, or when multiple instructions can trigger the same transaction. This includes checking for circular priority dependencies and whether priority settings are unique within the same scenario.

[0140] When the rule verification unit detects anomalies in the configured rule elements, the system immediately generates error messages in the visual configuration interface and blocks the current rule saving operation, guiding maintenance personnel to correct the rule elements. Only after all verifications pass will the rule configuration module store the configured transaction rules in a structured format in the rule base. The rule base supports categorization and indexing by fund project, instruction type, and business scenario for easy and quick subsequent retrieval. Simultaneously, the system retains rule configuration logs, recording detailed information such as the person configuring the rule, the configuration time, and the modified content for each rule operation, ensuring the integrity and traceability of the rules.

[0141] The instruction parsing module is the system's data access layer, responsible for receiving various operation instructions from external clearing systems and converting them into standardized internal data formats.

[0142] This instruction parsing module connects to the core clearing systems of financial clearing institutions and the IMIX interface of the China Foreign Exchange Trading Center (CFETS) through standardized interfaces. It can receive various clearing operation instructions, including A2010, A2011, A2012, A2017, A2031, and A2032, in real time. For IMIX interface instructions from CFETS, the module has a built-in IMIX interface adaptation unit that automatically performs field mapping and format conversion, ensuring that instructions from different sources can be accurately parsed by the system.

[0143] Upon receiving a raw instruction, the instruction parsing module first extracts the core elements of the instruction, including key fields such as instruction number, fund account information, fund amount, currency, trigger time, and business scenario identifier. Subsequently, the module performs a validity check on the instruction, including verifying whether the instruction format conforms to specifications, whether the fund account exists, whether the account status is normal, and whether the business scenario identifier is valid.

[0144] If the command passes the validity check, the command parsing module generates a standardized command parsing result, which is encapsulated in a unified data structure for easy processing by subsequent modules. If the command fails the validation, for example, due to an incorrect command format, a non-existent account, or an abnormal account status, the module directly pushes an exception alert to the exception handling module and records the original command information for subsequent investigation.

[0145] The intelligent rule engine module is the core decision-making layer of the system. Its input end is connected to the output end of the instruction parsing module to receive standardized instruction parsing results; its data end is connected to the rule base of the rule configuration module to retrieve and match accounting rules from the rule base. This module undertakes the core functions of accurately matching instructions and rules, resolving rule conflicts, and determining the order of accounting transactions.

[0146] The intelligent rule engine module contains three working sub-units: rule matching unit, priority determination unit, and conflict resolution unit.

[0147] The rule matching unit is responsible for executing multi-dimensional matching algorithms. Upon receiving the standardized instruction parsing results, this unit first performs a preliminary search in the rule base by instruction number to find all fund project rules associated with that instruction number. Then, combining the business scenario identifier in the instruction parsing results and the current status of the fund account, the unit performs a secondary filtering of the initially matched rules. For example, for instruction A2017, the rule matching unit finds that this instruction is associated with both "customer frozen funds" and "customer unfrozen funds" rules. At this point, by querying the current status of the fund account—if the account status is "not frozen," the "customer frozen funds" rule is matched; if the account status is "frozen," the "customer unfrozen funds" rule is matched. This multi-dimensional filtering ensures the accuracy of the matching results.

[0148] The priority determination unit is responsible for determining the execution order of multiple rules or instructions. When multiple operation instructions are associated with the same funding item, the priority determination unit determines the execution order of the transactions based on the instruction priorities preset in the rule configuration. For example, for the "customer freezes funds" rule, since instruction A2010 has a higher priority than instruction A2017, when the system receives instructions A2010 and A2017 simultaneously, the priority determination unit will arrange for the transaction corresponding to instruction A2010 to be executed first.

[0149] The conflict resolution unit is responsible for handling various conflict scenarios during rule matching. For mutually exclusive transaction rules, such as the mutually exclusive rules "customer freezes funds" and "customer unfreezes funds," the conflict resolution unit performs mutual exclusion checks during rule matching. If a currently matched rule is mutually exclusive with the rule to be matched, the match is rejected and a conflict log is recorded. For scenarios where multiple instructions trigger the same transaction, the conflict resolution unit checks according to a preset instruction triggering order and completion status. Only when all associated instructions meet the triggering conditions is the completion status of each instruction checked sequentially, and the transaction is triggered in the preset order until all preceding instructions corresponding to the transaction rule have been executed.

[0150] Through the collaborative work of the above three sub-units, the intelligent rule engine module can ensure the accuracy and uniqueness of rule matching in complex scenarios, and output the final determined accounting rules and accounting sequence to the accounting execution module.

[0151] The fund transfer execution module is the system's business execution layer. Its input end connects to the output end of the intelligent rule engine module. It is responsible for automatically executing fund transfer operations based on the matched fund transfer rules and instruction parsing information, and generating corresponding fund transfer vouchers and logs. This fund transfer execution module contains three core sub-units: an amount verification unit, a multi-currency conversion unit, and a mode execution unit.

[0152] The amount verification unit is responsible for verifying the compliance of the transaction amount before executing the fund transfer operation. This unit is configured with the verification formula: M ≤ B × K, where M is the transaction amount, B is the available balance of the corresponding account, and K is the risk adjustment coefficient. The risk adjustment coefficient is assigned a value based on the account's qualifications and business type, typically ranging from 0.9 to 1.0, with a default value of 1.0. When M ≤ B × K, the amount verification unit outputs a verification pass signal, allowing the fund transfer execution module to continue the operation. When M > B × K, the amount verification unit outputs a verification failure signal, suspends the fund transfer execution, and sends an exception warning signal to the exception handling module. This signal includes information such as the current account balance, the required transaction amount, and the risk adjustment coefficient.

[0153] The multi-currency conversion unit is responsible for handling multi-currency transaction scenarios. When the currency information in the instruction parsing result is inconsistent with the account currency specified in the transaction rules, the multi-currency conversion unit automatically calls an external exchange rate conversion interface to obtain the real-time exchange rate at the time of the transaction or the settlement exchange rate of the day. Based on the obtained exchange rate, the unit converts the amount of funds to be transferred into the target account's currency and generates a converted transaction voucher. After completing the currency conversion, the multi-currency conversion unit uses the converted amount as the transaction amount M for compliance verification by the amount verification unit. Simultaneously, the unit records the original currency amount, the conversion exchange rate, and the converted RMB amount in the transaction log to ensure that the amounts of the lender and borrower remain balanced after conversion.

[0154] The mode execution unit is responsible for selecting and executing the corresponding transaction logic based on the transaction mode identifier in the instruction parsing result. When the transaction mode is a bilateral mode, the mode execution unit directly completes the fund transfer between the payer's account and the payee's account, generating a bilateral transaction voucher. When the transaction mode is a chain mode, the mode execution unit triggers multiple fund transfer operations sequentially according to the preset settlement chain order. Specifically, for the settlement chain A→B→C→D, the mode execution unit first executes the fund transfer from A to B, verifying the fund balance of this link; then executes the fund transfer from B to C, verifying the fund balance again; finally, it executes the fund transfer from C to D. After all links are executed, the fund settlement of the entire chain is confirmed to be completed, and a chain transaction voucher is generated.

[0155] After completing each fund transfer operation, the transaction execution module synchronously records a detailed transaction log. The transaction log includes complete information such as instruction information, rule matching results, loan amount, account balance changes, transaction completion time, exchange rate (if any), and transaction mode identifier, providing a data foundation for subsequent audit traceability and rule optimization.

[0156] The exception handling module serves as the system's security layer. Its input is connected to the exception signal output of the accounting execution module. It is responsible for real-time monitoring of anomalies during the accounting execution process and automatically triggering corresponding handling procedures based on the anomaly type. This exception handling module internally comprises four collaborative sub-units: an anomaly monitoring unit, an automatic handling unit, a manual intervention unit, and a log recording unit.

[0157] The anomaly monitoring unit is responsible for capturing abnormal signals generated during the accounting process in real time. Capturing anomaly types includes, but is not limited to, debit / credit imbalance signals, insufficient account balance signals, instruction conflict signals, and rule matching failure signals. The anomaly monitoring unit classifies and marks the captured abnormal signals, generating standardized anomaly events that include the anomaly type, anomaly occurrence time, associated instruction information, and associated account information, and then transmits these events to the automatic processing unit and the log recording unit.

[0158] The automated handling unit is responsible for automatically triggering corresponding handling processes for different anomaly types based on preset anomaly handling strategies. For rule matching failure anomalies, the automated handling unit reviews the instruction elements and rule configurations, analyzes the reasons for the matching failure, and generates rule optimization suggestions. For insufficient account balance anomalies, the automated handling unit suspends the transaction execution and pushes a fund replenishment reminder to the operations and maintenance terminal, reminding relevant personnel to replenish the account funds in a timely manner. For loan-to-deposit imbalance anomalies, the automated handling unit automatically checks the exchange rate conversion and amount entry processes, locates the root cause of the problem, and provides a corrective solution. For instruction conflict anomalies, the automated handling unit calls the intelligent rule engine module to re-determine priorities and resolve conflicts.

[0159] The manual intervention unit provides a visual intervention interface for compliance personnel to view anomaly details and transaction logs. When automated handling fails to fully resolve anomalies, compliance personnel can manually adjust rule parameters or transaction parameters through the intervention interface, such as temporarily adjusting risk adjustment coefficients, modifying instruction priorities, and manually confirming transaction processing. After handling is completed, compliance personnel can send a restart command to the transaction execution module through the intervention interface to resume the transaction process.

[0160] The logging unit is responsible for recording anomaly details and handling processes, forming a complete anomaly handling log. Its inputs are connected to the outputs of the anomaly monitoring unit, automatic handling unit, and manual intervention unit, receiving standardized anomaly events and the execution results of each handling unit. The anomaly handling log is stored in the system log database for statistical analysis and traceability queries by the rule-based operations and maintenance module.

[0161] Through the collaborative work of the above four sub-units, the anomaly handling module forms a complete anomaly control chain of "anomaly capture - classification and marking - automatic handling - manual intervention - log archiving", ensuring that all kinds of anomalies can be handled in a timely and effective manner.

[0162] The rule maintenance module is the system's continuous optimization layer. Its data end is connected to the rule base of the rule configuration module and the log recording end of the accounting execution module. It is responsible for statistical analysis of accounting data and anomaly handling records, identifying rule defects, and supporting dynamic iteration of rules.

[0163] This module periodically collects transaction logs from the transaction execution module and exception handling logs from the exception handling module, and constructs rule performance evaluation metrics based on the collected data. Evaluation metrics include, but are not limited to, rule matching accuracy, transaction success rate, and exception occurrence rate. When an evaluation metric for a transaction rule is detected to be below a preset threshold, the rule maintenance module automatically marks the rule as requiring optimization.

[0164] For entries marked as rules requiring optimization, the rule maintenance module further analyzes their associated anomaly handling records to identify the type of rule defect. Common defect types include unreasonable priority settings, imprecise trigger conditions, and mismatched loan relationships. Based on the analysis results, the module generates specific optimization suggestions, such as adjusting instruction priorities, modifying trigger conditions, and updating loan relationships.

[0165] Operations and maintenance personnel can modify the rules to be optimized online through the visual rule modification interface provided by the rules operation and maintenance module. The modified rules are stored in the rule base as new versions, and the system automatically retains historical versions, supporting rule rollback when necessary. During the modification process, the system automatically verifies the legality of the new rules to ensure the legality of loan relationships, the rationality of instruction associations, and the consistency of priority logic.

[0166] After the new version of the rules passes verification, the rule maintenance module pushes it to the test environment for validation. Once validation is successful, the module gradually transitions the new version of the rules to the production environment using a canary release approach, initially applying it to a small range of business traffic. After confirming there are no anomalies, the application scope is expanded, ultimately completing a smooth iteration of the online accounting rules. The entire iteration process requires no modification to the core system code and no system redeployment, significantly shortening the rule adjustment cycle.

[0167] The above six modules are interconnected through clearly defined interfaces and data flows, forming a complete business loop. The specific collaboration process is as follows:

[0168] The rule configuration module pre-configures and stores the accounting rules, providing the rule foundation for the system. When a clearing operation instruction arrives, the instruction parsing module receives, parses, and verifies the instruction, generating a standardized instruction parsing result. The intelligent rule engine module receives this result, retrieves matching accounting rules from the rule base, and determines the final accounting rules and order through multi-dimensional matching, priority determination, and conflict resolution mechanisms.

[0169] Based on the output of the intelligent rules engine module, the transaction execution module sequentially performs amount verification, multi-currency conversion (if necessary), and fund transfer operations, and records detailed transaction logs. If an anomaly occurs during execution, the anomaly signal is sent to the anomaly handling module, which handles the anomaly automatically or through manual intervention and records the anomaly handling log.

[0170] The rules operation and maintenance module periodically collects data from the rule base and log base, performs rule performance evaluation and defect analysis, and generates optimization suggestions. Operation and maintenance personnel modify rules through the visual interface of the rules operation and maintenance module. After the optimized rules are verified and tested, they are updated to the rule base in a canary release manner, forming a complete closed loop of "rule configuration - command parsing - rule matching - transaction execution - anomaly handling - operation and maintenance monitoring - rule optimization".

[0171] Through the modular design and collaborative work of each module, this invention achieves dynamic configuration of clearing and accounting rules, precise matching of instructions, automated execution of accounting, intelligent handling of anomalies, and continuous optimization of rules, effectively solving technical problems such as poor rule scalability, low accuracy of instruction association, and low efficiency of anomaly handling in the prior art.

[0172] Example 3: Dynamic configuration of rules in multi-currency and multi-mode transaction scenarios

[0173] This embodiment focuses on the specific implementation of the present invention in complex clearing business scenarios, particularly the implementation details of multi-currency settlement, multiple settlement modes, and dynamic rule configuration capabilities. The technical solution described in this embodiment can be applied to business scenarios involving multi-currency settlement and complex settlement chains, such as international shipping derivatives clearing and cross-border spot clearing.

[0174] Multi-currency transaction scenarios:

[0175] Suppose that in an international shipping derivatives clearing transaction, a payment notification instruction A2032 is received, which includes a settlement amount in US dollars. The multi-currency translation unit of the transaction execution module processes it according to the following steps:

[0176] First, the currency information in the instruction is identified as US Dollar (USD), while the account currency specified in the transaction rules is Chinese Yuan (CNY). The multi-currency conversion unit automatically calls the external exchange rate conversion interface to obtain the real-time exchange rate at the time of the transaction (assuming the USD / CNY exchange rate is 7.15).

[0177] Then, the amount of funds to be transferred (US$100,000) is converted into RMB (RMB 715,000), and a converted accounting voucher is generated, recording the debit amount of US$100,000 (original currency) and the credit amount of RMB 715,000 (converted currency).

[0178] Finally, the converted amount of 715,000 yuan was used as the transaction amount M for compliance verification. After the verification was passed, the fund transfer was executed, and the original currency amount, the exchange rate, and the converted RMB amount were recorded in the transaction log to ensure that the amounts between the lender and borrower remained balanced after conversion.

[0179] Bilateral transaction scenario:

[0180] Taking the final settlement in shipping derivatives clearing as an example, when the A2032 instruction in the bilateral mode is received, the mode execution unit directly completes the fund transfer between the accounts of the two parties. Specifically, assuming that settlement object A needs to pay settlement object B 1 million yuan, the system simultaneously generates a debit voucher for account A and a credit voucher for account B, completing the two-way fund transfer in one go and recording the bilateral transaction vouchers.

[0181] Chain-based accounting scenarios:

[0182] Taking multi-level settlement in spot clearing as an example, when the A2032 instruction in chain mode is received, the mode execution unit triggers multiple fund transfers sequentially according to the preset settlement chain order. Assuming the settlement chain is: A→B→C→D, the system first executes the transfer from A to B, verifying the fund balance at this stage; then it executes the transfer from B to C, again verifying the fund balance; finally, it executes the transfer from C to D. After all stages are completed, the system confirms the completion of fund clearing for the entire chain and generates a chain-like transaction voucher.

[0183] Dynamic rule configuration scenarios:

[0184] When the business department needs to add a new funding item, "Customer Discount Subsidy," no core code modification is required. Operations personnel can add a new rule through the visual interface of the rule configuration module: funding item "Customer Discount Subsidy," loan relationship "Debit: Deposit Account, Credit: Customer Current Account," associated operation command "A2050 Discount Subsidy Command," and set the trigger condition to "Received A2050 Command and the coupon code is valid." During configuration, the rule verification unit automatically performs legality checks to ensure the loan relationship is reasonable and the command association is correct. After configuration, the new rule takes effect immediately and can be matched and invoked by the intelligent rule engine module, enabling rapid response to business needs.

[0185] The above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. 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. 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 the present invention.

Claims

1. A clearing and accounting method based on an intelligent rule engine, characterized in that: Includes the following steps: Step S1: Provide a visual configuration interface through the rule configuration module, configure the transaction rules and store them in the rule base. The transaction rules include at least the fund items, loan relationships, associated operation instructions and instruction priorities. Step S2: Receive the liquidation operation instruction through the instruction parsing module, extract the core elements of the instruction, verify the instruction, and generate standardized instruction parsing results; Step S3: Input the standardized instruction parsing results into the rule base through the intelligent rule engine module, filter the matching accounting rules based on the multi-dimensional matching algorithm, and determine the final accounting order and rules according to the preset instruction priority and conflict resolution mechanism. Step S4: The transaction execution module automatically generates transaction vouchers based on the matched transaction rules and instruction parsing results, and performs fund transfer operations according to the debit and credit relationships, while recording transaction logs. Step S5: Monitor the accounting process in real time through the exception handling module, trigger the corresponding handling process when an exception is detected, and restart the accounting process after the handling is completed.

2. The clearing and accounting method based on an intelligent rule engine according to claim 1, characterized in that: In step S3, the multi-dimensional matching algorithm specifically involves: inputting the parsed instruction elements into the rule base; firstly, matching the associated fund project rules according to the instruction number; then, filtering the matching results by combining the current business scenario identifier and fund account status; and outputting at least one transaction rule corresponding to the instruction. The conflict resolution mechanism includes: For scenarios where the same instruction number is associated with multiple transaction rules, the matching rule is automatically selected based on the current status of the fund account: if the fund account is currently not frozen, then the freezing transaction rule is matched; if the fund account is currently frozen, then the unfreezing transaction rule is matched. For scenarios where multiple instructions trigger the same accounting rule, verification is performed according to the preset instruction triggering order and completion status: when multiple related instructions meet the triggering conditions, the completion status of each instruction is verified in turn, and the accounting is triggered in the preset order until all the preceding instructions corresponding to the accounting rule are executed. For transaction rules that have a mutual exclusion relationship, a mutual exclusion check is performed during rule matching. If the currently matched rule and the rule to be matched have a mutual exclusion relationship, the match is rejected and a conflict log is recorded.

3. The clearing and accounting method based on an intelligent rule engine according to claim 1, characterized in that: In step S4, before performing the fund transfer operation, the fund transfer execution module performs compliance verification on the fund transfer amount using the following formula: M≤B×K; where M is the fund transfer amount, B is the available balance of the corresponding account, and K is the risk adjustment coefficient. When the verification result satisfies M≤B×K, the fund transfer execution module continues to execute the fund transfer operation; When the verification result satisfies M > B × K, the transaction execution module suspends the current transaction operation and automatically triggers an anomaly warning, pushing the anomaly information to the anomaly handling module. The anomaly information includes at least the current account balance, the required transaction amount, and the risk adjustment coefficient value.

4. The clearing and accounting method based on an intelligent rule engine according to claim 1, characterized in that: In step S4, the transaction execution module supports multi-currency transaction scenarios, specifically including: When the currency information contained in the instruction parsing result is inconsistent with the account currency specified in the transaction rules, the transaction execution module automatically calls the exchange rate conversion interface to obtain the real-time exchange rate at the time of the transaction or the settlement exchange rate of the day. Based on the exchange rate obtained, the amount of funds to be transferred is converted into the currency of the target account, and a converted transaction voucher is generated. After currency conversion is completed, fund transfer is executed, and the exchange rate and the amount before and after conversion are recorded to ensure that the amounts of the lender and borrower remain balanced after conversion. The converted amount is used as the transaction amount and is subject to compliance verification.

5. The clearing and accounting method based on an intelligent rule engine according to claim 1, characterized in that: In step S4, the transaction execution module supports both bilateral and chain-based transaction processing; wherein, The bilateral transaction mode is as follows: according to the matching transaction rules, the two-way fund transfer between the payer's account and the payee's account is completed simultaneously or sequentially, and the fund settlement of both accounts is directly completed. The chain-like settlement process involves triggering multiple fund transfer operations sequentially based on the order of multiple nodes in the settlement chain. After each transfer is completed, the fund balance of that link is verified, and the fund settlement of the entire chain is confirmed to be completed after all links are executed.

6. The clearing and accounting method based on an intelligent rule engine according to claim 1, characterized in that: It also includes step S6: rule optimization and iteration; Step S6 specifically includes: Step S601: Periodically collect transaction logs and anomaly handling records, and construct rule performance evaluation indicators based on the collected data. The rule performance evaluation indicators include at least rule matching accuracy, transaction success rate, and anomaly occurrence rate. When the evaluation indicator of any transaction rule is lower than a preset threshold, the rule is marked as a rule to be optimized. Step S602: Based on the evaluation indicators of the rule to be optimized and the associated anomaly handling records, analyze the rule defect types, which include at least unreasonable priority settings, imprecise trigger conditions, and mismatched lending relationships; generate optimization suggestions based on the analysis results, which include at least adjusting instruction priority, modifying trigger conditions, and updating lending relationships; Step S603: Modify the rule to be optimized through the visual configuration interface. The modified rule is stored in the rule base as a new version and the historical version is retained to support rule rollback. During the modification process, the new rule is automatically validated for legality. The legality validation includes at least the validation of the loan relationship, the validation of the reasonableness of the instruction association, and the validation of the consistency of the priority logic. Step S604: After the new version of the rules passes verification, it is pushed to the test environment for verification; after verification, the new version of the rules is gradually switched to the production environment in a gray-scale release manner to achieve smooth iteration of online accounting rules; the entire iteration process does not require modification of the system core code.

7. A clearing and accounting system based on an intelligent rule engine, used to implement the method described in any one of claims 1-6, characterized in that: include: The rule configuration module provides a visual configuration interface to receive the transaction rule elements configured by operations and maintenance personnel for different fund projects. The rule elements include at least the fund project name, loan relationship, associated operation instruction number, and instruction priority. The rule configuration module stores the configured transaction rules in a structured manner in the rule library and retains rule configuration logs. The instruction parsing module is used to connect to the external clearing system through a standardized interface, receive clearing operation instructions, extract the core elements of the instructions, verify the legality of the instructions, and generate standardized instruction parsing results. The intelligent rule engine module, whose input is connected to the output of the instruction parsing module, is used to receive standardized instruction parsing results; Its data terminal connects to the rule base of the rule configuration module, and is used to retrieve and match the accounting rules from the rule base; it is used to perform multi-dimensional matching with the rule base based on the instruction parsing results, and determine the final accounting rules and accounting order based on the preset instruction priority and conflict resolution mechanism. The transaction execution module, whose input end is connected to the output end of the intelligent rule engine module, is used to receive matching transaction rules and instruction parsing information, automatically generate transaction vouchers, and execute fund transfer operations according to loan relationships. The transaction execution module has a built-in amount verification unit for verifying the compliance of transaction amounts. The transaction execution module is also used to record transaction logs, which include at least instruction information, rule matching results, loan amounts, account balance changes, and transaction completion time. The exception handling module, whose input end is connected to the exception signal output end of the accounting execution module, is used to monitor exceptions in real time during the accounting execution process. The exceptions include at least the following: loan imbalance, insufficient account balance, instruction conflict, and rule matching failure. The exception handling module is used to automatically trigger the corresponding handling process according to the exception type and provides a manual intervention interface for compliance personnel to view exception details and make manual adjustments. The rule maintenance module connects to the rule base of the rule configuration module, the log recording end of the accounting execution module, and the output end of the exception handling module. It is used to statistically analyze accounting data and exception handling records, identify rule defects, and provide a visual rule modification interface. It supports dynamic iteration by modifying rules without modifying the core system code.

8. A clearing and accounting system based on an intelligent rule engine according to claim 7, characterized in that: The rule configuration module has a built-in rule verification unit; The rule verification unit is used to automatically verify the configured rule elements in real time when the operation and maintenance personnel configure the accounting rules through the visual configuration interface. The verification content of the rule verification unit shall include at least one or more of the following verifications: Loan relationship legality verification: Verify whether the configured debit and credit accounts comply with the preset accounting subject specifications and fund flow logic, and ensure that the account types of both the borrower and lender match the business attributes of the fund project; Command association rationality verification: Verify whether the association between the configured operation command and the fund project conforms to the business rules, including verifying whether a single command can be associated with multiple fund projects, whether multiple commands can be associated with the same fund project, and verifying the mutual exclusion relationship between commands; Priority logic consistency verification: When multiple operation instructions are associated with the same funding project, or when multiple instructions can trigger the same transaction, verify whether there is a logical conflict in the configured instruction priority, including verifying whether there is a priority circular dependency and whether the priority setting is unique in the same scenario. When the rule verification unit detects that there is an anomaly in the configured rule element, it generates an error message on the visual configuration interface, blocks the current rule saving operation, and guides the operation and maintenance personnel to correct the rule element. Once the verification is successful, the rule configuration module will store the configured transaction rules in a structured manner in the rule base.

9. A clearing and accounting system based on an intelligent rule engine according to claim 7, characterized in that: The transaction execution module includes: The amount verification unit is used to verify the compliance of the transaction amount before executing the fund transfer operation; the amount verification unit is configured with the verification formula: M≤B×K; where M is the transaction amount, B is the available balance of the corresponding account, and K is the risk adjustment coefficient, which is assigned a value according to the account qualification or business type. When M≤B×K, the amount verification unit outputs a verification pass signal, allowing the transaction execution module to continue executing the fund transfer operation; When M > B × K, the amount verification unit outputs a verification failure signal, suspends the transaction execution, and sends an abnormal warning signal to the abnormal handling module. The abnormal warning signal includes at least the current account balance, the required transaction amount, and the risk adjustment coefficient information. The multi-currency conversion unit is used to automatically call an external exchange rate conversion interface in multi-currency transaction scenarios to obtain the real-time exchange rate at the time of the transaction, and convert the funds to be transferred into RMB according to the real-time exchange rate to ensure the balance of the amounts between the lender and borrower; the multi-currency conversion unit is also used to record the original currency amount, the conversion exchange rate, and the converted RMB amount in the transaction log. The mode execution unit is used to select and execute the corresponding transaction logic based on the transaction mode identifier in the instruction parsing result. When the transaction mode is bilateral, the execution unit directly completes the fund transfer between the payer's account and the payee's account and generates bilateral transaction vouchers. When the transaction mode is chain mode, the mode execution unit triggers multiple fund transfer operations in sequence according to the preset settlement chain order, and verifies the fund balance of each link after each fund transfer is completed to ensure that the fund transfers in each link of the chain are accurate.

10. A clearing and accounting system based on an intelligent rule engine according to claim 7, characterized in that: The exception handling module includes: An anomaly monitoring unit, whose input end is connected to the anomaly signal output end of the accounting execution module, is used to capture anomaly signals in real time during the accounting execution process, classify and mark the captured anomaly signals, and generate standardized anomaly events. An automatic handling unit, whose input end is connected to the output end of the anomaly monitoring unit, is used to receive the standardized abnormal events and automatically trigger corresponding handling procedures for different abnormal types according to a preset abnormal handling strategy. The manual intervention unit is connected to the anomaly monitoring unit and the accounting execution module, respectively. It provides a visual intervention interface for compliance personnel to view anomaly details and manually adjust rule parameters or accounting parameters through the intervention interface. After manual confirmation, it sends a restart command to the accounting execution module. The log recording unit has its input terminals connected to the output terminals of the anomaly monitoring unit, the automatic handling unit, and the manual intervention unit, respectively, and is used to record anomaly details and handling processes to form an anomaly handling log.

Images