Reconciliation method and device, electronic equipment and storage medium

Abstract

The invention discloses an account checking method and device, electronic equipment and a storage medium, and relates to the field of financial science and technology. The method comprises the steps of performing financial reconciliation between a hosting party and a business party based on windowed reconciliation and a bidirectional verifiable snapshot chain of bidirectional mutual anchoring of snapshots in a hosting financial reconciliation scene, and checking accounting or data consistency within a compliance disclosure boundary of the two parties, the security of account checking between the two parties is improved, and the efficiency of bidirectional account checking is also improved.

Description

Technical Field

[0001] This application relates to the field of financial technology, and in particular to a reconciliation method, apparatus, electronic device, and storage medium. Background Technology

[0002] In collateral custody services, the custodian and the business party need to reconcile accounts according to the accounting window to ensure regulatory compliance and chain traceability, while controlling data disclosure. Real-world scenarios emphasize reaching consensus, rapid attribution, and solidifying actions without disclosing account details, supporting continuous cross-window processing.

[0003] Existing solutions primarily rely on detailed reconciliation or one-way snapshots. For example, this involves exchanging detailed ledgers or reports, with manual or rule-based verification depending on full disclosure; or each party generating its own snapshot for the current period, comparing them by hash or report, with continuity relying on timestamps or version numbers. However, these methods are not very effective. Therefore, the reconciliation method between the hosting provider and the business party has become a key research focus for professionals in this field. Summary of the Invention

[0004] This application provides a reconciliation method, apparatus, electronic device, and storage medium to improve the security and efficiency of reconciliation between parties.

[0005] According to one aspect of this application, a reconciliation method is provided, comprising:

[0006] The system obtains the compliance disclosure boundaries pre-defined by the custodian and the business party, and jointly cross-signs and references the previous snapshot block of the previous window to generate a window identifier and a backward link. The system then combines the window identifier, the backward link, and the compliance disclosure boundaries to generate a session token. The compliance disclosure boundaries are bound to a pre-defined evidence action library.

[0007] Based on the session token, a state snapshot root, a set commitment root, and a rule commitment summary for the current window corresponding to the custodian's account and asset balance are generated, and the state snapshot root, the set commitment root, and the rule commitment summary are combined into a commitment package;

[0008] Based on the commitment package, generate the difference summary and adjudication target for the current window;

[0009] Based on the aforementioned difference summary, the aforementioned adjudication objective, the aforementioned compliance disclosure boundaries, and the aforementioned evidence action library, generate a minimum necessary proof sequence;

[0010] Path verification is performed based on the minimum necessary proof sequence, the state snapshot root, and the set commitment root, and the consistency of the backward link and cross anchoring is verified, outputting attribution conclusions and evidence indexes;

[0011] The attribution conclusion and the evidence index are checked for consistency, and the check results are snapshotted and solidified to obtain the current snapshot block.

[0012] The current snapshot block undergoes double verification of forward commitment and chain continuity. In response to the successful double verification, the current snapshot block is used as the previous snapshot block for the next window.

[0013] According to another aspect of this application, a reconciliation apparatus is provided, the apparatus comprising:

[0014] The session token generation module is used to obtain the compliance disclosure boundary pre-defined by the custodian and the business party, and jointly cross-sign and reference the previous snapshot block of the previous window to generate a window identifier and a backward link. The window identifier, the backward link and the compliance disclosure boundary are combined to generate a session token. The compliance disclosure boundary is bound to a preset evidence action library.

[0015] The commitment package generation module is used to generate a state snapshot root, a set commitment root, and a rule commitment summary of the current window corresponding to the custodian's account and asset balance based on the session token, and to assemble the state snapshot root, the set commitment root, and the rule commitment summary into a commitment package;

[0016] The difference summary and adjudication target generation module is used to generate the difference summary and adjudication target of the current window based on the commitment package;

[0017] The minimum necessary proof sequence generation module is used to generate a minimum necessary proof sequence based on the difference summary, the adjudication objective, the compliance disclosure boundary, and the evidence action library;

[0018] The attribution and index output module is used to perform path verification based on the minimum necessary proof sequence, the state snapshot root, and the set commitment root, and to verify the consistency of the backward link and cross anchoring, and output the attribution conclusion and evidence index.

[0019] The current snapshot block determination module is used to perform consistency verification on the attribution conclusion and the evidence index, and to solidify the verification result into a snapshot to obtain the current snapshot block.

[0020] The current snapshot block verification module is used to perform dual verification of forward commitment and chain continuity on the current snapshot block. In response to the successful dual verification, the current snapshot block is used as the previous snapshot block of the next window.

[0021] According to another aspect of this application, an electronic device is provided, the electronic device comprising:

[0022] At least one processor; and

[0023] A memory communicatively connected to the at least one processor; wherein,

[0024] The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the reconciliation method described in any embodiment of this application.

[0025] According to another aspect of this application, a computer-readable storage medium is provided, the computer-readable storage medium storing computer instructions for causing a processor to execute and implement the reconciliation method described in any embodiment of this application.

[0026] According to another aspect of this application, a computer program product is provided, the computer program product including a computer program that, when executed by a processor, implements the reconciliation method according to any embodiment of this application.

[0027] In the technical solution of this application embodiment, by using a two-way verifiable snapshot chain based on windowed reconciliation and bidirectional anchoring of snapshots in the scenario of escrow financial reconciliation, financial reconciliation between the escrow party and the business party can be carried out. This enables the verification of the consistency of accounts or data within the compliant disclosure boundaries of both parties, which not only improves the security of reconciliation between the two parties, but also improves the efficiency of two-way reconciliation.

[0028] 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

[0029] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying 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.

[0030] Figure 1 This is a flowchart of a reconciliation method provided according to Embodiment 1 of this application;

[0031] Figure 2 This is a schematic diagram of window reconciliation between the custodian and the business party, as applicable to Embodiment 2 of this application;

[0032] Figure 3 This is a schematic diagram of the structure of an account reconciliation device according to Embodiment 3 of this application;

[0033] Figure 4This is a schematic diagram of the structure of an electronic device that implements the reconciliation method of this application. Detailed Implementation

[0034] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0035] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0036] Example 1

[0037] Figure 1 This application provides a flowchart of a reconciliation method in Embodiment 1. This embodiment is applicable to reconciliation in the case of collateral escrow. The method can be executed by a reconciliation device, which can be implemented in hardware and / or software and can be configured in an electronic device. Figure 1 As shown, the method includes:

[0038] S110. Obtain the compliance disclosure boundary jointly set by the custodian and the business party, and jointly cross-sign and reference the previous snapshot block of the previous window to generate a window identifier and a backward link. Combine the window identifier, the backward link and the compliance disclosure boundary to generate a session token. The compliance disclosure boundary is bound to a preset evidence action library.

[0039] The custodian can be a party requiring collateral custody, such as an individual, organization, or institution; the service provider can be a party offering custody services to the custodian, such as a bank. The conversation window is the interface between the custodian and the service provider for reconciliation interactions. The current window can be the conversation window for the current reconciliation period, while the previous window can be the conversation window for the immediately preceding reconciliation period. A session token is a unique identifier used to identify the current window reconciliation session, containing a window identifier, backlinks, and references to compliance disclosure boundaries. Backlinks are references to the identifier data of the previous window snapshot block, used to establish temporal continuity and traceability. Cross-signing and referencing involves both parties mutually signing the previous window snapshot block and recording a reference to the counterparty's snapshot block in the current window. Snapshot anchoring involves both parties embedding an anchoring field for the counterparty's previous window snapshot block in the current window snapshot block and jointly signing and confirming it. Compliance disclosure boundaries are the scope of evidence disclosure agreed upon by both parties at the start of the session, limiting the allowed types of proof and the detailed scope of prohibited disclosures. The evidence action library is a predefined set of evidence requests and verification actions, including summary-level proof requests, rule interpretation requests, and single-event proof requests and their verification paths.

[0040] Snapshot anchoring can be understood as follows: when the hosting party and the business party create a snapshot block for the current window, they first extract the identification data of the previous window snapshot block of the other party, write the identification data into the anchoring field of the current window, and then both parties jointly sign the anchoring field. This allows the current window snapshot block to simultaneously record the anchoring relationship and signing result of the previous window snapshot block of the other party. The anchoring relationship continues to be referenced in the next window to prevent unilateral rollback or insertion.

[0041] Cross-signing and referencing involves both parties exchanging signed documents generated for the current window. The signature data of the previous window snapshot block of the counterparty is signed, and the signature and reference are recorded in the current window. This binds the counterparty's historical snapshots with the records in the current window. The validity of the bound output window identifier and the backlink is confirmed and used as input for generating the session token.

[0042] The compliance disclosure boundary is a list of permitted proof types and prohibited disclosure details agreed upon by both parties at the start of the session. Both parties jointly sign this boundary and write it into the current window snapshot block. The compliance disclosure boundary is bound to the evidence action library, ensuring that only proof actions necessary to satisfy causal closure are triggered when discrepancies occur. The evidence action library is a set of standard actions that can be invoked, defining request fields, response fields, and verification paths. Actions include requesting summary-level proof, requesting rule interpretation, and requesting single-event proof. Verification paths are based on the current window's state snapshot root and set commitment root, and take effect together with the compliance disclosure boundary to ensure that subsequent evidence exchange follows the minimum necessary disclosure.

[0043] The generation of window identifiers, session tokens, and backlinks is based on the reconciliation window time range and the identities of both parties. The window identifier is formed by the identifier data of the previous window snapshot block. The backlink is formed by combining the window identifier, backlink, and compliance disclosure boundary to form the session token. The session token is used as the input for the generation and exchange of commitment packets to drive subsequent steps.

[0044] S120. Based on the session token, generate the state snapshot root, set commitment root and rule commitment summary of the current window corresponding to the custodian's account and asset balance, and combine the state snapshot root, set commitment root and rule commitment summary into a commitment package.

[0045] Among them, the State Snapshot Root is a verifiable summary of the account and asset balance matrix, used to provide a summary proof path for the asset and account dimensions without disclosing account details; the Set Commitment Root is a verifiable summary of the set of accounting events confirmed in the current window, used to provide proof of the existence of specified events and difference set location without disclosing irrelevant events; the Rule Commitment Summary is an itemized summary of the rule items applicable to the current window, including the identifiers of the pricing model, discount rate, pricing date, and asset classification mapping; the Commitment Package is a data set composed of the State Snapshot Root, Set Commitment Root, and Rule Commitment Summary, and references the window identifier and session token for subsequent verification; the exchange and double signature is when both parties exchange the Commitment Package and sign it respectively to form a consistent confirmation of the commitment content.

[0046] The state snapshot root is generated by hierarchically arranging the account and asset balance matrix according to the asset and account dimensions under the constraints of the window identifier and session token in S110, generating a verifiable summary structure and calculating the root value, which is the state snapshot root. The generation process takes the final balance value of the current window as input, generates leaf summaries in a deterministic order, merges them level by level to obtain the root value, and binds the root value to the window identifier so that subsequent summary-level proofs and single asset proofs can be verified along the structure path.

[0047] The set commitment root is generated by the window identifier and session token constraints of S110, which are used to generate a verifiable set structure and calculate the root value of the accounting event set confirmed in the current window. The root value is the set commitment root. The generation process takes the event entries of the current window as input, encodes them into an entry summary in the order guided by the session token, merges them level by level to obtain the root value, and records the index used for difference location, so that the existence proof and difference location of the specified event are verified based on the set commitment root.

[0048] The rule commitment summary, under the window identifier in S110, is an itemized commitment to the rule items applicable to the current window. Rule items include pricing models, discount rates, pricing dates, and asset classification mappings. A summary value is generated for each rule item and bound to the window identifier to form the rule commitment summary. This allows for interpretation based on the rule commitment summary when a difference is triggered, without disclosing account details. The exchange and double-signing of the commitment package involves combining the aforementioned state snapshot root, set commitment root, and rule commitment summary with the session token to form a commitment package after they are generated. Both parties exchange the commitment package and sign it on the root value and summary value respectively. The signed commitment package serves as input for subsequent S130, providing a unique and verifiable basis for difference summary extraction and adjudication target setting.

[0049] S130. Based on the commitment package, generate the difference summary and adjudication target for the current window.

[0050] The difference summary is a concise description of the scope of the difference without disclosing account details. It includes the asset dimension, the direction of the difference, and the scope referenced by the rule commitment summary. The adjudication objective is the processing target set for the current window reconciliation session, used to limit subsequent definitive attribution under the minimum necessary disclosure. The minimum necessary disclosure is a disclosure strategy that only calls the type of proof necessary to achieve causal closure within the constraints of the compliance disclosure boundary. The definitive attribution is the unambiguous determination result of the cause of the difference, limited to two categories: difference in rule caliber or actual mismatch of assets. The difference direction is an indicator indicating whether the balance difference between the custodian and the business party is positive or negative under the same asset dimension. The asset dimension is the asset identification level determined based on the asset classification mapping in the state snapshot root.

[0051] The difference summary is a summary object generated based on the commitment package of S120. It can be understood as follows: First, the commitment package is verified for signature and consistency of window identifier. After the verification is passed, the state snapshot root, the set commitment root, and the rule commitment summary are extracted. According to the asset classification mapping provided by the rule commitment summary, the corresponding asset dimension is located on the state snapshot root, and a reference relationship is established between the asset dimension and the event mapping associated with the set commitment root. Then, under the constraint of not disclosing account details, by comparing the summary-level identifier of the same asset dimension in both commitment packages with the difference prompt of the set commitment root, a summary record containing only the difference direction and the reference of the affected scope is generated, forming the difference summary. The difference summary is then bound to the session token for S140 to call.

[0052] The goal of the adjudication is to establish a definitive attribution with minimal necessary disclosure. Specifically, this can be achieved by: after generating the difference summary, solidifying the adjudication strategy record for the current window based on the compliance disclosure boundaries and rule commitment summary. The adjudication strategy record limits subsequent actions to only three types: summary-level proof, rule interpretation, and proof of a single event directly related to the difference. It also sets a causal closure as the stopping condition, prohibiting additional requests beyond the asset dimensions listed in the difference summary. Simultaneously, the adjudication strategy record explicitly stipulates the constraint of not disclosing account details, requiring any evidence request to be bounded by the verification path of the state snapshot root and the set commitment root, prohibiting requests for accounts or events not identified in the difference summary. Thus, the difference summary and the adjudication goal are used together as inputs for subsequent S140, driving the generation and execution of the subsequent minimum necessary proof sequence.

[0053] S140. Generate a minimum necessary proof sequence based on the difference summary, the adjudication objective, the compliance disclosure boundary, and the evidence action library.

[0054] The generation of the minimum necessary proof sequence is an ordered list of evidence requests based on the difference summary, adjudication objectives, compliance disclosure boundaries, and evidence action library. This list contains only the evidence requests necessary to achieve a definitive attribution. Rule interpretation proof is evidence that interprets the asset dimension and difference direction referred to in the difference summary according to the rule commitment summary, used to determine whether the difference is caused by an item in the rule commitment summary. Summary-level proof is a summary verification along the verification path of the state snapshot root at the asset dimension, used to verify that the summary balance is consistent with the commitment without disclosing account details. Single event proof is evidence that verifies the existence and scope of influence of a specified event directly related to the difference summary along the verification path of the set commitment root, used to locate the specific event causing the difference without disclosing irrelevant events.

[0055] The minimum necessary proof sequence is an ordered list generated by constraint-generative evidence routing on the difference summary, adjudication objectives, compliance disclosure boundaries, and evidence action library. Specifically, it can be as follows: First, under the constraints of the compliance disclosure boundaries, available actions matching the asset dimensions and difference directions listed in the difference summary are selected from the evidence action library to form a candidate set. Then, constraint-generative evidence routing outputs evidence request items in a coarse-to-fine order. Specifically, rule interpretation proof is output first, requesting a rule-based interpretation of the difference summary using a rule commitment summary and returning an interpretation coverage identifier and remaining difference hints. If causal closure is not achieved, summary-level proof is output sequentially, requesting summary verification of the asset dimensions on the state snapshot root and returning a summary consistency identifier and remaining difference hints. If causal closure is still not achieved, only single event proof is output for items directly related to the difference summary, requesting verification of the event existence and impact on the set commitment root and returning an event impact consistency identifier. The output in a coarse-to-fine order follows a fixed priority chain. Any subsequent request uses the return hints of the previous request as input to limit the target scope and verification path of the next request, ensuring that the request scope is always constrained by the difference summary and compliance disclosure boundaries. The constraint-based generative evidence routing terminates sequence generation and outputs the minimum necessary proof sequence currently generated when the identifier returned by any request indicates that a deterministic attribution has been formed and no additional evidence is required, with causal closure as the stopping condition. If no deterministic attribution is formed, the next request item is extended only within the scope allowed by the compliance disclosure boundary until a deterministic attribution is generated or the candidate set is exhausted. The resulting minimum necessary proof sequence is used as input for subsequent S150 for execution and mutual verification.

[0056] S150. Perform path verification based on the minimum necessary proof sequence, the state snapshot root, and the set commitment root, and verify the consistency of the backward link and cross anchoring, outputting the attribution conclusion and evidence index.

[0057] Path verification refers to the integrity and consistency check of the verification path returned by the evidence. It requires that the hierarchical relationship of the verification path from the start of the verified item to the root of the state snapshot or the root of the set commitment can be reconstructed, and that it is consistent with the root value bound to the window identifier and the session token. Path verification here can be a step-by-step mutual verification process. Step-by-step mutual verification refers to a synchronous verification process that initiates evidence requests item by item according to the minimum necessary proof sequence and performs local verification and adversary verification after each item is completed. It includes three parts: request execution, return verification, and comparison with the adversary's results.

[0058] Attribution conclusions refer to the results of determining the causes of differences when causal closure is achieved. These are limited to differences in rule definitions or actual asset mismatches, and identify the affected asset dimensions and the direction of the difference.

[0059] The evidence index is a set of verifiable references generated and solidified in real time during the execution of the minimum necessary proof sequence. Specifically, it can be: using the minimum necessary proof sequence obtained in S140 as input, requesting rule interpretation proofs, summary-level proofs, or single-event proofs item by item in sequence; for each returned item, first performing path verification on the state snapshot root or set commitment root in S120, and then performing consistency verification on the backward links and cross-anchoring in S110; after successful verification, generating the corresponding index item, which at least includes the window identifier, session token, request type identifier, asset dimension, difference direction, and hierarchical position identifier of the verification path. The evidence index includes root value and summary value references, entry identifiers corresponding to rule commitment summaries or event entries, time identifiers and signature identifiers, references to backward links and cross-anchoring, as well as verification result markers and causal closure status markers. The above index items are numbered and concatenated into an evidence index according to the order of the minimum necessary proof sequence. The evidence index only includes summary values ​​and location references and does not include account details to meet the constraints of not disclosing account details and compliance disclosure boundaries. When there are multiple pieces of evidence, the evidence index establishes a concatenation relationship with the reference fields of the previous index item through sequential numbering, so that any index item can be independently reviewed without relying on external details.

[0060] The output of attribution conclusions and evidence indexes is a process of determining causal closure after each step of the step-by-step mutual verification and solidifying the results when causal closure is achieved. Specifically, it can be as follows: using the index items generated in the current step and the previous index items as input, it is determined whether a deterministic attribution has been formed based on the adjudication target; if not, the next item of the minimum necessary proof sequence is executed and an index item is added after verification; if a attribution has been formed, an attribution conclusion is constructed, which indicates whether the difference type is a difference in rule caliber or a true mismatch of assets, and binds the asset dimension, difference direction and the corresponding set of index item numbers; at the same time, all accumulated index items are summarized into an evidence index in numerical order, and the attribution conclusion and evidence index are output together as input for subsequent S160, so that the disposal execution and snapshot solidification can be directly referenced and reviewed.

[0061] S160. Perform consistency verification on the attribution conclusion and the evidence index, and take a snapshot of the verification result to obtain the current snapshot block.

[0062] The snapshot solidification process comprises a set of steps based on attribution conclusions and evidence indexes to handle discrepancies and generate corresponding record snapshots. This includes accounting treatment of discrepancies in rule definitions, risk management of asset mismatches, and the generation and signing of snapshot blocks. The evidence index summary is a verifiable reference to the evidence index, providing an itemized summary and including the index item number range, summary value, and binding to the session token. Forward commitment is a commitment field for the next accounting window, including a description of the subsequent impact of executed actions, a reference to expected state changes, and binding to the window identifier. Cross-anchoring is a field where both parties embed anchor references to each other's snapshot blocks within their own snapshot blocks and jointly sign them, establishing a mutual binding relationship between their snapshots.

[0063] A snapshot block is a record object that solidifies the processing results and reference relationships of this step. It includes evidence index summary, forward commitment and cross anchoring, as well as references to window identifiers and session tokens.

[0064] The process of handling and snapshot solidification, under the constraints of the attribution conclusion and evidence index in S150, to complete the discrepancy handling and solidify the record, can be as follows: First, the consistency of the attribution conclusion and evidence index is checked. The check includes the sequential numbering of the index items, the consistency of the verification path with the state snapshot root and the set commitment root, and the binding verification with the backward link. After the check passes, if the attribution conclusion indicates that it belongs to the rule caliber difference, an adjustment entry is generated. The adjustment entry is an accounting adjustment record generated for the rule caliber difference, including the asset dimension, the direction of the difference, the adjustment amount, the rule commitment summary reference, the window identifier and session token, and the corresponding evidence index reference. Freezing, supplementing, or escalating are risk control actions triggered by a true asset mismatch. Freezing is used to restrict the inflow and outflow of the corresponding asset dimension, supplementing is used to arrange supplementary funds or assets in the direction of the difference, and escalating is used to report the handling event to the preset risk governance channel.

[0065] The adjustment entry is located based on the asset dimension and difference direction in the evidence index, and the adjustment amount is calculated based on the rule commitment summary. It is written into the window identifier and session token, referencing the corresponding set of index item numbers. After both parties complete double signature on the adjustment entry, it is recorded as a disposal record. If the attribution conclusion indicates a genuine asset mismatch, the affected asset dimension and difference direction are located based on the evidence index, triggering at least one of the following: freeze, replenishment, or escalation. Freezing involves setting a restriction identifier for the asset dimension and binding it to the session token; replenishment involves generating a replenishment instruction and binding it to the window identifier; and escalation involves registering the disposal event in a preset risk governance channel and establishing a reference to the set of numbers in the evidence index. After any of the above disposals is completed, a snapshot solidification process is initiated. Snapshot solidification is a technical approach that verifies and records the disposal results and reference relationships.

[0066] The process of generating a snapshot block containing an evidence index summary, forward commitment, and cross-anchoring to structurally solidify the execution results can be as follows: Using window identifiers and session tokens as the identifiers for the snapshot block, first, an itemized summary of the evidence index is generated. The evidence index summary is calculated, and the range of index item numbers and the summary value are recorded. The evidence index summary is then bound to the session token for subsequent review. Subsequently, a forward commitment is written. The forward commitment includes a description of the subsequent impact of adjusting entries or freezing, supplementing, or upgrading, a reference to the expected status change in the next accounting window, and a reference to the window... The binding of the identifier guides the generation parameters of the state snapshot root and set commitment root of the next window. Then, cross-anchoring is established. Cross-anchoring is an anchor field that embeds an identifier reference to the counterparty's snapshot block in the snapshot block and signs it together. The anchor field records the identifier data and signing result of the counterparty's snapshot block and binds it with the window identifier and session token of this snapshot block to form a traceable mutual binding relationship. Finally, the snapshot block is double-signed and saved as a solid record of the current window. The snapshot block is used as the input for subsequent S170 for the continuation of subsequent reconciliation sessions and external review.

[0067] S170. Perform forward commitment and chain continuity double verification on the current snapshot block. In response to the double verification passing, use the current snapshot block as the previous snapshot block of the next window.

[0068] The snapshot block generated based on S160 reveals the forward commitment to verify the chain continuity, outputs a new backward link and an updated session token, and uses the backward link as the input of the next window to form a linear closed loop. That is, the next window of the current window will repeat the operations of S110-S170 in this embodiment. The previous snapshot block in the next window is the current snapshot block of the current window, thus forming a continuous two-party escrow financial reconciliation process.

[0069] For the verification of forward commitments, the custodian and the business party jointly read the forward commitment field in the snapshot block, verify the binding relationship between this field and the window identifier and session token, and check whether its reference to the disposal record set is complete and consistent with the evidence index digest. The forward commitment only reveals the expected impact in the next accounting window at the asset level and does not include account details or event details; under the dual signature constraint of the snapshot block, both parties jointly confirm that the commitment serves as the strategy input basis when generating the state snapshot root and set commitment root for the next window.

[0070] Then, a chain continuity check is performed, verifying the binding relationship between the current window snapshot and the counterparty's snapshot based on the backward links and cross-anchors in the snapshot block. It also confirms that the consistency references between the evidence index digest and the disposal record set have been solidified under the signatures of both parties. The conditions for passing the chain continuity check are: the forward commitment is consistent with the disposal record set, consistent with the evidence index digest, consistent with the window identifier and session token binding, and the counterparty snapshot block pointed to by the cross-anchor can be verified under its double signature. After passing the check, the session closure output stage begins.

[0071] In the technical solution of this application embodiment, by using a two-way verifiable snapshot chain based on windowed reconciliation and bidirectional anchoring of snapshots in the scenario of escrow financial reconciliation, financial reconciliation between the escrow party and the business party can be carried out. This enables the verification of the consistency of accounts or data within the compliant disclosure boundaries of both parties, which not only improves the security of reconciliation between the two parties, but also improves the efficiency of two-way reconciliation.

[0072] In one optional implementation, the step of obtaining the compliance disclosure boundary pre-defined by the custodian and the business party in S110, and jointly cross-signing and referencing the previous snapshot block of the previous window to generate a window identifier and a backward link, and combining the window identifier, the backward link and the compliance disclosure boundary to generate a session token, can be further explained in the following implementation.

[0073] This implementation method addresses the initialization and constraint settings of reconciliation sessions, enabling the custodian and business parties to perform discrepancy analysis and attribution under the minimum necessary disclosure within the same accounting window. S110 eliminates disputes arising from inconsistent definitions or contextual discrepancies in subsequent steps, such as the generation of state snapshot roots and set commitment roots, the setting of discrepancy summaries and adjudication targets, the output of the minimum necessary proof sequence, and the execution and mutual verification processes. It ensures, through a constraint-driven approach from the session entry point, that subsequent steps can achieve causal closure and verifiable review without disclosing account details.

[0074] In this embodiment, the context of the reconciliation session is fixed by the following ordered tuple: .in, This is the window identifier, used to uniquely identify this accounting window; This is a session token used to bind the participants in this session to the window identifier; To define compliance disclosure boundaries, this limits the types of proof and the depth of disclosure that can be requested in this session; This is an evidence action library used to generate request templates that meet constraints under various proof types; This is a backward link used to establish a verifiable, continuous reference to the previous accounting window; For cross-anchoring, used to establish a co-signed anchor reference with an adversary session or snapshot block.

[0075] Window icon It consists of a minimal set of information including the accounting domain, time interval, and participating entities, providing a unique reference to the current window without disclosing account details. A simplified construct is used. It means that, among them For hash functions, For accounting domain identification, For time window identification, For the collection of identifiers of participating entities, Indicates a concatenation operation. Window identifier. It will be used as the binding field when generating the state snapshot root and the set commitment root in S120, and as the session's unique reference in each step from S130 to S160.

[0076] Session token By the participating entities Issued and bound under constraints, tokens are used to provide identity and session consistency verification in subsequent requests and authentications. The minimum verification for token binding can be represented as... ,in To bind the validation function, For the set of participating entities, output value This indicates that the binding verification has passed. In S120 with window identifier Together, they serve as the binding basis for generating the commitment package, and are used in S130 to S160 to limit the scope of requests and verification paths to ensure that disclosure does not exceed the boundaries.

[0077] Compliance Disclosure Boundaries The set of disclosure strategies for this session directly limits the types of proofs available and their disclosure depth to meet the minimum necessary disclosure constraint and serve the stopping condition for causal closure. Represented by the set of allowed proof types as ,in This indicates the interpretation and proof of the rules. This indicates a summary-level proof. This indicates proof of a single event. In S130, it is used to set the policy boundary of the adjudication target; in S140, it is used to filter candidate actions and limit the output range of the constraint generative evidence routing; and in S150 and S160, it is used to verify whether the execution and solidification comply with the disclosure boundary.

[0078] Evidence Action Library The mapping from proof type to request template is given for use in and Generate executable and verifiable evidence requests under binding constraints. Formalization can be understood as: ,in For a set of request templates, This is a request template for rule interpretation and proof. This is a request template for summary-level proofs. This is a request template for single-event proof. Each template includes... and The binding fields are defined, and structured requirements are set for the returned verification paths so that path verification and consistency checks in S150 can be directly reconstructed to the state snapshot root or set commitment root.

[0079] Backlinks To ensure continuity and traceability between the current session and the previous accounting window, no account details are disclosed. It means that, among them This is the window identifier for the previous accounting window. This is the token from the previous session. In S150, it serves as input for consistency verification, used to check whether the verification result of this session remains consistent with the fixed records in the historical window.

[0080] Cross anchoring Used to establish a mutual signing anchor relationship with the counterparty, ensuring that snapshots or sessions of both parties have mutual binding characteristics during subsequent mutual verification and solidification. Employs It means that, among them This can be used as the counterparty's snapshot block identifier or session identifier. It will be directly referenced in the consistency verification of S150 and the snapshot fixation of S160 to prove that the handling of this session and the handling of the counterparty are jointly signed and anchored under the constraints of the same window identifier and session token.

[0081] When S110 enters the session, it uses... Based on this foundation, a unique window identifier and binding token are established, compliance disclosure boundaries are defined, and an evidence action library is prepared. Simultaneously, backward links are established with historical windows, and cross-anchoring is established with adversaries. Context will be used by S120 to generate commitment packages, by S130 for setting difference summaries and adjudication objectives, by S140 to constrain the minimum necessary proof sequence for generating evidence routing outputs, and by S150 and S160 for progressive mutual verification and snapshot solidification, ensuring that the entire process achieves deterministic attribution and verifiable review without disclosing account details.

[0082] In an optional implementation, step S120, which generates a state snapshot root, a set commitment root, and a rule commitment summary for the current window corresponding to the custodian's account and asset balance based on the session token, and assembles the state snapshot root, the set commitment root, and the rule commitment summary into a commitment package, may include:

[0083] Based on the session token, the custodian's account and asset balance matrix is ​​hierarchically arranged according to asset and account dimensions to generate the state snapshot root; based on the session token, the set commitment root is generated for the set of accounting events confirmed by the current window; based on the window identifier in the session token, the preset rule items corresponding to the current window are processed into itemized commitments to obtain the rule commitment summary; the state snapshot root, the set commitment root, and the rule commitment summary are combined to generate the commitment package.

[0084] It should be noted that the embodiments of this application further elaborate on the aforementioned S120. Specifically, S120 uses the session context established in S110. To address the fundamental constraints and provide verifiable evidence for subsequent discrepancy analysis and attribution without disclosing account details, a commitment package is generated and exchanged and dual-signed. Specifically, the commitment package includes three core commitment objects: a state snapshot root, a set commitment root, and a rule commitment summary, along with a window identifier. and session token Binding is used to extract difference summaries in S130 only by asset dimension and difference direction, and to complete the mutual verification of summary-level proof and single event proof along the verification path in S140 to S150.

[0085] First, generate the root state snapshot. Under the disclosure constraints, the final balance of the current window is hierarchically arranged according to asset and account dimensions to form a structured summary for aggregation and verification. To avoid disclosing account details, this step only uses the asset dimension as the leaf-level input, converting the final balance of each asset dimension into a leaf summary, and merging them level by level according to the deterministic order determined by the asset classification mapping in the rule commitment summary to obtain the state snapshot root. Throughout the generation process, the window identifier is always bound. With session token It also records the verification path that can be reconstructed by S150, so that subsequent summary consistency verification can be completed without disclosing account details.

[0086] This is followed by the generation of the set of commitment roots. The set of commitment roots takes the set of accounting events confirmed in the current window as input, and is then processed by... The guiding sequence generates an entry summary for each event and merges them level by level to obtain the set commitment root. The structure is used in S130 to support the need to locate irrelevant events without disclosing them, and in S150 to support the verification of the existence and scope of influence of specified events. The generation of the set commitment root is simultaneously bound to... and And record index information to ensure that subsequent difference location and path verification can be completed with minimal necessary disclosure.

[0087] Generate a rule commitment summary. The rule commitment summary provides itemized commitments to the rule items applicable to the current window. Rule items include the pricing model, discount rate, pricing date, and asset classification mapping. To ensure consistency, the rule commitment summary and... The binding and interpretation are used to set the adjudication objectives in S130 and to provide evidence for the priority request rule interpretation in S140, avoiding additional disclosures or duplicate verifications due to inconsistent rule interpretations.

[0088] After the three commitment objects mentioned above are generated, a commitment package is constructed and a commitment package digest value is calculated for signing and subsequent reference. The commitment package is... and The binding fields include a state snapshot root (for summary-level validation), a collection commitment root (for event-level validation), and a rule commitment digest (for rule interpretation). To form a unique identifier for the commitment content and serve exchange and double signature, this implementation calculates the following core digest value on the commitment package:

[0089] ;

[0090] in, This is the value of the commitment package digest; For hash functions; For window identification; For session tokens; This is the root of the state snapshot; For the set commitment root; A summary of the rule commitment; This is a concatenation operation. The digest value... Provide verifiable identifiers for the commitment package without disclosing account details, ensuring consistent referencing and path verification of the commitment package in each step from S130 to S150. and Completed within the bound context.

[0091] Finally, the exchange is executed and both parties sign off. The custodian and the service provider agree on the package details. , , , , and The exchange and signing are completed, forming a consistent confirmation of the commitments. The signing results are recorded as follows: and ,in The custodian signs off on the results. The results are signed by the business party; both are in accordance with For signing input and citation and The binding fields ensure consistency between identity and session in subsequent requests and verifications. At this point, the commitment package consists of a set of fields. The structure is used as input to S130 for the extraction of the difference summary and the setting of the adjudication target; at the same time, the state snapshot root and set commitment root of the commitment package and their verification path are directly referenced in the stepwise mutual verification of S150, which helps to ensure causal closure and verifiable review with minimal necessary disclosure.

[0092] In one alternative implementation, the step of generating the difference summary and adjudication target for the current window based on the commitment package in S130 may include:

[0093] Based on the asset classification mapping in the rule commitment summary, the corresponding asset dimension is located on the state snapshot root. By comparing the summary identifier of the same asset dimension in the commitment packages of the custodian and the business party with the difference prompts of the set commitment root, the difference summary is generated. Based on the compliance disclosure boundary and the rule commitment summary, the adjudication target of the reconciliation session in the current window is determined.

[0094] It should be noted that the embodiments in this application are an expanded description of S130 in the foregoing embodiments. Specifically, the session context established in S110... As a constraint, the commitment package generated and exchanged by S120 is used as input, where the commitment package contains binding fields for the state snapshot root, the set commitment root, and the rule commitment summary.

[0095] In this step, the state snapshot root and the set commitment root of both parties are denoted as follows: and as well as and The rule commitment summary is denoted as The window identifier is recorded as The session token is recorded as The compliance disclosure boundary is denoted as The evidence action database is recorded as Based on this, S130 constructs a difference summary according to the asset dimension and the direction of the difference, with the goal of minimum necessary disclosure and definitive attribution, and solidifies the adjudication objective into a strategy record that can be directly analyzed by S140.

[0096] First, from The asset classification mapping in the middle extracts the set of asset dimensions for the current window, denoted as . Each of them This serves as an identifier for an asset dimension. For each asset dimension... ,pass and The verification path is reconstructed to obtain the summary value without disclosing account details, and the summary values ​​are obtained separately. and (Both are summations of the final value of the balance at the asset level). To avoid disclosing specific amounts, this step only calculates the difference existence indicator and the difference direction: Difference Existence Indicator 1 1 of them Indicator function; difference direction ,in For symbolic functions, return , or These represent negative, indifferent, or positive directions, respectively.

[0097] Subsequently based on right The applicable rule entries are used to extract the scope references affected by the rule commitment summary, denoted as... ( This is a reference to the identifier of an applicable rule entry (excluding the full text of the rule). For asset dimensions that may require event-level validation. Without disclosing irrelevant events, record the path location reference of the set commitment root, denoted as . and (Both are in) and The location identifier is used for subsequent verification path limitations in S140 and S150. Based on this, the difference summary is based on... The set of entries consists of only the asset dimension. Difference direction Scope of reference affected by rule commitment summary and necessary path location references and This does not include account details and event details. To ensure the difference summary can be rigorously parsed by S140, this implementation also sets an adjudication target, which is limited to... Proof of prior rule interpretation under constraints Subsequent summary level proof Proof of a single event when necessary The execution follows a fixed-priority link, with causal closure as the stopping condition; where... , , All from Evidence Action Library This is used to map the above proof types to executable request templates, with the stopping condition denoted as... ( (This is a causal closure condition; it is true when a deterministic attribution is formed.)

[0098] To generate a unique and verifiable input digest for the difference summary and the adjudication target, this implementation calculates the difference summary value without disclosing account details and binds it to the adjudication target as an input identifier for use in S140, specifically:

[0099]

[0100] ;

[0101] in, Input summary values ​​for the difference summary and the adjudication target; For hash functions; For window identification; For session tokens; A summary of the rule commitment; Identify assets; The difference is identified; For the direction of the difference; References are made for scopes affected by the rule commitment summary; and They are respectively in and Path location reference; This is a serial connection operation; To ensure compliance with disclosure boundaries; A fixed priority chain from coarse to fine; This is the causal closure termination condition. (The above...) It only includes necessary dimension identifiers, direction identifiers, and references, excluding account details and event details; its binding and Ensure that in the constrained generative evidence routing of S140, all evidence requests are strictly limited to the asset dimensions and path locations referenced in the difference summary, and are subject to... Disclosure depth constraints and This serves as a stopping condition. Ultimately, the difference summary and the ruling objective are... The input identifier is provided to S140 to generate the minimum necessary proof sequence and drive subsequent execution and step-by-step verification.

[0102] In one alternative implementation, generating the minimum necessary proof sequence based on the difference summary, the adjudication objective, the compliance disclosure boundary, and the evidence action library in step S140 may include:

[0103] Based on the aforementioned difference summary, the aforementioned adjudication objective, the aforementioned compliance disclosure boundaries, and the aforementioned evidence action library, an ordered list of evidence requests is output as the minimum necessary proof sequence; wherein, the ordered list of evidence requests includes evidence request items required to achieve deterministic attribution.

[0104] It should be noted that the embodiments described in this application are extensions of S140 in the foregoing embodiments. Specifically, the session context established in S110... Based on the constraints, the commitment packet fields of the dual signature are generated and exchanged in conjunction with S120. And the difference summary obtained from S130 and the input summary value of the adjudication target. (This includes asset dimension sets and path location references), constraining generative evidence routing at the compliance disclosure boundary. With evidence action library Under the common constraints, the minimum necessary proof sequence is output according to a fixed priority chain from coarse to fine (first rule interpretation proof, then summary-level proof, and single-event proof if necessary). The sequence is bound to the window identifier at the generation level. With session token Furthermore, the sequence elements only carry the necessary dimension identifiers, rule references, and verification path references to ensure that the subsequent S150 can achieve causal closure without disclosing account details.

[0105] Before the route is expanded, S140 from Parse the set of asset dimension indexes to be processed ,in For asset dimension identification, The difference is marked. For the direction of the difference, For references to the scope of the rule commitment summary, and In order to be in and Path location reference. Evidence Action Library Mapping proof types to request templates, specifically including (Request template for rule interpretation and proof) (Request template for summary-level proof) and (Request template for proof of a single event), compliance disclosure boundaries Limit the set of available proof types and the depth of disclosure; stop conditions This serves as the causal closure criterion. To ensure a coarse-to-fine global priority, S140 first performs rule interpretation proofs for all asset dimensions, then performs summary-level proofs for asset dimensions that have not yet achieved causal closure, and finally performs single-event proofs for asset dimensions that still have not achieved causal closure.

[0106] The core of this step lies in strictly adhering to the principle of not disclosing account details. Under the premise of [condition], an ordered list of requests with guardian conditions is constructed as the minimum necessary proof sequence. Therefore, the minimum necessary proof sequence is defined as [formula]. The output of the constraint-generated evidence routing is calculated as follows:

[0107]

[0108] in, This is the minimum necessary proof sequence; Operators that concatenate sequences in the order they are written; The set of asset dimension indexes where the difference exists; For type permission indication, when proving type exist When permitted to take Otherwise take ; The request template generation function for rule interpretation proof has the following parameters in order: window identifier. Session token Asset Dimension Scope reference Summary of Rule Commitments ; The request template generation function for summary-level proofs has the following parameters in order: , , State snapshot root and ; The request template generation function for single event proof has the following parameters in order: , , Path location reference , With set commitment root , ; 1 For indicator functions; From the asset dimension Placeholder for causal closure determination during the rule interpretation and proof phase; From the asset dimension Placeholder for causal closure determination in the summary-level proof phase. (The above) and As a guardian condition, it is output along with the sequence elements. When the sequence is executed and mutual verification is performed step by step in S150, it is realized by the returned interpretation overwrite flag, summary consistency flag or event impact consistency flag, triggering a strategy with causal closure as the stopping condition.

[0109] Based on the above calculation formula, the specific generation process of S140 is as follows: First, analyze... get , , , , , and based on Filter the available proof types; then use... right All The generation rules explain and prove the request elements, and each element is bound to... and And cite and Based on this, only those cases in S150 where causal closure has not been achieved through rule interpretation (corresponding to...) )of ,use Generate summary-level proof request elements, each element being bound to... and And limit the verification path to and The asset dimension position; if causal closure has not yet been achieved (corresponding to ), then use References are only made to path locations directly related to the differences. and Generate a single event proof request element and limit the verification path to... and This avoids additional disclosures beyond the asset dimensions and scope listed in the difference summary. The entire sequence is organized strictly according to a global priority chain: rule interpretation proof, then summary-level proof, and, if necessary, single-event proof, and so on. The termination of the guardian condition is triggered step by step in S150 to stop the condition.

[0110] Furthermore, to maintain overall clarity and ease of understanding, each rule explanation and proof element must contain at least [number of elements]. Each summary-level proof element contains at least [number] elements. Each single event proof element must contain at least [number] elements. The aforementioned fields ensure that S150, during the execution sequence and progressive mutual verification, can directly perform path verification on the state snapshot root and the set commitment root, combined with compliance disclosure boundaries. With causal closure termination condition A step-by-step determination is made to achieve a definitive attribution without disclosing account details. Ultimately, As input to S150, it is submitted for execution, driving the stepwise mutual verification process to generate attribution conclusions and evidence indexes.

[0111] In an optional implementation, the path verification performed in S150 based on the minimum necessary proof sequence, the state snapshot root, and the set commitment root, and the consistency of the backward links and cross-anchorings, outputting attribution conclusions and evidence indexes, may include:

[0112] The path verification is performed on the state snapshot root and the set commitment root according to the minimum necessary proof sequence, and the consistency of the backward link and cross anchoring is verified; in response to the path verification and the consistency verification being passed, index entries are generated, and all index entries are combined into the evidence index; the deterministic attribution of each index entry is determined according to the adjudication objective, and the attribution conclusion is generated.

[0113] This application's implementation is an extended description of S150 in the foregoing embodiments. Specifically, the session context established in S110... Based on the constraints, the commitment packet fields of the dual signature are generated and exchanged in conjunction with S120. And the minimum necessary proof sequence output by S140. The process involves phased mutual verification without disclosing account details. The core of phased mutual verification is: sequentially reading... The request elements in the code perform path validation on both the state snapshot root and the set commitment root, and verify the results and backlinks at each step. and cross anchoring Perform consistency checks; update the protection conditions for each asset dimension; if causal closure is achieved, stop immediately and output the attribution conclusion and evidence index, which are used as inputs to S160.

[0114] At the execution level, each sequence element is bound to a window identifier. With session token And limit the verification path to or This ensures that path verification and consistency checks do not exceed the compliance disclosure boundaries. This step constructs index entries for fixed fields after each request is completed. These index entries are then fixed as verifiable references using hash digests, concatenated to form an evidence index, and satisfy the causal closure stopping condition with the minimum prefix length. Key points are given in the following formula:

[0115]

[0116]

[0117] in, For evidence index; For hash functions; Indicates a serial connection operation; To concatenate operators in sequence; This refers to the sequence step number; This is the proof type identifier for the current request element, taken from... (Rule interpretation and proof) (Summary-level proof) or (Proof of a single event); For from the first A function that maps each requested element to an asset dimension index returns... ; This is the asset dimension identifier corresponding to the request; This indicates the direction of the difference in this asset dimension; For path validation digest, derived from in or The verification path reconstruction and consistency verification results are as follows; For the root reference field collection, if Then includes ,like Then includes ,like Then set it to empty; For rule commitment summary citation, if Then includes Otherwise, set to empty; For backlinks; For cross anchoring; The set of verification results for this step must include at least the explanation coverage identifier. Summary Consistency Identifier Consistency Identifier for Event Impact One of the three or a combination thereof; and These are the signature marks of the custodian and the business party, respectively; , , From the asset dimension The cumulative flags within the already executed prefix, This indicates that the difference has been covered by the rule interpretation. This indicates that the summary-level verification is consistent. This indicates that the event's impact is consistent with the verification. Indicates logical negation; For logical AND; The minimum prefix length that satisfies the stopping condition is determined by all... If any explanation is valid, or the summary is invalid, or the event impact is invalid, then a causal closure is formed.

[0118] Based on the above formula, the execution of step-by-step mutual verification is refined as follows: when At that time, according to and Provide an interpretation of the rules and generate interpretation coverage identifiers. Incorporate it With cumulative markers ;when At that time, along The path verification was completed at the asset dimension location, and the output was summarized as a consistency identifier. Incorporate it With cumulative markers ;when At that time, only The specified event location completes path verification and generates an event impact consistency identifier. Incorporate it With cumulative markers Each step is in and Under binding verification and , Consistency, and with Solidify index entries to form The prefix. Reaching At that time, construct attribution conclusions For each ,like Then it is classified as a difference in rule caliber; otherwise, when or This is classified as a true asset mismatch; and will It is bound to its corresponding set of index item numbers. Final output and As input to S160, this drives the execution of actions and the solidification of snapshots. Through the above-mentioned stepwise mutual verification and index solidification, this step achieves path verification of the root of state snapshots and the root of set commitments without disclosing account details. It also ensures that after achieving causal closure, verifiable and referable attribution conclusions and evidence indexes are formed, based on consistency with backward links and cross-anchoring.

[0119] In one optional implementation, the consistency check of the attribution conclusion and the evidence index in step S160, and the snapshot fixation based on the check result to obtain the current snapshot block, may include:

[0120] A consistency check is performed based on the attribution conclusion and the evidence index; in response to the consistency check result being passed, the classification result of the attribution conclusion is determined; the classification result includes rule caliber differences and asset mismatch; the classification result is then snapshotted to obtain the current snapshot block.

[0121] This application's implementation is an extended description of S160 in the foregoing embodiments. Specifically, the session context established in S110... As a constraint basis, it undertakes the generation and exchange of dual-signature commitment packet fields and digests based on S120. Summary of differences and adjudication objectives following S130 The minimum necessary proof sequence following the output of S140 And the attribution conclusions and evidence index output by S150, i.e. and Without disclosing account details, S160 is based on This implementation distinguishes between two handling paths: differences in rule definitions and genuine asset mismatches. The former generates adjustment entries with dual signatures, while the latter triggers at least one risk management action: freezing, supplementation, or escalation. The handling results and their reference relationships are then solidified into a snapshot block, complete with an evidence index summary, forward commitment, and cross-anchoring, ensuring externally verifiable records that can be inherited by subsequent windows. This implementation reuses the asset dimension set in S130. The difference exists in the index set. Difference direction With the cumulative marker in S150 and in S120 The verification path reconstructs the aggregated value locally (without disclosing account details) to calculate the amount and threshold required for disposal.

[0122] First, based on right Each asset dimension Determine the type of disposal: When When, it is considered a difference in rule caliber; when or At that time, it was determined to be a true mismatch of assets. To generate the adjustment amount required for the adjusting entries, the asset dimensions of both parties were adjusted. The final value of the aggregated balance is reconstructed locally using the S120 binding field and the S150 validation path, denoted as follows: and (Both are summaries based on asset dimensions, excluding account details), calculate the difference range. and the direction of the difference ;when Adjustment entries are generated and recorded in real time. It also references the relevant index item number set from the evidence index. To address the true mismatch in asset disposal, risk disposal parameters are set: freeze flag. Supplement the amount With upgrade mark Its determination is driven by both the cumulative flag and the amplitude threshold, that is, when When it was established And based on the preset threshold and Calculate separately and This allows for the combination of magnitude and consistency results into an actionable risk management triple without disclosing account details. To ensure external verification of the snapshot without revealing details, this implementation constructs a summary for the evidence index: [Record / Description] The minimum prefix length for S150 to achieve causal closure. For the first The hash value of each index entry ( ), and The mapping from index items to asset dimension indexes (as defined in S150) is defined accordingly. As The corresponding set of index item numbers. Then, the evidence index summary is calculated. (in For hash functions, (For cascading operation). Forward commitment This is used to describe the scope of the impact of an executed action on the next accounting window; in this implementation, it is expressed in a compressed form as follows: It records verifiable summaries of disposal type and upgrade level at the asset dimension.

[0123] To solidify all processing and referencing relationships in this step under a single identifier, this implementation uses the snapshot block digest as the core verifiable object and performs double signing on the digest:

[0124]

[0125]

[0126] in, A snapshot block summary; For window identification; For session tokens; For backlinks; For cross anchoring ( ,in (The counterparty's snapshot block identifier or session identifier, as defined in S110). For evidence index summary; For hash functions; This is a serial connection operation; The set of asset dimension indexes where the difference exists; For the asset dimension The handling records are divided into two categories: when When there are differences in the rules and regulations, record the adjusting entry elements, including the asset dimension. Difference direction Adjustment amount Summary of Rule Commitments References and set of index item numbers ;when When there is a genuine mismatch of assets, record the risk management elements, including the freezing marker. Supplement the amount Upgrade mark as well as In the formula For the difference range ( and Based on and The verification path in the asset dimension The final value of the reconstructed aggregate balance is not disclosed (account details are not disclosed). To make up the difference; Mark as frozen; For upgrade markers; and For a preset amplitude threshold and satisfying The above construction guarantees Without disclosing account details, a complete four-element relationship is established, consisting of evidence index summary, disposal record, forward commitment, and link anchor.

[0127] In terms of handling and execution, targeting Asset Dimension ,in accordance with Generate adjusting entries and match them with , Binding involves both parties completing dual signatures at the journal entry level or snapshot level; for Asset Dimension Execute freeze (set) respectively Restriction markings and Binding), replenishment (the amount issued is) The completion command and Binding) and Upgrade (when) Events are registered and handled through a pre-defined risk governance channel and cited. At least one of the following. Finally, the disposal results and reference relationships are organized into snapshot block objects, to... A uniquely verifiable digest, generated separately by the hosting provider and the business provider. and (Both are based on) For signing input and explicit citation and (binding), forming a snapshot block The snapshot block is then used as input to S170 to support the subsequent window's reception and external review.

[0128] In one optional implementation, the double verification of forward commitment and chain continuity for the current snapshot block in S170, and the setting of the current snapshot block as the previous snapshot block for the next window in response to the successful double verification, may include:

[0129] The hosting provider and the business provider jointly read the forward commitment field in the current snapshot block and perform forward commitment verification with the window identifier and the session token; in response to the forward commitment verification being successful, they verify whether the chained and continuous binding relationship of snapshots between the hosting provider and the business provider is established based on the backward links and cross anchors in the current snapshot block; in response to the binding relationship being established, the current snapshot block is used as the previous snapshot block of the next window.

[0130] This application's implementation method is an extension of S170 in the aforementioned embodiments. The snapshot block generated in S160 is the sole input. The snapshot block consists of a window identifier W, a session token T, an evidence index digest, a set of disposal records, forward commitments, backward links L, cross-anchoring C, a snapshot block digest, and double signatures. The goal of S170 is to reveal the forward commitments in the snapshot block without disclosing account details, to verify the scope and chain continuity of the impact on the next accounting window. After successful verification, a new backward link and an updated session token are output, where the new backward link serves as the input to the next window S110, enabling the reconciliation session to form a linear closed loop in the window dimension.

[0131] First, forward commitment disclosure is performed. The custodian and the business party jointly read the forward commitment field in the snapshot block, verifying the binding relationship between this field and the window identifier W and session token T, as well as whether its reference to the set of disposal records is complete and consistent with the evidence index digest. The forward commitment only discloses the expected impact in the next accounting window at the asset level, and does not include account details or event details; under the dual signature constraint of the snapshot block, both parties jointly confirm that the commitment serves as the strategy input basis when generating the state snapshot root and set commitment root for the next window.

[0132] Next, a chain continuity check is performed. Around the backward link L and cross-anchor C in the snapshot block, the binding relationship between the current window snapshot and the counterparty's snapshot is verified to ensure it is valid, and the consistency reference between the evidence index digest and the disposal record set is confirmed to be solidified under the signatures of both parties. The conditions for passing the chain continuity check are: the forward commitment is consistent with the disposal record set, consistent with the evidence index digest, consistent with the binding of the window identifier W and the session token T, and the counterparty snapshot block pointed to by the cross-anchor C can be verified under its double signature. After the check passes, the session closure output stage begins.

[0133] Finally, the session is closed and the context field used to take over the next window is output. The new backward link is generated by binding the current window identifier with the session token, and is used as a history reference input in the next window to ensure linear continuity between windows; the updated session token is issued by both parties under the double signature constraint of the current snapshot block and bound to the new window identifier, and is used to limit the identity consistency and session consistency of requests and verifications in the next window.

[0134] Example 2

[0135] Figure 2 This is a schematic diagram of window reconciliation between the custodian and the service provider as provided in Embodiment 2 of this application. This embodiment is a supplementary explanation of window reconciliation between the two parties based on the foregoing embodiments and implementation methods. Figure 2 As shown, the details are as follows:

[0136] Figure 2 As shown, the windowed snapshot chain of the custodian (dark blue track) and the business party (dark red track) is displayed on two timelines. The snapshot blocks of each window maintain temporal continuity through backward links. The vertical "lock"-shaped connection represents cross-anchoring and double signature, ensuring that the records of both parties are mutually bound and traceable. Window 2 is marked with "Differences," and the right side shows the minimum necessary proof sequence from coarse to fine (rule interpretation → summary level → single event). The checkmark at the end indicates that causal closure has been achieved. All verifications reconstruct the path on the state snapshot root / set commitment root, are constrained by session tokens and compliance disclosure boundaries, and do not disclose account details. After attribution is achieved, the process enters the disposal panel, generating adjustments, freezes, supplements, or upgrades, and solidifying them into an evidence index summary. Subsequently, the snapshot generation and parameter acceptance of window 3 are guided by forward commitments, forming a cross-window linear closed loop and facilitating external review.

[0137] The process is presented as a windowed snapshot chain between the custodian and the business party, using two timelines: the arrows and vertical lock-shaped lines between windows correspond to session establishment, backward linking, and cross-anchoring in S110; the circled differences in the diagram correspond to the difference summary in S130; the coarse-to-fine proofs on the right, ending with checkmarks, reflect the minimum necessary proof in S140 and the step-by-step mutual verification in S150 until causal closure; the freeze, supplement, upgrade, and evidence index summary in the right-hand disposition panel correspond to the disposition execution and snapshot solidification in S160; the forward commitment arrows leading from the disposition point to the next window, corresponding to the forward commitment disclosure and session closure in S170. The generation and exchange of commitment packets in S120 are not separately labeled in the diagram but are implicit in the formation of each window snapshot block, providing the root value and rule commitment basis for difference identification and subsequent verification.

[0138] Here, we summarize the two embodiments and implementation methods described above. The technical solution of this application establishes temporal continuity and mutual binding at the reconciliation window level through a bidirectional verifiable snapshot chain of "session token + backlink + snapshot anchoring". The session token explicitly binds the window identifier and the compliance disclosure boundary, cross-signs and references the previous window snapshot block, ensuring that all commitments and proofs are executed under the same identity and disclosure policy, and that any verification result must be consistent with historical links and counterparty anchoring. Thus, without exposing account details, it solves the common problems of window rollback, unilateral rewriting, and inconsistent contextual statements in existing solutions. Compared to relying solely on unilateral timestamps or loose logs, snapshot anchoring and dual-signature solidification provide a traceable and non-repudiable foundation for chain evidence.

[0139] In terms of data commitment and discrepancy localization, the state snapshot root and the set commitment root respectively generate verifiable summaries for the balance matrix and event set, which, combined with the rule commitment summary, constitute a commitment package that has been exchanged and double-signed. This design allows both summary-level and event-level path verification to trace back to the root value, while using itemized rules to ensure the prior consistency of valuation caliber, discount rate, and asset classification. Based on the commitment package, only the asset dimension, difference direction, and rule impact scope are extracted to form a discrepancy summary, avoiding the disclosure of account or irrelevant event details and reducing communication and privacy costs. Compared to traditional full-scale detail comparison or sampling review, this solution first explains the source of discrepancies with rule commitments, reducing round-trip verification and repeated caliber adjustments, and the set commitment supports difference localization to narrow the scope of subsequent verification.

[0140] In the closed loop of evidence generation and disposal, the constraint-based generative evidence routing outputs the minimum necessary proof sequence under the compliant disclosure boundary and evidence action library according to a fixed priority of "rule interpretation → summary level → single event when necessary," and uses causal closure as the stopping criterion. During execution, all returns must complete path verification at the state snapshot root or set commitment root, and simultaneously check the consistency of backward links and cross-anchoring; the verification results are sequentially solidified into evidence indexes containing only summaries and location references, supporting independent review and external auditing. After the attribution conclusion is clear, the system automatically generates adjustment entries or triggers freeze / supplement / upgrade, and records the evidence index summary and forward commitment in a snapshot block, passing the disposal impact to the next window. Compared with existing processes that lack deterministic stopping conditions and are difficult to replay evidence, this solution achieves deterministic attribution, verifiable auditing, and consistent cross-window transmission while strictly controlling the disclosure boundary, reducing unnecessary data exchange and the probability of disputes, and improving the executability of automated disposal.

[0141] Example 3

[0142] Figure 3 This is a schematic diagram of the structure of an account reconciliation device provided in Embodiment 3 of this application. Figure 3 As shown, the device 300 includes:

[0143] The session token generation module 310 is used to obtain the compliance disclosure boundary pre-defined by the custodian and the business party, and jointly cross-sign and reference the previous snapshot block of the previous window to generate a window identifier and a backward link. The window identifier, the backward link and the compliance disclosure boundary are combined to generate a session token. The compliance disclosure boundary is bound to a preset evidence action library.

[0144] The commitment package generation module 320 is used to generate, based on the session token, a state snapshot root, a set commitment root, and a rule commitment summary of the current window corresponding to the custodian's account and asset balance, and to assemble the state snapshot root, the set commitment root, and the rule commitment summary into a commitment package;

[0145] The difference summary and adjudication target generation module 330 is used to generate the difference summary and adjudication target of the current window based on the commitment package;

[0146] The minimum necessary proof sequence generation module 340 is used to generate a minimum necessary proof sequence based on the difference summary, the adjudication objective, the compliance disclosure boundary, and the evidence action library;

[0147] The attribution and index output module 350 is used to perform path verification based on the minimum necessary proof sequence, the state snapshot root, and the set commitment root, and to verify the consistency of the backward link and cross anchoring, and output the attribution conclusion and evidence index.

[0148] The current snapshot block determination module 360 ​​is used to perform consistency verification on the attribution conclusion and the evidence index, and to solidify the verification result into a snapshot to obtain the current snapshot block.

[0149] The current snapshot block verification module 370 is used to perform dual verification of forward commitment and chain continuity on the current snapshot block. In response to the passing of the dual verification, the current snapshot block is used as the previous snapshot block of the next window.

[0150] In the technical solution of this application embodiment, by using a two-way verifiable snapshot chain based on windowed reconciliation and bidirectional anchoring of snapshots in the scenario of escrow financial reconciliation, financial reconciliation between the escrow party and the business party can be carried out. This enables the verification of the consistency of accounts or data within the compliant disclosure boundaries of both parties, which not only improves the security of reconciliation between the two parties, but also improves the efficiency of two-way reconciliation.

[0151] In one alternative implementation, the commitment package generation module 320 may include:

[0152] The state snapshot root generation unit is used to hierarchically arrange the custodian's account and asset balance matrix according to the asset dimension and the account dimension based on the session token, and generate the state snapshot root.

[0153] A set commitment root generation unit is used to generate the set commitment root based on the session token for the set of accounting events confirmed by the current window;

[0154] The rule commitment summary determination unit is used to perform itemized commitment processing on the preset rule items corresponding to the current window based on the window identifier in the session token to obtain the rule commitment summary;

[0155] The commitment package synthesis unit is used to combine the state snapshot root, the set commitment root, and the rule commitment summary to generate the commitment package.

[0156] In one alternative implementation, the difference summary and adjudication target generation module 330 may include:

[0157] The difference summary determination unit is used to locate the corresponding asset dimension on the state snapshot root according to the asset classification mapping in the rule commitment summary, and generate the difference summary by comparing the summary identifier of the same asset dimension in the commitment package of the custodian and the business party with the difference prompt of the set commitment root;

[0158] The adjudication target determination unit is used to determine the adjudication target of the reconciliation session of the current window based on the compliance disclosure boundary and the rule commitment summary.

[0159] In one alternative implementation, the minimum necessary proof sequence generation module 340 may be specifically used for:

[0160] Based on the aforementioned difference summary, the aforementioned adjudication objective, the aforementioned compliance disclosure boundaries, and the aforementioned evidence action library, an ordered list of evidence requests is output as the minimum necessary proof sequence; wherein, the ordered list of evidence requests includes evidence request items required to achieve deterministic attribution.

[0161] In one alternative implementation, the attribution and indexing output module 350 may include:

[0162] A consistency verification unit is used to perform path verification on the state snapshot root and the set commitment root according to the minimum necessary proof sequence, and to verify the consistency of the backward link and cross anchoring.

[0163] An index item determination unit is configured to generate index items and combine all index items into the evidence index in response to the successful path verification and the consistency verification.

[0164] The attribution conclusion determination unit is used to determine the deterministic attribution of each of the index items based on the adjudication target and generate the attribution conclusion.

[0165] In one alternative implementation, the current snapshot block determination module 360 ​​may include:

[0166] Attribution evidence verification unit, used to perform consistency verification based on the attribution conclusion and the evidence index;

[0167] The classification conclusion determination unit is used to determine the classification result of the attribution conclusion in response to the verification result being that the consistency verification has passed; the classification result includes rule caliber differences and asset mismatch.

[0168] The current snapshot block determination unit is used to solidify the classification result into a snapshot to obtain the current snapshot block.

[0169] In one alternative implementation, the current snapshot block verification module 370 may include:

[0170] A forward commitment verification unit is used by the custodian and the business party to jointly read the forward commitment field in the current snapshot block and perform forward commitment verification with the window identifier and the session token;

[0171] The backward link verification unit is used to verify, in response to the forward commitment verification passing, whether the chain-like continuous binding relationship of snapshots between the custodian and the business party is valid based on the backward links and cross anchors in the current snapshot block.

[0172] The next cycle verification advance unit is used to, in response to the establishment of the binding relationship, use the current snapshot block as the previous snapshot block of the next window.

[0173] The reconciliation device provided in this application embodiment can execute the reconciliation method provided in any embodiment of this application, and has the corresponding functional modules and beneficial effects for executing each reconciliation method.

[0174] Example 4

[0175] Figure 4 A schematic diagram of an electronic device 10, which can be used to implement embodiments of this application, is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (such as helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the application described and / or claimed herein.

[0176] like Figure 4 As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory 12 or a random access memory 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the read-only memory 12 or loaded from storage unit 18 into the random access memory 13. The random access memory 13 may also store various programs and data required for the operation of the electronic device 10. The processor 11, read-only memory 12, and random access memory 13 are interconnected via a bus 14. An input / output interface 15 is also connected to the bus 14.

[0177] Multiple components in electronic device 10 are connected to input / output interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of monitors, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0178] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, central processing units, graphics processing units, various special-purpose artificial intelligence computing chips, various processors running machine learning model algorithms, digital signal processors, and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as reconciliation methods.

[0179] In some embodiments, the reconciliation method may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program may be loaded and / or installed on electronic device 10 via read-only memory 12 and / or communication unit 19. When the computer program is loaded into random access memory 13 and executed by processor 11, one or more steps of the reconciliation method described above may be performed. Alternatively, in other embodiments, processor 11 may be configured to execute the reconciliation method by any other suitable means (e.g., by means of firmware).

[0180] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays, application-specific integrated circuits (ASICs), application-specific standard products (ASICs), system-on-a-chip (SoCs), payload programmable logic devices (PLCs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0181] Computer programs used to implement the methods of this application may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0182] In the context of this application, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. Alternatively, a computer-readable storage medium can be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory, read-only memory, erasable programmable read-only memory, optical fibers, portable compact disk read-only memory, optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0183] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a monitor with a cathode ray tube or liquid crystal display) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0184] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or computing systems that include middleware components (e.g., application servers), or computing systems that include frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0185] A computing system can include clients and servers. Clients and servers are generally geographically separated and typically interact via communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a host product within the cloud computing service system to address the shortcomings of traditional physical hosts and virtual private servers, such as high management difficulty and weak business scalability.

[0186] This application also discloses a computer program product, which includes a computer program that, when executed by a processor, implements the reconciliation method provided in any embodiment of this application. This program product shares the same inventive concept as the reconciliation methods disclosed in the embodiments of this application, and therefore will not be described in detail here.

[0187] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this application can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this application can be achieved, and this is not limited herein.

[0188] The specific embodiments described above do not constitute a limitation on the scope of protection of this application. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A reconciliation method, characterized by, The method comprises the following steps: obtaining a compliance disclosure boundary pre-set by a hosting party and a business party, and jointly signing and referencing a last snapshot block of a last window, generating a window identifier and a backward link, and combining the window identifier, the backward link and the compliance disclosure boundary to generate a session token; wherein the compliance disclosure boundary has a binding relationship with a preset evidence action library; based on the session token, generating a state snapshot root corresponding to the account and asset balance of the hosting party, a set commitment root and a rule commitment digest of the current window, and combining the state snapshot root, the set commitment root and the rule commitment digest to generate a commitment package; according to the commitment package, generating a difference summary and a ruling target of the current window; according to the difference summary, the ruling target, the compliance disclosure boundary and the evidence action library, generating a minimum necessary proof sequence; according to the minimum necessary proof sequence, the state snapshot root and the set commitment root, performing path verification, and checking the consistency of the backward link and the cross anchor, outputting an attribution conclusion and an evidence index; the consistency of the attribution conclusion and the evidence index is checked, and the checking result is snapshot solidified to obtain a current snapshot block; performing double verification of forward commitment and chain continuity on the current snapshot block, and in response to the double verification passing, taking the current snapshot block as a last snapshot block of a next window.

2. The method of claim 1, wherein, The method comprises the following steps: based on the session token, generating a state snapshot root corresponding to the account and asset balance of the hosting party, a set commitment root and a rule commitment digest of the current window, and combining the state snapshot root, the set commitment root and the rule commitment digest to generate a commitment package; based on the session token, arranging the account and asset balance matrix of the hosting party according to asset dimension and account dimension to generate the state snapshot root; based on the session token, generating the set commitment root for the set of confirmed account events of the current window; based on the window identifier in the session token, performing entry commitment processing on the preset rule item corresponding to the current window to obtain the rule commitment digest; 3. The method of claim 1, wherein, combining the state snapshot root, the set commitment root and the rule commitment digest to generate the commitment package. The method comprises the following steps: according to the asset classification mapping in the rule commitment digest, locating the corresponding asset dimension on the state snapshot root, and generating the difference summary by comparing the summary identifier of the same asset dimension in the commitment package of the hosting party and the business party and the difference prompt of the set commitment root; 4. The method of claim 1, wherein, determining the ruling target of the reconciliation session of the current window according to the compliance disclosure boundary and the rule commitment digest. The method comprises the following steps: output an ordered evidence request list as the minimum necessary proof sequence based on the difference digest, the adjudication target, the compliance disclosure boundary and the evidence action library; wherein the ordered evidence request list comprises evidence request items required to achieve deterministic attribution.

5. The method of claim 1, wherein, perform path verification according to the minimum necessary proof sequence, the state snapshot root and the set commitment root, and check consistency of the backward link and the cross anchor, and output an attribution conclusion and an evidence index, comprising: perform path verification according to the minimum necessary proof sequence, the state snapshot root and the set commitment root, and check consistency of the backward link and the cross anchor; in response to the path verification and the consistency check passing, generate index items, and combine all the index items into the evidence index; determine deterministic attribution of each of the index items according to the adjudication target, and generate the attribution conclusion.

6. The method of claim 1, wherein, perform consistency checking on the attribution conclusion and the evidence index, and perform snapshot solidification according to a checking result, to obtain a current snapshot block, comprising: perform consistency checking according to the attribution conclusion and the evidence index; in response to the checking result being that the consistency checking passes, determine a classification result of the attribution conclusion; the classification result comprises a rule coverage difference and an asset real mismatch; perform the snapshot solidification on the classification result, to obtain the current snapshot block.

7. The method of claim 1, wherein, perform double verification of forward commitment and chain continuity on the current snapshot block, and in response to the double verification passing, take the current snapshot block as a previous snapshot block of a next window, comprising: the hosting party and the business party jointly read a forward commitment field in the current snapshot block, and perform forward commitment verification with the window identifier and the session token; in response to the forward commitment verification passing, check whether a binding relationship of chain continuity of snapshots between the hosting party and the business party is established according to the backward link and the cross anchor in the current snapshot block; in response to the binding relationship being established, take the current snapshot block as a previous snapshot block of a next window.

8. A reconciliation apparatus, characterized by The apparatus comprises: a session token generation module configured to obtain a compliance disclosure boundary pre-set by a hosting party and a business party, and jointly perform cross signing and referencing on a previous snapshot block of a previous window to generate a window identifier and a backward link, and combine the window identifier, the backward link and the compliance disclosure boundary to generate a session token; wherein the compliance disclosure boundary has a binding relationship with a preset evidence action library; a commitment package generation module configured to generate, based on the session token, a state snapshot root corresponding to an account and an asset balance of the hosting party, a set commitment root and a rule commitment digest of a current window, and combine the state snapshot root, the set commitment root and the rule commitment digest to form a commitment package; a difference digest and adjudication target generation module configured to generate a difference digest and an adjudication target of the current window according to the commitment package; a minimum necessary proof sequence generation module configured to generate a minimum necessary proof sequence according to the difference digest, the adjudication target, the compliance disclosure boundary and the evidence action library; a difference digest and adjudication target generation module configured to generate a difference digest and an adjudication target of the current window according to the commitment package; An attribution and index output module is configured to perform path verification according to the minimum necessary proof sequence, the state snapshot root and the set commitment root, check consistency of the backward link and the cross anchor, and output an attribution conclusion and an evidence index; A current snapshot block determination module is configured to perform consistency checking on the attribution conclusion and the evidence index, and perform snapshot solidification on a checking result to obtain a current snapshot block; A current snapshot block verification module is configured to perform double verification of forward commitment and chain continuity on the current snapshot block, and in response to the double verification passing, take the current snapshot block as a previous snapshot block of a next window.

9. An electronic device, comprising: The electronic device comprises: at least one processor; and a memory connected with the at least one processor in communication; wherein the memory stores a computer program executable by the at least one processor, and the computer program is executed by the at least one processor to enable the at least one processor to perform the account reconciliation method of any one of claims 1-8.

10. A computer-readable storage medium, characterized in that, The computer readable storage medium stores computer instructions for causing the processor to implement the account reconciliation method of any one of claims 1-8 when executed.

Images