Rule configuration and mapping method and device for multi-party settlement, equipment and medium

CN123015015APending Publication Date: 2026-10-30CHINA UNICOM ONLINE INFORMATION TECHNOLOGY CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202610832451.4
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2026-06-10
Publication Date
2026-10-30

AI Technical Summary

Technical Problem

可以解决相关技术中因结算规则缺乏动态配置映射框架、无规则版本管理与零停服更新机制、规则匹配机制不完善易引发规则串用及结算差错、结算数据可追溯性不足的问题

Benefits of technology

[0010]通过本申请,由于采用预设多维度匹配因子及结算逻辑的规则模板生成规则实例并进行版本化管理,支持规则变更时生成增量规则数据同步至各执行节点实现本地缓存更新,结算时先通过精确匹配过滤候选规则再经模糊匹配评分确定最优规则实例,同时在结算完成后生成审计记录,因此,可以解决相关技术中因结算规则缺乏动态配置映射框架、无规则版本管理与零停服更新机制、规则匹配机制不完善易引发规则串用及结算差错、结算数据可追溯性不足的问题,达到结算规则可灵活动态配置与高效变更、规则匹配精准可靠、结算过程规则版本一致且全链路可追溯的技术效果。

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN123015015A_ABST
    Figure CN123015015A_ABST
Patent Text Reader

Abstract

The application discloses a rule configuration and mapping method and device for multi-party settlement, equipment and medium, relates to the technical field of data processing, and comprises the following steps: generating a rule instance based on a preset multi-dimensional matching factor and a settlement logic rule template, assigning a version identifier to the rule instance and storing the rule instance; in response to a rule instance change event, generating incremental rule data and synchronizing the incremental rule data to each execution node to update a local rule cache; when a settlement process is triggered, extracting matching factor values of business data, filtering candidate rules through accurate matching, and determining an optimal rule instance through fuzzy matching scoring; and performing a settlement operation according to the optimal rule and generating full-link audit records. The application realizes dynamic and efficient change of settlement rules, improves the accuracy and reliability of rule matching, and guarantees the rule version consistency and full-link traceability of the settlement process.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a rule configuration and mapping method, apparatus, device and medium for multi-party settlement. Background Technology

[0002] In recent years, third-party payment platform businesses have expanded from single payment channel services to diversified comprehensive payment solutions, forming a complex settlement network involving multiple parties, multiple levels, and multiple contractual constraints. The traditional architecture of independent order and settlement systems is no longer suitable for the needs of business and finance integration transformation.

[0003] In related technologies, the mapping between settlement rules and contracts often adopts a preset pricing mechanism, lacking dynamically configurable rule templates and mapping frameworks that adapt to settlement parameters of different partners. Contract time constraints are only processed with simple Booleanization, which can easily lead to rule jumps at the contract validity boundary in the scenario of batch settlement of accounts. At the same time, the zero-downtime hot loading and multi-node consistency synchronization of settlement rules are not achieved, and there is also a lack of a sound rule version management mechanism, which cannot guarantee the consistency of rule versions during the settlement process. In addition, the rule matching mechanism has defects, which can easily lead to the risk of rule misuse and make it difficult to efficiently and accurately select the optimal settlement rule from a large number of candidate rules, resulting in frequent settlement errors, slow response to rule changes, and insufficient traceability of settlement data. Summary of the Invention

[0004] This application provides a rule configuration and mapping method, apparatus, device, and medium for multi-party settlement. It can solve the problems in related technologies such as the lack of a dynamic configuration and mapping framework for settlement rules, the absence of rule version management and zero-downtime update mechanisms, imperfect rule matching mechanisms leading to rule misuse and settlement errors, and insufficient traceability of settlement data.

[0005] According to a first aspect of this application, a rule configuration and mapping method for multi-party settlement is provided, comprising: Obtain a rule instance generated based on a preset rule template, assign a version identifier to the rule instance and store it, wherein the preset rule template defines matching factors and settlement logic for matching business data in multiple dimensions; In response to a change event of a rule instance, rule data containing the changed content is generated, and the rule data is synchronized to at least one rule execution node to update the local rule cache of each rule execution node; When the settlement process is triggered, the matching factor values ​​of each dimension in the target business data are extracted. Based on the matching factor values, a two-stage rule matching operation is performed from the currently valid rule instances to determine the optimal rule instance. The two-stage rule matching operation includes first performing a first-stage filtering based on precise matching conditions, and then performing a second-stage scoring based on fuzzy matching conditions on the filtered rule instances. According to the settlement logic specified by the optimal rule instance, a settlement operation is performed on the target business data, and corresponding audit records are generated.

[0006] According to a second aspect of this application, a rule configuration and mapping apparatus for multi-party settlement is provided, comprising: The acquisition module is configured to acquire rule instances generated based on a preset rule template, assign a version identifier to the rule instances and store it, wherein the preset rule template defines matching factors and settlement logic for matching business data in multiple dimensions; The generation module is configured to generate rule data containing the changed content in response to a change event of a rule instance, and synchronize the rule data to at least one rule execution node to update the local rule cache of each rule execution node; The matching module is configured to extract the matching factor values ​​of each dimension in the target business data when the settlement process is triggered, and perform a two-stage rule matching operation from the currently valid rule instances based on the matching factor values ​​to determine the optimal rule instance. The two-stage rule matching operation includes first performing a first-stage filtering based on precise matching conditions, and then performing a second-stage scoring based on fuzzy matching conditions on the filtered rule instances. The settlement module is configured to perform settlement operations on the target business data according to the settlement logic specified by the optimal rule instance, and generate corresponding audit records.

[0007] According to a third aspect of this application, an electronic device is provided, comprising: At least one processor; and memory that is communicatively connected to at least one processor; The memory stores instructions that can be executed by at least one processor, which enables the at least one processor to execute the rule configuration and mapping method for multi-party settlement described in the first aspect above.

[0008] According to a fourth aspect of this application, a non-transitory computer-readable storage medium storing computer instructions is provided, wherein the computer instructions are used to cause a computer to execute the rule configuration and mapping method for multi-party settlement described in the first aspect above.

[0009] According to a fifth aspect of this application, a computer program product is provided, including a computer program that, when executed by a processor, implements the rule configuration and mapping method for multi-party settlement as described in the first aspect above.

[0010] This application addresses the challenges of generating rule instances and versioning them using a rule template with preset multi-dimensional matching factors and settlement logic. It supports the generation of incremental rule data and synchronization to each execution node for local cache updates when rules change. During settlement, candidate rules are filtered through precise matching, and the optimal rule instance is determined through fuzzy matching scoring. Simultaneously, an audit record is generated after settlement. Therefore, this solution resolves the problems in related technologies, such as the lack of a dynamic configuration mapping framework for settlement rules, the absence of rule version management and zero-downtime update mechanisms, imperfect rule matching mechanisms leading to rule misuse and settlement errors, and insufficient traceability of settlement data. It achieves the technical effects of flexible and dynamic configuration and efficient modification of settlement rules, accurate and reliable rule matching, consistent rule versions throughout the settlement process, and end-to-end traceability.

[0011] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this application, nor is it intended to limit the scope of this application. Other features of this application will become readily apparent from the following description. Attached Figure Description

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

[0013] Figure 1 This is a flowchart illustrating a rule configuration and mapping method for multi-party settlement provided in an embodiment of this application. Figure 2 This is a schematic diagram of a rule configuration and mapping device for multi-party settlement provided in an embodiment of this application. Detailed Implementation

[0014] The following description, in conjunction with the accompanying drawings, illustrates exemplary embodiments of this application, including various details to aid understanding. These should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this application. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0015] The following description, with reference to the accompanying drawings, describes a rule configuration and mapping method, apparatus, device, and medium for multi-party settlement according to embodiments of this application.

[0016] Figure 1 This is a flowchart illustrating a rule configuration and mapping method for multi-party settlement provided in an embodiment of this application.

[0017] like Figure 1 As shown, the method includes the following steps: Step 101: Obtain a rule instance generated based on a preset rule template, assign a version identifier to the rule instance and store it. The preset rule template defines matching factors and settlement logic for multiple dimensions of business data.

[0018] In some embodiments, a preset rule template serves as a standardized carrier for settlement rules, pre-defining multiple matching factors for matching business data and corresponding settlement logic. Matching factors establish a mapping relationship between business data and settlement rules, while the settlement logic specifies the algorithm for calculating the settlement amount based on the business data. The template design allows different types of settlement rules to be configured according to a unified structure, avoiding fragmentation of rule definitions and supporting adaptation to the differentiated settlement needs of different partners and product types.

[0019] Operations personnel input the corresponding parameters through a visual configuration interface, filling these parameters into a preset rule template to generate a rule instance. Matching factors can cover seven dimensions: partner company identifier, product category code, product code, contract number, contract effective date, contract expiration date, and settlement period, forming a multi-layered constraint system. The settlement logic can include different types of algorithmic expressions such as fee calculation and profit-sharing ratios, adapting to various settlement scenarios including upstream accounts receivable fee calculation, downstream channel fee payment, technical service fee settlement, and channel agent commission allocation.

[0020] The generated rule instances are stored in the rule metadata database in structured JSON format. The version management module automatically generates an incrementing version identifier for each newly generated or modified rule instance to distinguish different iterations of the same rule. The stored metadata includes at least the rule identifier, version identifier, creation time, modification time, effective status, specific values ​​of matching factors for each dimension, and algorithmic expressions representing the settlement logic. The effective status includes four types: draft, effective, expired, and archived, used to identify the availability status of the rule instance at different lifecycle stages.

[0021] By pre-setting standardized rule templates, unified configuration and management of settlement rules are achieved, reducing the complexity of rule definition. The allocation and structured storage of version identifiers make the rule iteration process traceable, facilitating rule querying, rollback, and version management, and providing a fundamental guarantee for the consistency of rule versions in subsequent settlement processes.

[0022] Step 102: In response to a change event of a rule instance, generate rule data containing the changed content, and synchronize the rule data to at least one rule execution node to update the local rule cache of each rule execution node.

[0023] In some embodiments, a change event is automatically triggered when a rule instance in the rule metadata database is created, modified, or deleted. The rule change distribution module in the configuration center monitors change events in the rule metadata database in real time. Upon detecting a change, it does not generate the full set of rule data. Instead, it generates incremental rule data containing only the changed portion based on the differences in rule content before and after the change. This incremental generation method significantly reduces the amount of data that needs to be transmitted, avoids the network bandwidth consumption and processing delays caused by full synchronization, and improves the efficiency of rule updates.

[0024] The rule change distribution module pushes the generated incremental rule data to all deployed rule execution nodes through the event notification mechanism of the message bus. Upon receiving the incremental rule data, each rule execution node directly updates its locally stored rule cache in memory, including adding new rule instances, modifying the content of existing rule instances, or deleting expired rule instances. The entire update process does not require stopping any service processes and will not affect ongoing business processing, achieving zero-interruption service loading of settlement rules.

[0025] By using incremental rule data generation and message bus synchronization mechanisms, efficient and consistent updates of settlement rules are achieved. This solves the problems of service downtime for rule changes and inconsistent rule versions across multiple nodes in the traditional architecture, significantly shortening the response cycle for rule changes and ensuring the continuity and stability of settlement services.

[0026] Step 103: When the settlement process is triggered, extract the matching factor values ​​of each dimension in the target business data. Based on the matching factor values, perform a two-stage rule matching operation from the currently valid rule instances to determine the optimal rule instance. The two-stage rule matching operation includes first performing a first-stage filtering based on precise matching conditions, and then performing a second-stage scoring based on fuzzy matching conditions on the filtered rule instances.

[0027] In some embodiments, the settlement process is typically triggered on a preset settlement start date. The system extracts matching factor values ​​for each dimension corresponding to the target business data from the aggregated business data. These matching factor values ​​are the core basis for establishing a mapping relationship between business data and settlement rules. Their dimensions correspond one-to-one with the matching factors defined in the preset rule template, covering seven dimensions: partner company identifier, product category code, product code, contract number, contract effective date, contract expiration date, and settlement period. The settlement period factor supports matching by calendar month, calendar quarter, and custom cycle, adapting to diverse settlement cycle requirements agreed upon by different partners.

[0028] After extracting the matching factor values, the system performs the first stage of precise matching filtering from the currently effective set of rule instances. Precise matching conditions include: the partner identifier in the business data is the same as the partner identifier in the rule instance; the contract number corresponding to the business data is the same as the contract number in the rule instance; the settlement period of the business data is the same as the settlement period specified in the rule instance; and the occurrence time of the business data falls within the contract validity time window specified by the rule instance. If any precise matching condition is not met, the rule instance is removed from the candidate set. Through this first stage of filtering, the candidate rule set can be compressed from hundreds to dozens or even single digits, significantly reducing the complexity of subsequent matching calculations.

[0029] After the first stage of filtering, the system performs a second stage of fuzzy matching and scoring on the remaining candidate rule instances. The system calculates the matching score between each candidate rule and the target business data using a multi-dimensional scoring model, and finally selects the rule with the highest score as the optimal rule instance.

[0030] The two-stage rule matching mechanism first rapidly narrows down the candidate rule range through precise matching, and then accurately selects the optimal rule through a multi-dimensional scoring model. This improves both the efficiency of rule matching and the accuracy of the matching results. The application of the exponential time decay factor solves the problem of rule jumps at the contract validity boundary, and the design of the indicator function avoids the risk of rule misuse from a mechanism perspective, thus improving the overall reliability and stability of settlement rule matching.

[0031] Step 104: Perform settlement operations on the target business data according to the settlement logic specified by the optimal rule instance, and generate corresponding audit records.

[0032] In some embodiments, the system executes corresponding settlement operations on target business data according to the settlement logic defined by the determined optimal rule instance. Settlement operations are divided into two categories: upstream accounts receivable settlement and downstream accounts payable settlement, respectively adapting to the settlement needs of the third-party payment platform and upstream merchants and downstream partners. Upstream accounts receivable settlement calculates the accounts receivable fees for single or batch business data within the payment period based on the fee rate specified by the optimal rule, generating corresponding upstream settlement statements. Downstream accounts payable settlement allocates the corresponding payable amount from the generated accounts receivable amount according to the profit-sharing ratio or fee rate specified by the optimal rule, generating accounts payable settlement statements for each downstream partner. For example, when an order with a transaction amount of 100 yuan matches the upstream fee rate of 8%, the calculated accounts receivable fee is 8 yuan; if it also matches the downstream channel supplier fee rate of 0.2%, the technology supplier risk control revenue share of 1%, and the channel agent commission of 3%, then the payable channel fee is 0.2 yuan, the risk control revenue share is 1 yuan, and the channel commission is 3 yuan, resulting in a net platform income of 6.8 yuan.

[0033] After the settlement operation is completed, the system automatically generates a full-chain audit log. The audit log fully covers all key nodes of the settlement process, including at least the business data identifier, the identifier and version identifier of the selected optimal rule instance, the extracted values ​​of matching factors for each dimension, the scoring details of rule matching, the execution timestamp of the settlement operation, and detailed settlement details of accounts receivable and accounts payable. All audit logs are persistently stored to ensure that every step of the settlement process is traceable and verifiable.

[0034] Through a unified settlement logic execution framework, it simultaneously supports multiple types of settlement needs from upstream receivables and downstream payables, achieving unified processing of multi-party settlements. The generation of end-to-end audit records ensures the traceability of settlement data, effectively pinpoints the points where settlement errors occur, and improves the transparency and reliability of settlement operations.

[0035] Compared with related technologies, in this embodiment, rule instances generated based on a preset rule template are obtained, a version identifier is assigned to the rule instance and stored, and the preset rule template defines matching factors and settlement logic for multiple dimensions of business data. In response to a change event of a rule instance, rule data containing the changed content is generated and synchronized to at least one rule execution node to update the local rule cache of each rule execution node. When the settlement process is triggered, the matching factor values ​​of each dimension in the target business data are extracted, and based on the matching factor values, a two-stage rule matching operation is performed from the currently valid rule instances to determine the optimal rule instance. The two-stage rule matching operation includes first performing a first-stage filtering based on precise matching conditions, and then performing a second-stage scoring based on fuzzy matching conditions on the filtered rule instances. According to the settlement logic specified by the optimal rule instance, a settlement operation is performed on the target business data, and corresponding audit records are generated. It can solve the problems in related technologies, such as the lack of a dynamic configuration mapping framework for settlement rules, the absence of rule version management and zero-downtime update mechanism, the imperfect rule matching mechanism which easily leads to rule misuse and settlement errors, and insufficient traceability of settlement data. It achieves the technical effect of flexible and dynamic configuration and efficient change of settlement rules, accurate and reliable rule matching, consistent rule versions in the settlement process, and full-link traceability.

[0036] As a specific implementation of this application, based on the basic solution, the step of obtaining a rule instance generated based on a preset rule template, assigning a version identifier to the rule instance and storing it includes: In response to parameters input through the configuration interface, the parameters are filled into a preset rule template to generate a rule instance; The rule instances are stored in a structured data format in the rule metadata database, and the version management module generates an incrementing version identifier for them. The stored metadata includes at least the rule identifier, the version identifier, the effective status, the specific values ​​of the matching factors for each dimension, and the algorithm expression used to characterize the settlement logic.

[0037] Specifically, operators input relevant parameters for settlement rules through a visual configuration interface. The system automatically fills these parameters into a preset rule template, generating a rule instance. The visual configuration interface provides an intuitive parameter input point, allowing rule configuration without writing code, thus lowering the technical barrier to rule configuration. The preset rule template has a standardized structure, and all parameter inputs follow a unified format specification, ensuring that the generated rule instances are structurally consistent and avoiding formatting errors and logical inconsistencies that may occur when manually writing rules.

[0038] The generated rule instances are stored in the rule metadata database in structured JSON format. JSON format offers excellent readability and cross-platform compatibility, facilitating data parsing and transmission between different nodes. It also supports flexible field expansion to adapt to new requirements in subsequent settlement rule dimensions. The version management module automatically generates an incrementing integer version identifier for each newly generated rule instance. Each modification to the same rule generates a new incrementing version number, ensuring that each rule instance has a globally unique identifier and preventing confusion between different version rules.

[0039] The metadata stored in the rule metadata database includes at least a rule identifier, version identifier, effective status, specific values ​​of matching factors for each dimension, and an algorithmic expression representing the settlement logic. The rule identifier is used to globally and uniquely identify a specific settlement rule, while the version identifier distinguishes different iterations of the rule. The effective status indicates the available stage of a rule instance in its lifecycle, including four stages: draft, effective, ineffective, and archived. The draft stage represents an unpublished configuration; the effective stage indicates the rule is eligible for settlement matching; the ineffective stage indicates the rule is no longer in use; and the archived stage is for historical record retention. The specific values ​​of the matching factors for each dimension correspond to all matching dimensions defined in the rule template, and the algorithmic expression explicitly defines the calculation method for the settlement amount in the form of a mathematical formula.

[0040] Generating rule instances through a visual configuration interface simplifies the rule configuration process and improves its efficiency and accuracy. Structured data format storage and the generation of incremental version identifiers ensure the standardization of rule data and the uniqueness of versions. Complete metadata storage provides comprehensive and accurate data support for subsequent rule management, version tracking, and settlement execution.

[0041] As a specific implementation of this application, based on the basic solution, the method further defines the response to the change event of the rule instance, generating rule data containing the changed content, and synchronizing the rule data to at least one rule execution node to update the local rule cache of each rule execution node, including: A change event is triggered when a rule instance in the rule metadata database changes. The rule change distribution module listens for the change events and generates incremental data for the rule changes; The rule change distribution module pushes the incremental data to each rule execution node through an event notification mechanism. Each rule execution node then updates its local rule cache in memory accordingly to achieve zero-interruption service loading of rules.

[0042] Specifically, when a rule instance in the rule metadata database undergoes any of the following operations—creation, modification, or deletion—the database automatically triggers the corresponding change event. This change event carries a unique identifier for the changed rule, the change type, and a timestamp of the change, providing precise location information for subsequent rule distribution and ensuring that only changed rules are included in the synchronization process.

[0043] The rule change distribution module continuously monitors the change event stream in the rule metadata database. Upon capturing a valid change event, it extracts the metadata of the rule instance before and after the change and compares them field by field. Only the content with differences is extracted to generate incremental data for the rule change. The incremental data only contains fields such as the modified matching factor value, settlement algorithm expression, or effective status, rather than the complete rule instance data. This significantly reduces the amount of data that needs to be transmitted and avoids the waste of network resources and processing delays caused by full synchronization.

[0044] The rule change distribution module uses a message bus-based event notification mechanism to broadcast the generated incremental data to all online rule execution nodes. Upon receiving the incremental data, each rule execution node performs an atomic update operation on its local rule cache in memory, adding new rules, modifying fields of existing rules, or removing expired rules based on the change type. The entire update process is completed in memory without stopping any service processes or interfering with ongoing settlement tasks, achieving zero-interruption service loading of settlement rules.

[0045] By synchronizing incremental data generation with message bus broadcasting, the efficiency of rule change transmission and processing is improved, while ensuring rule version consistency across all rule execution nodes. The implementation of zero-disruption service loading completely solves the problem of service downtime for rule changes in traditional architectures, ensuring continuous operation of settlement services and reducing the rule change response cycle from hours to seconds.

[0046] As a specific implementation of this application, the precise matching conditions are further defined based on the basic solution, including: The business data has the same partner identifier as the rule instance, the business data has the same contract number as the rule instance, the business data has the same settlement period as the rule instance, and the business data occurs within the contract validity period window specified in the rule instance. Furthermore, the first stage of filtering includes: if any of the exact matching conditions is not met, then the rule instance is removed from the candidate set.

[0047] Specifically, precise matching criteria are the core screening basis in the first stage of rule matching, encompassing four independent dimensions that must be met simultaneously. The partner identifier is a globally unique identifier distinguishing different upstream merchants and downstream suppliers, ensuring that settlement rules apply only to designated partners. The contract number corresponds to the specific settlement contract signed by both parties, guaranteeing that the basis for settlement execution is completely consistent with the terms stipulated in the contract. Settlement period matching ensures that the rules correspond to the settlement cycle agreed upon by the partners, supporting various settlement period formats such as calendar months, calendar quarters, and custom cycles. The contract validity time window limits the applicable time range of the rules; only rules are eligible for matching if the time of occurrence of business data falls between the contract's effective and expiration dates.

[0048] In the first stage of filtering, the system iterates through all currently active rule instances, verifying the four exact matching conditions in turn. If any condition is not met, the system immediately removes the rule instance from the candidate rule set and removes it from the subsequent matching process. Through this precise filtering stage, the size of the candidate rule set can be compressed from hundreds to dozens or even single digits, significantly reducing the computational load of subsequent matching calculations and significantly improving the overall rule matching processing speed.

[0049] The precise matching and filtering mechanism that fully satisfies all four dimensions can quickly eliminate a large number of irrelevant rules, effectively narrowing down the range of candidate rules. At the same time, it eliminates the risk of misuse of rules across partners, contracts, and payment periods, providing a reliable foundation for the subsequent accurate selection of the optimal settlement rules.

[0050] As a specific implementation of this application, based on the basic scheme, the second-stage score is further defined to calculate the filtered rule instances using the following scoring model: ; in, For matching scores; This is an indicator function that takes the value 1 when the business data meets the exact matching condition, and 0 otherwise; For any factor in the fuzzy matching factor set; As a factor Preset weights; For business data and rule instances in factors Similarity score; This is the time decay coefficient; This is the minimum time difference between the current payment deadline and the contract validity period. This is the priority value for the rule instance; For business data; For settlement rules.

[0051] Specifically, the second-stage scoring, building upon the precise matching and filtering of the first stage, comprehensively evaluates the remaining candidate rule instances using a multi-dimensional quantitative scoring model, ultimately selecting the rule with the highest score as the optimal settlement rule. The scoring model integrates multiple factors influencing rule matching into a single quantitative score through mathematical formulas, achieving standardization and automation in rule selection.

[0052] The calculation formula for the scoring model is:

[0053] In the formula, Represents business data Settlement rules The score indicates the match between the two entities; a higher score means a higher degree of match. This is an indicator function that takes a value of 1 when the business data meets all the exact matching conditions in the first stage, and a value of 0 otherwise. The design of the indicator function ensures that rules that fail to pass the exact matching will not enter the final scoring and ranking, fundamentally eliminating the risk of rule misuse.

[0054] This is a weighted summation term for fuzzy matching.

[0055] It represents any one of the factors in the set of fuzzy matching factors. Fuzzy matching factors usually include dimensions such as product class code and product code. Corresponding factors The preset weights are set according to the importance of each factor in matching the settlement rules; the more important the factor, the greater its weight. For business data and rule instances in factors The similarity score ranges from 0 to 1. Fuzzy matching supports wildcard and regular expression matching. When the business data and the rule instance's factor value are completely identical, the similarity score is 1.0. When using wildcards or regular expressions for partial matching, the similarity score is calculated based on the completeness of the match. Rules with exact matches score higher than those with fuzzy matches, ensuring that more precise rules are selected first.

[0056] This is an exponential time decay term. This is the time decay factor, which is usually set to 0.01. This represents the minimum time difference, in days, between the current payment due date and the contract's expiration date. The exponential time decay term allows the rule score to decrease smoothly as the contract approaches its expiration date and increase smoothly after the new contract takes effect. For example, when there are 30 days left on the contract, e^(-0.01×30)≈0.74, and the rule score drops to about 74% of its original value; when there are 60 days left on the contract, e^(-0.01×60)≈0.55, and the rule score drops to about 55% of its original value. This design avoids sudden jumps in rule scores at the contract's expiration date, achieving a gradual transition between old and new rules.

[0057] This is the priority value for the rule instance. Priority values ​​can be manually specified by operations personnel or automatically optimized based on the rule's historical matching frequency. For settlement rules of important partners or frequently occurring rules, a higher priority value can be set to ensure they are selected first when matching scores are similar, while also improving the matching speed of high-frequency rules.

[0058] The system calculates the matching score for each of the candidate rule instances retained after the first stage of filtering, and finally selects the rule instance with the highest score as the optimal rule instance for subsequent settlement operations.

[0059] By employing a multi-dimensional quantitative scoring model, fuzzy matching degree, time decay characteristics, and rule priority are integrated into a unified matching score, achieving automated and precise selection of optimal rules. The exponential time decay term solves the problem of rule jumps at the contract validity boundary, the indicator function eliminates the risk of rule misuse from a mechanism perspective, and the priority optimization mechanism balances business flexibility and processing efficiency, thereby improving the overall accuracy and stability of rule matching.

[0060] As a specific implementation of this application, based on the basic solution, the settlement operation on the target business data is further defined according to the settlement logic specified by the optimal rule instance, and corresponding audit records are generated, including: When the optimal rule instance is an upstream accounts receivable settlement rule, the accounts receivable amount corresponding to the business data is calculated according to the specified rate, and an upstream settlement statement is generated. When the optimal rule instance is a downstream payable settlement rule, the payable amount to be paid to the target downstream entity is determined from the generated accounts receivable amount according to the settlement logic of its specified profit sharing ratio or fee rate, and a downstream settlement statement is generated. The audit record includes at least the business data identifier, the identifier and version identifier of the selected rule instance, the extracted value of each matching factor, the matching score, and the settlement details of receivables and payables.

[0061] Specifically, settlement operations are categorized into two types based on the optimal rule instance, corresponding to the upstream receivables and downstream payables settlement needs of the third-party payment platform. When the optimal rule instance is an upstream receivables settlement rule, the system extracts the specified fee rate parameter from the rule, calculates the total receivables for single or batch transactions within the payment period, and generates a standardized upstream settlement statement. The upstream settlement statement includes basic merchant information, settlement period, total transaction amount, receivables amount, and transaction fee details for each transaction, serving as the basis for fund settlement with the upstream merchant. For example, when an order with a transaction amount of 100 yuan matches an upstream receivables settlement rule with a fee rate of 8%, the system calculates the receivables for that order to be 8 yuan.

[0062] When the optimal rule instance is a downstream accounts payable settlement rule, the system allocates funds from the corresponding upstream accounts receivable amount based on the profit-sharing ratio or fee rate defined in the rule, determines the amount payable to each downstream entity, and generates an independent downstream settlement bill for each downstream entity. Downstream entities include different types of partners such as channel suppliers, technology suppliers, and channel agents. The settlement logic can adapt to various profit-sharing models such as channel fees, technology service fees, and channel commissions. For example, for the 8 yuan accounts receivable fee generated from the above 100 yuan transaction, if a downstream accounts payable settlement rule with a channel supplier fee rate of 0.2%, a technology supplier risk control share of 1%, and a channel agent commission of 3% is matched, the accounts payable channel fee will be calculated as 0.2 yuan, the risk control share as 1 yuan, and the channel commission as 3 yuan, resulting in a final net income of 6.8 yuan for the platform.

[0063] After the settlement operation is completed, the system automatically generates a full-chain audit record and stores it persistently. The audit record fully covers the key nodes of the settlement process, and includes at least the unique identifier of the business data, the rule identifier and version identifier of the selected optimal rule instance, the matching factor values ​​of each dimension extracted from the business data, the final score of the rule matching process, and detailed calculations of the receivable and payable amounts. All audit records are immutable and support querying and tracing by business data identifier, rule identifier, settlement period, and other dimensions.

[0064] By distinguishing between upstream receivables and downstream payables settlement logic, unified processing of multi-party settlements is achieved, simultaneously meeting the settlement needs of the platform and various upstream and downstream partners. The standardized settlement statement generation process improves settlement efficiency, and the end-to-end tamper-proof audit records ensure the traceability and verifiability of the settlement process, enabling rapid identification of settlement errors and enhancing the transparency and reliability of settlement operations.

[0065] As a specific implementation of this application, the method embodiment further includes, based on the basic solution, the following additional features: When a settlement operation is triggered, the version identifier of the currently active rule instance is associated and bound with the identifier of the current settlement period to ensure that all business data belonging to the same settlement period are settled based on the same version of the rule instance.

[0066] Specifically, when a settlement operation is triggered on the settlement start date, the system will automatically perform an association binding operation between the rule version and the settlement period. The settlement start date is the first day of each settlement cycle. At this time, the system will obtain the latest version identifier of all currently active rule instances, establish a one-to-one correspondence between them and the globally unique identifier of the current settlement period, and persistently store this association in the rule metadata database.

[0067] Once the association and binding are complete, all business data settlement tasks within the entire settlement period will strictly use the bound rule version for matching and calculation. Even if a rule instance is changed during the execution of the settlement period, generating a new rule version, this new version will not be applied to the currently ongoing settlement period. It will only take effect after being bound to the corresponding settlement period on the start date of a subsequent new settlement period. For example, if the settlement start date for the October 2026 settlement period is October 1st, and the system binds the rule instance with version number V2.3 to the 202610 settlement period identifier on that day, and if a settlement rule is modified on October 15th and a V2.4 version is generated, this version will only take effect during the November 2026 settlement period. All transactions within the October 2026 settlement period will still uniformly use the V2.3 version rule for settlement. This binding mechanism fundamentally avoids the situation of multiple rule versions being used interchangeably within the same settlement period, solving the inconsistency problem in traditional architectures where rule changes may lead to some transactions using the old rules and some using the new rules within the same settlement period.

[0068] Beneficial effects: By linking rule versions with settlement periods, the mechanism ensures that the settlement rule versions of all business data within the same settlement period are completely consistent, effectively avoiding settlement errors and reconciliation disputes caused by rule changes within the settlement period, improving the accuracy and consistency of settlement results, and also providing a unified rule basis for subsequent audits and verifications.

[0069] Figure 2 This is a schematic diagram of the structure of a rule configuration and mapping device for multi-party settlement provided in an embodiment of this application, as shown below. Figure 2 As shown, it includes: acquisition module 201, generation module 202, matching module 203, and settlement module 204.

[0070] The acquisition module 201 is configured to acquire a rule instance generated based on a preset rule template, assign a version identifier to the rule instance and store it, wherein the preset rule template defines matching factors and settlement logic for matching business data in multiple dimensions. The generation module 202 is configured to generate rule data containing the changed content in response to a change event of a rule instance, and synchronize the rule data to at least one rule execution node to update the local rule cache of each rule execution node; The matching module 203 is configured to extract the matching factor values ​​of each dimension in the target business data when the settlement process is triggered, and perform a two-stage rule matching operation from the currently valid rule instances based on the matching factor values ​​to determine the optimal rule instance. The two-stage rule matching operation includes first performing a first-stage filtering based on precise matching conditions, and then performing a second-stage scoring based on fuzzy matching conditions on the filtered rule instances. The settlement module 204 is configured to perform settlement operations on the target business data according to the settlement logic specified by the optimal rule instance, and generate corresponding audit records.

[0071] In some examples of this embodiment, the acquisition module 201 is specifically configured to, in response to parameters input through the configuration interface, fill the parameters into a preset rule template to generate a rule instance; store the rule instance in a structured data format in the rule metadata database, and have an incrementing version identifier generated for it by the version management module, wherein the stored metadata includes at least the rule identifier, the version identifier, the effective status, the specific values ​​of the matching factors of each dimension, and the algorithm expression used to characterize the settlement logic.

[0072] In some examples of this embodiment, the generation module 202 is specifically configured to trigger a change event when a rule instance in the rule metadata database changes; the rule change distribution module listens to the change event and generates incremental data of the rule change; the rule change distribution module pushes the incremental data to each rule execution node through an event notification mechanism, and each rule execution node updates its local rule cache in memory accordingly to achieve zero-interruption service loading of rules.

[0073] In some examples of this embodiment, the matching module 203 is specifically configured such that the precise matching conditions include: the partner identifier in the business data is the same as the partner identifier in the rule instance; the contract number corresponding to the business data is the same as the contract number in the rule instance; the settlement period to which the business data belongs is the same as the settlement period specified in the rule instance; and the occurrence time of the business data is within the contract validity time window specified by the rule instance; and the first stage filtering includes: if any of the precise matching conditions are not met, then the rule instance is removed from the candidate set.

[0074] In some examples of this embodiment, the matching module 203 is specifically configured to calculate the filtered rule instances using the following scoring model for the second stage score: ; in, For matching scores; This is an indicator function that takes the value 1 when the business data meets the exact matching condition, and 0 otherwise; For any factor in the fuzzy matching factor set; As a factor Preset weights; For business data and rule instances in factors Similarity score; This is the time decay coefficient; This is the minimum time difference between the current payment deadline and the contract validity period. This is the priority value for the rule instance; For business data; For settlement rules.

[0075] In some examples of this embodiment, the settlement module 204 is specifically configured to, when the optimal rule instance is an upstream accounts receivable settlement rule, calculate the accounts receivable amount corresponding to the business data according to its specified rate and generate an upstream settlement statement; when the optimal rule instance is a downstream accounts payable settlement rule, determine the accounts payable amount payable to the target downstream entity from the generated accounts receivable amount according to the settlement logic of its specified profit sharing ratio or rate and generate a downstream settlement statement; the audit record includes at least the business data identifier, the identifier and version identifier of the selected rule instance, the extracted values ​​of each matching factor, the matching score, and the settlement details of accounts receivable and accounts payable.

[0076] It should be noted that other corresponding descriptions of the functional units involved in the rule configuration and mapping device for multi-party settlement provided in this embodiment can be found in [reference]. Figure 1 The corresponding descriptions in [the document] will not be repeated here.

[0077] Based on the above, Figure 1 This embodiment illustrates a rule configuration and mapping method for multi-party settlement. Correspondingly, it also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described... Figure 1 This paper presents a rule configuration and mapping method for multi-party settlement.

[0078] Based on the above, Figure 1 This embodiment illustrates a rule configuration and mapping method for multi-party settlement. Correspondingly, it also provides a computer program product storing a computer program that, when executed by a processor, implements the above-described... Figure 1 This illustrates a rule configuration and mapping method for multi-party settlement.

[0079] Based on this understanding, the technical solution of this application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as CD-ROM, USB flash drive, mobile hard drive, etc.) and includes several instructions to cause a computer device (such as personal computer, server, or network device, etc.) to execute the methods of various implementation scenarios of this application.

[0080] Based on the above, Figure 1 The method for rule configuration and mapping for multi-party settlement is shown, and Figure 2 To achieve the above objectives, the present application also provides an electronic device, such as a personal computer or a server, in the illustrated virtual device embodiment. This device includes a storage medium and a processor; the storage medium stores a computer program; the processor executes the computer program to implement the above-described virtual device. Figure 1 This paper presents a rule configuration and mapping method for multi-party settlement.

[0081] In some embodiments, the aforementioned physical device may further include a user interface, a network interface, a camera, radio frequency (RF) circuitry, sensors, audio circuitry, a Wi-Fi module, etc. The user interface may include a display screen, an input unit such as a keyboard, etc., and optionally, a USB interface, a card reader interface, etc. In some embodiments, the network interface may include a standard wired interface, a wireless interface (such as a Wi-Fi interface), etc.

[0082] The storage medium may also include an operating system and a network communication module. The operating system is a program that manages the hardware and software resources of the aforementioned physical device, supporting the operation of information processing programs and other software and / or programs. The network communication module is used to enable communication between the various components within the storage medium, as well as communication with other hardware and software in the information processing physical device.

[0083] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes the element.

[0084] The above are merely specific embodiments of this application, enabling those skilled in the art to understand or implement this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to these embodiments, but is to be accorded the widest scope consistent with the principles and novel features claimed herein.

Claims

1. A rule configuration and mapping method for multi-party settlement, characterized in that, include: Obtain a rule instance generated based on a preset rule template, assign a version identifier to the rule instance and store it, wherein the preset rule template defines matching factors and settlement logic for matching business data in multiple dimensions; In response to a change event of a rule instance, rule data containing the changed content is generated, and the rule data is synchronized to at least one rule execution node to update the local rule cache of each rule execution node; When the settlement process is triggered, the matching factor values ​​of each dimension in the target business data are extracted. Based on the matching factor values, a two-stage rule matching operation is performed from the currently valid rule instances to determine the optimal rule instance. The two-stage rule matching operation includes first performing a first-stage filtering based on precise matching conditions, and then performing a second-stage scoring based on fuzzy matching conditions on the filtered rule instances. According to the settlement logic specified by the optimal rule instance, a settlement operation is performed on the target business data, and corresponding audit records are generated.

2. The rule configuration and mapping method for multi-party settlement according to claim 1, characterized in that, The step of obtaining a rule instance generated based on a preset rule template, assigning a version identifier to the rule instance and storing it includes: In response to parameters input through the configuration interface, the parameters are filled into a preset rule template to generate a rule instance; The rule instances are stored in a structured data format in the rule metadata database, and the version management module generates an incrementing version identifier for them. The stored metadata includes at least the rule identifier, the version identifier, the effective status, the specific values ​​of the matching factors for each dimension, and the algorithm expression used to characterize the settlement logic.

3. The rule configuration and mapping method for multi-party settlement according to claim 1, characterized in that, The process of responding to a change event of a rule instance, generating rule data containing the changed content, and synchronizing the rule data to at least one rule execution node to update the local rule cache of each rule execution node includes: A change event is triggered when a rule instance in the rule metadata database changes. The rule change distribution module listens for the change events and generates incremental data for the rule changes; The rule change distribution module pushes the incremental data to each rule execution node through an event notification mechanism. Each rule execution node then updates its local rule cache in memory accordingly to achieve zero-interruption service loading of rules.

4. The rule configuration and mapping method for multi-party settlement according to claim 1, characterized in that, The precise matching conditions include: The business data has the same partner identifier as the rule instance, the business data has the same contract number as the rule instance, the business data has the same settlement period as the rule instance, and the business data occurs within the contract validity period window specified in the rule instance. Furthermore, the first stage of filtering includes: if any of the exact matching conditions is not met, then the rule instance is removed from the candidate set.

5. The rule configuration and mapping method for multi-party settlement according to claim 1, characterized in that, The second-stage scoring is calculated on the filtered rule instances using the following scoring model: ; in, For matching scores; This is an indicator function that takes the value 1 when the business data meets the exact matching condition, and 0 otherwise; For any factor in the fuzzy matching factor set; As a factor Preset weights; For business data and rule instances in factors Similarity score; This is the time decay coefficient; This is the minimum time difference between the current payment deadline and the contract validity period. This is the priority value for the rule instance; For business data; For settlement rules.

6. The rule configuration and mapping method for multi-party settlement according to claim 1, characterized in that, The step of performing settlement operations on the target business data according to the settlement logic specified by the optimal rule instance and generating corresponding audit records includes: When the optimal rule instance is an upstream accounts receivable settlement rule, the accounts receivable amount corresponding to the business data is calculated according to the specified rate, and an upstream settlement statement is generated. When the optimal rule instance is a downstream payable settlement rule, the payable amount to be paid to the target downstream entity is determined from the generated accounts receivable amount according to the settlement logic of its specified profit sharing ratio or fee rate, and a downstream settlement statement is generated. The audit record includes at least the business data identifier, the identifier and version identifier of the selected rule instance, the extracted value of each matching factor, the matching score, and the settlement details of receivables and payables.

7. The rule configuration and mapping method for multi-party settlement according to claim 1, characterized in that, Also includes: When a settlement operation is triggered, the version identifier of the currently active rule instance is associated and bound with the identifier of the current settlement period to ensure that all business data belonging to the same settlement period are settled based on the same version of the rule instance.

8. A rule configuration and mapping device for multi-party settlement, characterized in that, include: The acquisition module is configured to acquire rule instances generated based on a preset rule template, assign a version identifier to the rule instances and store it, wherein the preset rule template defines matching factors and settlement logic for matching business data in multiple dimensions; The generation module is configured to generate rule data containing the changed content in response to a change event of a rule instance, and synchronize the rule data to at least one rule execution node to update the local rule cache of each rule execution node; The matching module is configured to extract the matching factor values ​​of each dimension in the target business data when the settlement process is triggered, and perform a two-stage rule matching operation from the currently valid rule instances based on the matching factor values ​​to determine the optimal rule instance. The two-stage rule matching operation includes first performing a first-stage filtering based on precise matching conditions, and then performing a second-stage scoring based on fuzzy matching conditions on the filtered rule instances. The settlement module is configured to perform settlement operations on the target business data according to the settlement logic specified by the optimal rule instance, and generate corresponding audit records.

9. An electronic device, characterized in that, include: At least one processor; and a memory communicatively connected to the at least one processor; The memory stores instructions that can be executed by the at least one processor, which are executed by the at least one processor to enable the at least one processor to perform the rule configuration and mapping method for multi-party settlement as described in any one of claims 1-7.

10. A non-transitory computer-readable storage medium storing computer instructions, characterized in that, The computer instructions are used to cause the computer to execute the rule configuration and mapping method for multi-party settlement according to any one of claims 1-7.