A Privacy-Preserving Multi-Party Collaborative Reconciliation Method and System Based on Value Codes

Abstract

This invention belongs to the interdisciplinary field of information technology, fintech, and distributed systems, specifically relating to a privacy-preserving multi-party collaborative reconciliation method and system based on value codes. More specifically, this invention relates to a trusted reconciliation scheme that utilizes programmable "value codes" as the core reconciliation carrier. It aims to solve problems such as inconsistencies in transaction records among multiple participants, cumbersome reconciliation processes, excessive manual intervention, difficulties in dispute resolution, and data privacy leaks by constructing a distributed, auditable, highly transparent, and privacy-preserving reconciliation infrastructure. This solution is applicable to various business scenarios requiring efficient, accurate, and trusted reconciliation, such as cross-institutional transaction clearing, supply chain collaborative reconciliation, multi-party profit sharing verification in platform-based economies, and cross-border business transaction reconciliation. This invention breaks through the limitations of traditional ledgers, inventing value codes as a measure of human value, and constructing a trusted reconciliation axiomatic system based on information economics and game theory. The core algorithm of the system integrates: a transaction energy level mapping operator based on log-normal distribution, a reconciliation utility evaluation model based on Milgrom's information value equation, and a non-cooperative game-theoretic collaborative engine based on Nash algorithm.

Description

Technical Field

[0001] This invention belongs to the interdisciplinary field of information technology, financial technology and distributed systems, and specifically relates to a privacy-preserving multi-party collaborative reconciliation method and system based on value codes. Background Technology

[0002] With the acceleration of digitalization, data has become a core production factor, making it crucial to ensure its authenticity, integrity, and credibility. Traditional data storage methods, such as local storage, centralized databases, or third-party notary offices, suffer from inherent drawbacks, including data susceptibility to tampering, high storage costs, cumbersome verification processes reliant on the credibility of a central institution, and difficulties in cross-institutional data interoperability. Blockchain technology, with its distributed, immutable, and traceable characteristics, provides a revolutionary solution for building a decentralized and trustworthy data storage system. Numerous studies and practices both domestically and internationally have focused on blockchain-based data storage platforms. The following section introduces and analyzes the main categories of existing technologies.

[0003] In complex business activities, transaction reconciliation is a crucial step in ensuring consistency of accounts among participating parties, safeguarding funds, detecting errors, and resolving disputes. Essentially, it involves establishing and maintaining a shared and credible consensus on the state of accounts in an environment of information asymmetry involving multiple entities, systems, and stages. However, the digitalization and intelligentization of this fundamental financial activity have long lagged behind the development of transactions themselves, becoming a key bottleneck restricting improvements in business efficiency, risk management, and trust building. The evolution of current mainstream reconciliation methods and their inherent, deep-seated technical flaws constitute the real-world context for the systematic solutions proposed in this invention. To completely overturn the aforementioned non-cooperative model, this invention proposes a value code as a measure of human value. In complex multi-party business networks, the value code is no longer merely a data encapsulation container, but rather, like a fundamental unit in physics, it transforms the credit elements of human collaboration behind each transaction into a quantifiable digital benchmark through rigorous mathematical expectation and probability measurement, providing an 'atomic-level' measurement standard for decentralized multi-party reconciliation.

[0004] Traditional Distributed File Reconciliation Model and Its Fundamental Defects. For decades, inter-enterprise reconciliation has primarily relied on a "distributed but non-collaborative" model based on independent accounting systems and file exchange. The standard process typically involves each participating party manually or via scripts exporting transaction logs in specific formats (such as CSV, TXT, and Excel) from their core business systems (such as ERP, payment systems, and financial software) after the agreed-upon reconciliation period (e.g., end of day or week). These files, containing sensitive business data, are exchanged between the parties via File Transfer Protocol (FTP), email, or even physical media (such as USB drives). Subsequently, each party uses local reconciliation software or relies on financial personnel to conduct time-consuming and labor-intensive item-by-item comparisons and reconciliations to identify discrepancies, and repeatedly communicates, confirms, and adjusts accounts offline via telephone, email, and other methods. This model suffers from a series of serious problems rooted in its architectural design: First, it is extremely inefficient, with a lengthy reconciliation cycle. The entire process, from data export and transmission to receipt and manual comparison, typically takes hours or even days, heavily relying on batch processing. This makes it unsuitable for the demands of modern business scenarios such as high-frequency trading and real-time settlement, resulting in high capital costs and long risk windows. Secondly, the error rate remains high, making it difficult to guarantee data quality. Due to the lack of unified semantic standards and data specifications, different systems may define and record the same business concepts (such as "transaction completion time" and "net amount") differently, leading to "garbage in, garbage out." Files are at risk of damage, loss, or tampering during transmission, and relying on manual visual comparison of massive amounts of data is a major source of frequent errors. Thirdly, operating costs are high. This model requires a large number of professional finance and IT personnel for data preparation, transmission monitoring, discrepancy analysis, and cross-departmental communication, making it a typical labor-intensive operation with costs increasing linearly with scale. Fourthly, the process is opaque, leading to high trust costs. Each party operates like a "black box," only seeing their own data and the final discrepancy results, unable to know the other party's data processing logic, the specific time and stage at which the discrepancies occurred. Once discrepancies arise, disputes often escalate into mutual blame and suspicion, resulting in lengthy dispute resolution processes lacking objective evidence and severely damaging business trust. Fifth, security and compliance risks are prominent. Plaintext transaction data is exposed across multiple storage points and transmission links, making it highly vulnerable to data breaches and internal / external attacks, and failing to meet the requirements of regulations such as the General Data Protection Regulation (GDPR) and the Personal Information Protection Law of the People's Republic of China regarding data minimization, security, and access control.

[0005] Limitations and New Bottlenecks of Centralized Reconciliation Platforms. With the development of fintech, centralized reconciliation platform solutions have emerged, led by powerful third parties (such as large banks, clearinghouses, e-commerce platforms, and core supply chain enterprises) to improve reconciliation efficiency and standardization. In this model, all participants upload transaction data to the central platform, which performs centralized data cleaning, matching, and comparison, and then publishes authoritative reconciliation results downstream. Such solutions, through unified data interfaces and formats, address the issues of decentralized decision-making and inconsistent standards to some extent, shortening the reconciliation chain. However, it merely centralizes the decentralized issues and introduces new and more severe technical and trust bottlenecks: First, centralized architectures inherently suffer from single points of failure and performance bottlenecks. The reconciliation platform itself becomes the critical information infrastructure of the entire ecosystem. If service is interrupted due to technical failures, cyberattacks, or operational problems, the reconciliation operations of all participants will immediately cease, resulting in a high concentration of systemic risk. During peak transaction scenarios such as "Double Eleven," the platform's computing power and throughput face extreme challenges. Second, it creates larger-scale "data silos" and privacy black holes. The platform centrally stores all detailed transaction data from all participants, forming a highly valuable but also extremely dangerous "data goldmine." This not only violates the principles of data minimization and purpose limitation but also makes it the ultimate target of Advanced Persistent Threat (APT) attacks. The risk of data misuse and leakage has shifted and amplified from multiple dispersed points to a single centralized point. Furthermore, the trust model has distorted from "multilateral mutual distrust" to "unconditional dependence on centralization." Participants must completely trust that the platform operator will not maliciously tamper with data, will not use data for unfair competition, and that its system algorithm is always correct. This model, which places trust in a single entity, runs counter to the trend of decentralized and verifiable trust technologies, and the platform's own impartiality and reliability are difficult to prove. Finally, the system is closed and lacks scalability. Such platforms are typically "siloed" systems built on specific technology stacks, making it difficult to achieve low-cost, standardized interoperability with heterogeneous external blockchain networks, other consortium reconciliation platforms, or new enterprise digital systems, thus creating new ecological barriers.

[0006] The Exploration and Unfinished Road of Blockchain Reconciliation Solutions. Blockchain technology, with its distributed ledger, immutability, traceability, and automatic execution of smart contracts, offers a revolutionary approach to building next-generation reconciliation systems. Existing explorations mainly focus on two models, but neither has achieved the ideal goal: The first is the full ledger sharing model. In this model, the transaction details of all participants are written into a shared blockchain at the moment of generation, and real-time, automatic atomic-level comparison is achieved through on-chain smart contracts. While this model can theoretically achieve ultimate consistency and automation, the cost is the complete sacrifice of business privacy. Competitors, unrelated partners, and even the public can view core sensitive information such as specific transaction amounts, transaction frequencies, and customer relationships, which is absolutely unacceptable in real-world business scenarios. The second is the hash-based notarization model, a compromise on privacy issues. Participants only store the hash value ("digital fingerprint") of the transaction data on the blockchain, while the plaintext data remains stored locally. During reconciliation, both parties still need to exchange plaintext data offline, recalculate the hash, and compare it with the on-chain record. This model is essentially a "patch" of traditional document reconciliation. The blockchain only acts as an immutable "notary office" for evidence in case of disputes afterward. However, it does not change the core issue that the reconciliation process still requires offline data exchange and comparison. It fails to achieve truly automated, verifiable, and privacy-protected reconciliation, i.e., the ideal state of "data available but not visible".

[0007] Beyond Comparison: The Lack of Intelligent Reconciliation and Dispute Resolution. Beyond the core conflict between privacy and automation, existing technological solutions (both traditional and blockchain-based) generally suffer from functional limitations. Most focus only on the basic function of data consistency comparison, lacking support for complex business logic. In modern economic activities, reconciliation is far more than simple monetary matching. For example, in the profit-sharing scenario of the platform economy, complex calculations are involved based on tiered commission rates, promotional subsidies, and refund rules; in supply chain finance, reconciliation may rely on multi-dimensional conditions such as goods receipt status and quality inspection reports. Existing reconciliation systems struggle to programmatically define and automatically execute these dynamic and complex "reconciliation rules," resulting in numerous steps still requiring manual interpretation and intervention of business rules, limiting automation to a very low level. More importantly, when irreconcilable differences (disputes) arise, existing systems generally lack an inherent, reliable resolution mechanism. The entire process was forced to deviate from the digital system and revert to primitive offline communication: repeatedly pulling and shoving through emails and phone calls to collect scattered paper or electronic evidence such as contracts, shipping documents, and receipts. This was inefficient, and the completeness and authenticity of the evidence were difficult to guarantee. How to reliably introduce and connect off-chain events and evidence to the on-chain reconciliation and arbitration logic to form a digital, end-to-end dispute resolution loop is a link that is generally missing in existing technical solutions, which also means that there is always a "breakpoint" in the reconciliation process that requires manual intervention.

[0008] Summary of Systemic Technological Gaps. In summary, the industry currently faces a series of interconnected and progressively deepening systemic technological gaps in building next-generation trusted transaction reconciliation systems: 1. Lack of a flexible, programmable digital value carrier capable of simultaneously carrying transaction information, reconciliation status, and business rules, serving as the smallest trusted unit for automated reconciliation. 2. Lack of a unified interoperability layer capable of breaking down barriers between heterogeneous systems (on-chain / off-chain, different blockchains, traditional IT) to achieve free flow and state synchronization of value carriers. 3. Lack of a privacy-preserving computation framework deeply embedded in the core reconciliation process to achieve cryptographic verifiability of comparison results without exchanging or exposing plaintext data, thus resolving the paradox of privacy and trusted automation. 4. Lack of a powerful and scalable reconciliation rule engine and smart contract system to support the programmatic expression and automated execution of complex business logic. 5. Lack of a standardized dispute resolution and evidence anchoring protocol seamlessly integrated with the reconciliation process, based on cryptographic primitives and oracle technology, to achieve full-process digitization and automation of discrepancy handling. Currently, there is no mature technical solution on the market that can comprehensively and systematically solve all the above challenges. This invention, based on a deep analysis of these technical pain points and gaps, aims to propose a novel trusted transaction reconciliation method and system based on a "value code" architecture. This provides a complete technical implementation path for building a future reconciliation infrastructure that is efficient, automated, privacy-secure, and possesses legal dispute resolution capabilities. Summary of the Invention

[0009] The technical problems that need to be solved in this invention are: This solves the problems of inefficiency, high error rate, high cost, and long reconciliation cycle caused by the reliance on manual labor and document exchange in traditional reconciliation methods.

[0010] This addresses the issues of single point of failure risk, centralized exposure of data privacy, reliance on trust among participants, and difficulty in supporting interoperability between heterogeneous systems that exist in centralized reconciliation platforms.

[0011] This addresses the contradiction in existing blockchain reconciliation solutions: the shared ledger model lacks privacy protection, while the hash-based evidence storage model cannot achieve automated and verifiable reconciliation.

[0012] This addresses the issue of rigid reconciliation rules that are difficult to define flexibly and execute automatically in complex business scenarios, leading to significant human intervention and interpretation.

[0013] This addresses the issues of cumbersome dispute resolution processes, lack of credible evidence, and inability to automatically trigger compensation or arbitration mechanisms when discrepancies arise in reconciliation.

[0014] To address the problems of inefficiency, privacy breaches, lack of trust, and insufficient automation in existing transaction reconciliation technologies, this invention provides a systematic solution. The core innovation of this solution lies in proposing a novel digital carrier, the "reconciliation value code," and constructing a layered, scalable, and privacy-secure reconciliation network architecture around it. This architecture deconstructs the complex multi-party reconciliation process into standardized steps such as value code generation, circulation, verification, and disposal. By integrating blockchain, cryptography, smart contracts, and distributed computing technologies, it achieves end-to-end automation and trustworthiness from data collection to dispute resolution.

[0015] The system adopts a five-layer architecture, from bottom to top: Data Source and Adaptation Layer: Responsible for interfacing with heterogeneous external systems and serving as the data entry point. Unified Reconciliation Service Layer: The core scheduling and logic processing hub of the system, managing the entire lifecycle of value codes. Privacy Computation Service Layer: Provides cryptographic primitives and computational frameworks to support verification and validation under privacy protection. Reconciliation Application Layer: The user interface and integration interface for users and business systems. Audit and Supervision Layer: Ensures full-process traceability and auditability, and meets compliance and regulatory requirements. The layers communicate loosely through clearly defined APIs and event-driven mechanisms, ensuring the system's flexibility, maintainability, and scalability.

[0016] The unified reconciliation service layer is the "brain" of the system. It abstracts the heterogeneity of the lower layers and provides consistent services to the upper reconciliation applications. It adopts a microservice architecture and includes the following core services: Protocol Conversion: Converts requests and data from different sources (HTTP / HTTPS, gRPC, Kafka, JDBC, Blockchain RPC) into internal standard protocols (such as internal service calls based on gRPC). Identity Authentication and Authorization: Performs strong identity authentication (based on certificates or tokens) on participating parties and checks whether they have permission to access specific data sources or operate specific types of value codes. Implements Role-Based Access Control (RBAC) or Attribute-Based Access Control (ABAC). Flow Control and Circuit Breaking: Prevents malicious or abnormal traffic from impacting internal services. When an adapter or data source malfunctions, it can quickly circuit break to ensure overall system stability. Data Format Standardization: A built-in data mapping engine supports configurable field mapping, cleaning, and transformation rules to ensure that fields such as "order amount" and "payment time" from different systems are unified into the internal standard format. State Machine Engine: Drives the transitions of value code states. It listens for various events (such as "received signatures from all parties," "privacy verification proof verified," and "arbitration result issued") and, based on a predefined state transition graph, calls the corresponding processor to update the value code state and trigger the next action (such as notifying relevant parties or initiating a dispute resolution process). Storage and Indexing Service: Responsible for the persistent storage of value code data. Since value codes may be frequently queried, a hybrid model can be adopted: "hot data" is stored in a high-performance NoSQL database (such as MongoDB, with RCID as the primary key), and "cold data" or key versions are stored on the blockchain for notarization. Simultaneously, multi-dimensional indexes are established (such as by participant DID, time range, transaction type, status, etc.) to support efficient queries. Rule Base: Stores all predefined reconciliation rule templates. Rules support version management. The rule parser and executor can parse rules in DSL or script format. When a value code needs to be verified, the engine loads the rules it references, takes the commitment data in the value code and the proof submitted by the participants as input, performs logical judgments in a sandbox environment, and outputs "match," "mismatch," and difference details (within the limits allowed by privacy protection). Dynamic rule negotiation (advanced feature): In certain peer-to-peer scenarios, participants can dynamically determine the rules and parameters to be used for this reconciliation through a negotiation agreement at the initial stage of value code creation, and write the commitment of the negotiation result into the value code.

[0017] When the verification reveals discrepancies that cannot be automatically reconciled, the system seamlessly switches from "automatic verification" mode to "dispute resolution" mode.

[0018] The first step in discrepancy handling is to attempt automatic reconciliation under preset rules. The rules engine loads the pre-defined strategies for "discrepancy handling": Tolerance reconciliation: If the difference in amount is within the preset absolute value or percentage tolerance range, the system will automatically generate an adjusting entry, mark the value code status as "resolved (auto-reconciliation)," and notify the relevant parties.

[0019] Time window matching: For "one-sided transactions" caused by time-series differences (such as transactions recorded by Party A but delayed by Party B), the system can query whether related transactions appear on the other party within a future period (such as 24 hours). If they do, the reconciliation status is automatically updated to "match successful".

[0020] If auto-reconciliation fails, the "dispute resolution protocol" built into the value code is activated. This is a configurable, multi-level upgradeable smart contract process.

[0021] Level 1: Bilateral Automated Negotiation: The system automatically creates a dispute chain and notifies both parties to the dispute. Within a specified time, both parties can upload additional explanations or evidence (whose hashes are anchored to the chain) via a client. The system may provide a simple "negotiation" smart contract: one party can propose a solution (e.g., "I will bear 60% of the difference"), and the other party can accept or reject it within a time limit. If accepted, the dispute is resolved. Level 2: Third-Party Arbitration: If bilateral negotiation times out or fails, the protocol automatically escalates. Depending on the rules, 3 or 5 arbitrators may be randomly selected from a pre-selected "arbitrator pool" (comprised of industry experts and trusted institutional nodes). The system distributes the core dispute materials (value code, hashes of evidence submitted by both parties, and the difference report) to the arbitrators in encrypted form. The arbitrators decrypt and view the materials using their private keys. Within a specified time, the arbitrators anonymously vote via a smart contract (e.g., choosing to support Solution A, Solution B, or propose Solution C). The smart contract automatically calculates the ruling based on voting rules (e.g., majority rule). The third level involves on-chain evidence preservation and judicial linkage: For major disputes that cannot be resolved through on-chain arbitration, the protocol can generate a final evidence package by recording the complete and tamper-proof dispute process (including all evidence hashes, communication records, and voting results). The hash of this evidence package is written into a legally valid judicial blockchain. Participating parties can use this as electronic evidence to file lawsuits with traditional judicial institutions. Because all evidence chains are complete and endorsed by multiple parties, the efficiency and credibility of judicial trials are greatly improved.

[0022] Throughout the dispute resolution process, oracles are responsible for reliably introducing facts from the off-chain world into on-chain logic. Evidence gathering and verification oracles: When a dispute requires external evidence (such as "Please provide the official USD / CNY midpoint rate on December 1, 2023"), the oracle network retrieves data from multiple pre-defined authoritative data sources (such as the central bank's official website, Reuters), reaches a consensus, and then writes the signed data into a smart contract. Event triggering oracles monitor business events from off-chain systems. For example, a logistics company's system automatically sends a signed message to the oracle network when goods are signed for. After the oracle verifies the signature, it triggers the fulfillment of the "cash on delivery" condition in the reconciliation value code.

[0023] The audit trail is modeled using the W3C Verifiable Credentials (VC) standard, making it a verifiable and portable digital credential. Each significant audit event (such as "Value Code status changed to disputed") generates a VC. The issuer of the VC is the microservice performing the operation, the holder is the relevant participant, and the declaration content is the audit event details. The VC itself carries the issuer's digital signature, allowing anyone to verify its authenticity and integrity. Sensitive fields in the declaration are replaced with zero-knowledge proofs. For example, a credential might include a proof stating "The total amount involved in the operation is greater than 1 million RMB (meets regulatory thresholds)," without displaying the specific amount. All VCs generated around the same RCID are cryptographically linked to form a complete and tamper-proof "reconciliation storyline."

[0024] Regulatory agencies join the network as special authorized participants. Each regulatory node runs a regulatory client that can synchronize all audit trails (VCs), but by default only sees anonymized and aggregated information. Regulators can submit a legally binding "investigation order" through the regulatory interface. This order is essentially an access control policy (written in languages ​​like Rego). For example, the policy might be: "Please disclose the counterparty DID and exact amount for all transactions initiated by company DID:did:example:xyz in Q4 2023 with a single transaction amount exceeding 500,000 RMB and a final status of 'Match Successful'." The policy is submitted to the "Regulatory Compliance Smart Contract." The contract automatically parses the policy, locating all eligible target VCs and participants. The contract sends a "Data Disclosure Request" to the relevant participants' clients, containing the hash of the investigation order and the specific data fields to be disclosed. According to internal compliance policies, participating clients, either automatically or after manual approval, use the regulator's public key to encrypt designated sensitive data or generate a specific zero-knowledge proof that satisfies the query (e.g., generating a zk-SNARK proving "the counterparty in this transaction is did:example:abc, and the amount is 550,000.00 yuan"). They then send the encrypted data or proof to the regulatory node. The regulatory node decrypts the data or verifies the proof to obtain the required information. Throughout this process, the original data never leaves the data holder in plaintext; instead, compliant disclosure is achieved under cryptographic protection, perfectly balancing privacy and regulation.

[0025] Through the detailed explanation in the above six parts, this invention provides a complete and self-consistent trusted transaction reconciliation solution based on value codes, encompassing both theoretical models and technical implementation details. It is not merely a technical tool, but rather a foundational protocol and operational framework for "how to reconcile transactions reliably" in the future digital economy, possessing broad application prospects and significant commercial and social value.

[0026] Beneficial effects Improve efficiency and reduce costs: By automating data access, intelligent verification, and programmatic dispute resolution, the traditional reconciliation cycle, which is measured in "days," is shortened to near real-time or near real-time, significantly reducing manual intervention and substantially lowering reconciliation operating costs.

[0027] Enhance trust and reduce disputes: Based on distributed ledger and cryptographic technologies, the reconciliation process is ensured to be open, transparent, and the records are tamper-proof. All participants operate based on the same trusted data source (reconciliation value code), reducing disputes caused by information asymmetry at the source.

[0028] Protecting privacy and ensuring compliance and trustworthiness: The innovative integration of privacy-preserving computation technologies such as zero-knowledge proofs and secure multi-party computation into the reconciliation process achieves reconciliation that is "data usable but not visible," protecting sensitive business information while ensuring the correctness and verifiability of the verification results through cryptography, thus complying with data security regulations.

[0029] Flexible and intelligent processing: Reconciliation rules are decoupled from hard-coded rules and dynamically defined and loaded through programmable value codes and a reconciliation rule engine, enabling flexible support for various complex business reconciliation scenarios. Discrepancy handling and dispute resolution processes are intelligent and automated, forming a closed business loop.

[0030] Open ecosystem and interconnectedness: Through a unified reconciliation layer and adapter design, it can be compatible with heterogeneous data sources such as blockchain and traditional IT systems, breaking down information silos and providing a technical foundation for building a unified reconciliation ecosystem network that spans institutions, industries, and regions. Detailed Implementation

[0031] To address the aforementioned issues, this invention provides a trusted transaction reconciliation method and system based on value codes. The core of this method lies in creating a novel "reconciliation value code" as the smallest trusted unit for recording, verifying, and resolving transaction reconciliation; and constructing a layered, scalable reconciliation network architecture to achieve automated reconciliation and dispute resolution while protecting privacy.

[0032] A trusted transaction reconciliation method based on value codes, characterized by the following steps: Step S1: Definition and Generation of Reconciliation Value Code. A reconciliation value code is a structured, programmable digital object used to encapsulate reconciliation information for a single transaction or a batch of transactions. Its data structure includes at least: a globally unique identifier (ReconciliationCodeID), an associated transaction information digest (TxDigest, including but not limited to anonymized identifiers of both parties, timestamps, transaction type, and commitment values ​​of core elements), a list of participants and their confirmation status (ParticipantStatus, recording the confirmation signatures or zero-knowledge proofs of each relevant party for the transaction record), a reconciliation rule reference (RuleRef, pointing to a predefined business reconciliation rule that can be executed by smart contracts, such as matching rules, tolerance rules, profit-sharing calculation formulas, etc.), the current reconciliation status (ReconciliationState, such as: pending confirmation, confirmed, successful match, discrepancies, under dispute, resolved), and an associated evidence chain anchor (EvidenceAnchor, used to link off-chain evidence related to the transaction reconciliation, such as electronic contract hashes, logistics order hashes, etc.). Specifically, the generation of value codes follows a log-normal distribution logic for energy level mapping. Due to the significant long-tail characteristics of cross-institutional transactions in terms of amount and frequency, the system sets transaction characteristic variables. Its probability density function is expressed as: The system dynamically extracts parameters from each party through maximum likelihood estimation. And perform an integral transformation to generate the core metric weights of the value code. : This algorithm, through logarithmic space transformation, ensures that the value code, as a 'unit of measurement,' has a unified dimensional scale when processing massive amounts of small transactions and huge abnormal transactions.

[0033] Step S2: Construction and Data Access of the Unified Reconciliation Layer. A logically unified reconciliation service layer is constructed. This layer interfaces with heterogeneous data sources from different participants through a series of adapters, including various blockchain networks, traditional databases, and enterprise ERP / financial systems. The adapters are responsible for mapping and encapsulating the raw transaction data from the source systems into a standard "reconciliation value code" draft according to predefined transformation rules, or synchronizing the status of existing external value codes to this layer. The unified reconciliation layer maintains a global reconciliation value code index and a lightweight status synchronization mechanism to ensure that each participant, within its authorized scope, can obtain the value code status view required for reconciliation.

[0034] Step S3: Multi-party collaborative verification with privacy protection. Participating parties access the unified reconciliation layer through their respective reconciliation clients. The system does not require all parties to exchange all transaction data in plaintext. During the verification phase, cryptographic techniques are used to protect privacy: A participant (such as the payee) can generate a zero-knowledge proof that a batch of transaction records held locally and associated with a certain reconciliation value code have statistical summaries (such as sums and averages) of key fields (such as amount and quantity) that match the promised values ​​in the value code, and that all records satisfy the reconciliation rules, without revealing any plaintext details of any individual record.

[0035] When detailed comparison is required, the participating parties or multiple parties use the Secure Multi-Party Computation (MPC) protocol locally to jointly calculate the matching results and details of differences in transaction records without exposing their own plaintext data (for example, only outputting a "list of transaction IDs that Party A has but Party B does not").

[0036] The verification results (whether proof of a successful match or a summary of discrepancies) are submitted to the unified reconciliation layer, triggering an update of the reconciliation value code status. To scientifically quantify the business value generated by eliminating uncertainty in reconciliation, the system introduces Milgrom's information value equation during the verification phase. Let the prior expected risk cost of the system before reconciliation be: When based on value code sequence After the privacy check is passed, the expected posterior risk is reduced to: The marginal information value generated. The calculation is as follows: The system uses this equation to automatically calculate the profit-sharing ratio among multiple parties, enabling reconciliation data elements to participate in the distribution based on their value contribution.

[0037] Step S4: Intelligent discrepancy handling and dispute resolution. When the reconciliation value code status changes to "Difference Exists," the system automatically triggers the discrepancy handling process: First, the system attempts to automatically reconcile accounts according to preset rules, such as automatically balancing accounts within a tolerance range. If automatic reconciliation fails, the system initiates a dispute resolution process based on the pre-defined dispute resolution protocol in the reconciliation value code. The system can automatically request off-chain evidence (such as scanned copies of contracts or stored hashes of receipts) from relevant parties and reliably anchor this evidence to the blockchain via oracle services.

[0038] Dispute resolution can be achieved through pre-defined smart contract arbitration (automatic adjudication based on evidence) or by introducing a decentralized arbitration committee for on-chain voting. The resolution outcome (such as compensation amount and liability determination) will ultimately update the reconciliation value code status to "Resolved" and can automatically trigger related fund settlements or accounting adjustments. When handling consensus on differing states, the system constructs a malicious game-theoretic model based on the Nash Algorithm. (Definition of participating parties follows.) The strategy for submitting data is Its utility function It combines value incentives with audit penalty factors. The system solves for the optimal response set of each party through iterative calculations, ensuring that a unique Nash equilibrium point exists in the system. ,satisfy: This equilibrium point corresponds to all participants choosing the 'honest reconciliation' strategy. Mathematically, it has been proven that any attempt to tamper with the data will lead to a precipitous drop in the subject's utility, thus achieving 'trust without trust'.

[0039] Step S5: End-to-End Audit and Regulatory Support. The entire reconciliation process, from value code generation, party confirmation, verification calculation, to dispute resolution and all key steps and status changes, is recorded immutably on the distributed ledger, forming a complete audit trail. Privacy-related data within the audit trail is presented in the form of commitments or zero-knowledge proofs. Regulatory agencies, as authorized nodes joining the network, can obtain a specific audit view. Subject to legal and regulatory requirements, regulators can conduct thorough reviews of suspected non-compliant transactions using specific keys or protocols to verify their authenticity and compliance.

[0040] The basic logical architecture of the system of this invention is divided into five layers: data source and adaptation layer, unified reconciliation service layer, privacy computing service layer, reconciliation application layer, and audit and supervision layer.

[0041] 1) Data source and adaptation layer: This layer serves as the interface between the system and the external world. Appropriate adapters are deployed for different data source types.

[0042] Blockchain Adapter: Used to connect blockchain networks such as Ethereum, Fabric, and FISCOBCOS. This adapter listens for events of specific contracts on the chain (such as token transfers and transaction creation), captures transaction information, and converts it into a standard transaction data format defined internally by the system. For example, it parses fields such as transaction ID, participants, asset type, and amount from Fabric chaincode events.

[0043] Traditional database adapters connect to enterprise databases such as Oracle and MySQL via JDBC / ODBC, periodically or triggeredly querying specified transaction tables to obtain incremental transaction logs. This adapter requires configuring data mapping rules to map database fields to a standard format.

[0044] API Adapter: Retrieves transaction data by calling the RESTful API or WebService interface provided by the participant. Suitable for scenarios where direct access to the database is not possible, but the other party provides a standard data service interface.

[0045] After acquiring the data, all adapters perform necessary cleaning and anonymization (such as replacing real user IDs with anonymous internal identifiers), generate a draft reconciliation value code, and submit it to the unified reconciliation service layer. Adapters must possess authentication, encrypted data transmission, and breakpoint resume capabilities.

[0046] 2) Unified reconciliation service layer: This layer is the core hub of the system, responsible for the full lifecycle management of reconciliation value codes and the coordination of the reconciliation process.

[0047] Value Code Management Service: Receives draft value codes from the adapter, assigns a globally unique ReconciliationCodeID to each, and sets its initial state to "Pending Confirmation." This service provides interfaces for storing, querying, and updating the status of value codes. The final storage of value codes can be a high-performance distributed database (such as TiDB) or as a sidechain state store; key metadata hashes must be stored on the blockchain for verification.

[0048] Reconciliation Rule Engine: A pluggable rule execution environment. Rules are written in a DSL (Domain-Specific Language) or a standard scripting language (such as JavaScript or Solidity) and describe how to determine whether two or more transactions match, how to calculate profit sharing, and what the allowed amount tolerance is. For example, a rule might be: "If the transaction type is 'product sale,' then matching the order number and amount, with a difference within ±0.01 yuan, is considered successful; if successful, calculate the receivables from each party according to the profit sharing ratio table in the appendix." Event-driven workflow engine: Listens for value code state change events and triggers corresponding follow-up actions. For example, when all participants in a value code have confirmed it, the event is triggered, and the engine calls the privacy computing service layer for verification; when a discrepancy is found during the verification, the discrepancy handling process is triggered, which may include automatically sending notifications, creating dispute tickets, etc.

[0049] 3) Privacy Computing Service Layer: This layer provides the cryptographic infrastructure for privacy-preserving computations during the reconciliation process.

[0050] Zero-knowledge proof service: Deploys ZK proof frameworks such as libsnark, bellman, and circom. When participants choose scheme A for batch verification, this service assists them in "compiling" local data and reconciliation rules into arithmetic circuits and generating proofs. The generated proofs are submitted back to the unified reconciliation layer for rapid verification by the on-chain verification contract.

[0051] Secure Multi-Party Computation Service: Integrates MPC frameworks such as MP-SPDZ and ABY. In the detailed comparison scenario of Solution B, this service coordinates the participating parties to establish a secure channel, runs the MPC protocol, and ultimately outputs only the difference report without disclosing any party's non-difference data.

[0052] Trusted Execution Environment (TEE) service (optional): As another high-performance privacy computing solution, it utilizes hardware TEEs such as Intel SGX and AMD SEV to execute reconciliation logic in encrypted memory, ensuring the confidentiality and integrity of the computing process and data.

[0053] 4) Reconciliation Application Layer: This layer provides a visual interface and API for end users (accounting staff, finance personnel, and business partners).

[0054] Reconciliation portal website / client: Displays a list of reconciliation value codes awaiting confirmation, reconciliation progress (success / difference), difference details (in a privacy-protected format), and a dispute resolution interface. Users can perform actions such as "confirm," "initiate a dispute," and "upload evidence" on the interface.

[0055] Open API: Provides integration interfaces for participants' existing business systems (such as financial software and ERP), enabling them to automatically complete operations such as value code confirmation and receiving reconciliation results, achieving seamless integration with internal enterprise processes.

[0056] 5) Audit and supervision authorities: This layer ensures the auditability and compliance of the system.

[0057] Audit Log Service: An immutable log recording all critical operations (value code creation, state changes, proof verification, dispute resolution, etc.). Each log entry contains the operator (anonymized identifier), the object of the operation (value code ID), the operation type, a timestamp, and the hash of the previous log entry (forming a hash chain).

[0058] Regulatory Interface: Provides regulatory agencies with a dedicated, strictly access-controlled query and monitoring interface. Regulatory nodes can view global reconciliation statistics and risk monitoring indicators. With legal authorization, specific encrypted transaction data can be decrypted or verified through a "regulatory key" or in collaboration with relevant parties, enabling transparent supervision.

[0059] System workflow example: Take the profit-sharing and reconciliation among the three parties—the cross-border e-commerce platform (platform provider), the payment institution (payer), and the logistics company (logistics provider)—as an example.

[0060] Transaction Occurrence and Data Collection: A cross-border order is completed. The payment adapter captures the payment transaction details (amount 1000 RMB, transaction fee rate 2%), generating a draft value code V1. The logistics adapter captures the logistics fee transaction details (fee 200 RMB), generating a draft value code V2. The platform's own system generates the product sales revenue transaction details (cost 700 RMB), generating a draft value code V3. These three drafts are pre-configured by the rules engine and associated with the same "Master Reconciliation Value Code" M.

[0061] Value Code Confirmation: The reconciliation clients of the platform, payment, and logistics parties receive a list of value codes to be confirmed. Each party verifies that the draft information associated with it matches the local records and performs digital signature confirmation. Once all sub-value codes under M have been confirmed, the status of M changes to "Pending Verification".

[0062] Privacy protection verification: The system triggers the reconciliation rule: "Total revenue (platform selling price) = Net amount received by the payer + Logistics fee + Platform profit sharing." None party needs to disclose their specific amount. The payer uses zero-knowledge proof service to prove its local net amount (1000). The statement (1-2%)=980 yuan is correct; the logistics provider proves its cost is 200 yuan; the platform provider proves its recorded revenue is 1000 yuan and its cost is 700 yuan. The system verifies the contract via ZK, confirming that the equation 1000==980+200+(1000-700-? other platform fees) holds true under the commitments provided by all parties, although the specific figures are not explicitly disclosed. Verification passes, and the M status changes to "Reconciliation Successful".

[0063] Discrepancy Handling (Hypothetical Scenario): If the payer's local calculation shows a net amount of 975 yuan (e.g., due to a rate calculation error), the ZK proof fails, and the M state changes to "Discrepancy Exists." The system automatically attempts to reconcile the discrepancy (e.g., automatically balancing within 10 yuan). If this fails, a dispute resolution process is initiated. The platform, acting as the coordinator, requests the payer to provide the original electronic evidence hash of the rate contract. The oracle network retrieves the file digest corresponding to this hash from the off-chain evidence storage system. After comparing it with the evidence hash submitted by the payer, it confirms that the rate should be 2%. The smart contract automatically recalculates and updates the accounts of all parties accordingly, the M state eventually changes to "Resolved," and a settlement instruction is automatically generated.

[0064] Audit and Supervision: All the above steps, from the generation of V1 / V2 / V3, signatures of all parties, generation and verification results of ZK proofs, introduction of disputed evidence, to the final state change, are fully recorded in the audit log for subsequent inquiry by all parties and random checks by regulatory agencies.

[0065] Through the above specific implementation methods, the present invention constructs a complete and reliable reconciliation closed loop from data access, trusted verification, intelligent processing to comprehensive auditing, which can effectively support the needs of efficient, privacy-preserving, and automated reconciliation in various business scenarios.

[0066] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A trusted transaction reconciliation system based on value codes, characterized in that, It adopts a layered architecture, from bottom to top, including: Data source and adaptation layer: used to interface with external heterogeneous data sources through multiple adapters, obtain raw transaction data and convert it into a reconciliation value code draft; Unified Reconciliation Service Layer: As the core scheduling and logic processing hub of the system, it is used to manage the entire lifecycle of reconciliation value codes, including value code management, reconciliation rule execution, and event-driven workflow coordination; Privacy-preserving computation service layer: provides zero-knowledge proofs, secure multi-party computation cryptographic primitives and computation frameworks, and supports verification and validation under privacy protection; Reconciliation Application Layer: Provides a user-friendly visual interface and integration interfaces for business systems; Audit oversight layer: Used to record immutable audit trails and provide a controlled oversight interface for regulatory agencies.

2. The system according to claim 1, characterized in that, The unified reconciliation service layer further includes: a protocol conversion module for converting requests and data from different sources into an internal standard protocol; an identity authentication and authorization module for authenticating and controlling access for participating parties; and a data format standardization module for unifying data fields from different systems into an internal standard format. This module has a built-in log-normal distribution calibration operator for analyzing the heterogeneous transaction strength characteristics of participating parties. The mapping is to a standardized value metric scale, and its mapping function follows the logic of cumulative distribution: A state machine engine listens for events and drives reconciliation value code state transitions based on a predefined state transition graph; a rule base and rule parser executor store, parse, and execute predefined reconciliation rules; and an information value assessment engine based on Milgrom's information value equation. Calculate the value of the information uncertainty eliminated by the successfully matched reconciliation value code, and perform dynamic settlement of reconciliation service fees accordingly. A state consensus and game theory adjudication engine, based on the Nash algorithm, solves the utility functions of each party within a privacy-preserving multi-party computation framework. steady-state solution This is to ensure the absolute reliability of the reconciliation status transfer.

3. The system according to claim 1, characterized in that, The audit oversight layer uses verifiable assertion standards to model audit events, and replaces sensitive fields in the audit trajectory with zero-knowledge proofs. The regulatory agency submits access control policies to the regulatory compliance smart contract, and with the cooperation of the clients of relevant participating parties, obtains the required information in the form of encryption or zero-knowledge proofs, thereby achieving compliant disclosure under privacy protection.

4. A trusted transaction reconciliation method based on value codes, characterized in that, Includes the following steps: S1. Definition and generation of reconciliation value code: Create a structured digital object as the reconciliation value code. The reconciliation value code encapsulates at least a globally unique identifier, an associated transaction information summary, a list of participants and confirmation status, a reconciliation rule reference, the current reconciliation status, and an associated evidence chain anchor. S2. Construction and Data Access of the Unified Reconciliation Layer: Construct a unified reconciliation service layer, and access heterogeneous data sources from different participants through adapters to convert the original transaction data of the source system into a draft reconciliation value code or synchronize the status of external value codes. S3. Multi-party collaborative verification under privacy protection: Participating parties access the unified reconciliation service layer through their respective reconciliation clients. During the verification phase, zero-knowledge proof and / or secure multi-party computation cryptography are used to verify and compare the transaction records associated with the reconciliation value code without exchanging plaintext data. The verification results are then submitted to update the status of the reconciliation value code. S4. Intelligent discrepancy handling and dispute resolution: When there is a discrepancy in the reconciliation value code status indication, the system automatically triggers the discrepancy handling process, including automatic reconciliation based on preset rules, and in the event of automatic reconciliation failure, initiating the dispute handling process according to the preset dispute resolution protocol, wherein the dispute handling process includes off-chain evidence anchoring, smart contract arbitration or on-chain voting by a decentralized arbitration committee. S5. Full-process audit and supervision support: Key steps and status changes in the reconciliation process are recorded in an immutable manner to form an audit trail, and an authorized access mechanism is provided to regulatory agencies so that they can conduct thorough audits in compliance with regulatory requirements.

5. The method according to claim 4, characterized in that, The transaction information summary in step S1 includes the anonymized identifiers of both parties, timestamps, transaction type, and commitment values ​​of core elements; the reconciliation rule references a predefined business reconciliation rule that can be executed by a smart contract.

6. The method according to claim 4 or 5, characterized in that, The heterogeneous data sources in step S2 include blockchain networks, traditional databases, and enterprise ERP / financial systems; the adapters include blockchain adapters, traditional database adapters, and API adapters.

7. The method according to claim 4, characterized in that, In step S3, when zero-knowledge proof technology is used, the participants generate a proof to confirm that the key field statistical summary of the transaction record held locally and associated with the reconciliation value code is consistent with the promised value in the value code, and that all records meet the reconciliation rules, without revealing the plaintext details of a single record.

8. The method according to claim 4, characterized in that, In step S3, when using secure multi-party computation technology, the participating parties jointly calculate the matching results and difference details of the transaction records without exposing their own plaintext data.

9. The method according to claim 4, characterized in that, The dispute resolution process in step S4 is a multi-level escalation process, which includes at least: Level 1, bilateral automatic negotiation: The parties with differences upload evidence and conduct negotiation within the system; Level 2, Introducing Third-Party Arbitration: Arbitrators are selected from a pre-set pool of arbitrators to conduct anonymous voting on encrypted dispute materials for a ruling; Level 3, On-chain Evidence Preservation and Judicial Connection: The complete dispute process is recorded and preserved on the judicial blockchain.

10. The method according to claim 4 or 9, characterized in that, Step S4 also includes using an oracle service to reliably anchor off-chain events or evidence to on-chain logic, for triggering the fulfillment of reconciliation conditions or as evidence for dispute resolution.

Images