System-crossed order financing repayment account change locking and performance data closed loop management method

Abstract

The present application relates to the technical field of data management, and further relates to a method for realizing order financing repayment account change locking and performance data closed loop management across systems, which comprises the following steps: step 1, an e-commerce platform, a business and financial integrated system and a fund party system are taken as accounting nodes to access a consortium chain network provided with an account locking smart contract, and a repayment account locking voucher containing an account summary and a locking state field is created; step 2, performance documents are uploaded to a distributed storage network, and content identification is nested step by step to form a performance data closed loop, and the payment is released after consistent summary comparison, the payment amount is accumulated on the chain in homomorphic ciphertext, and the repayment account change is updated after being signed and confirmed by the fund party; step 3, when the cumulative repayment amount plaintext reaches the total financing repayment amount, the settlement proof is verified and signed to rewrite the settlement state. The present application realizes the cross-system unified locking of the repayment account and the performance data closed loop management, and improves the fund safety and the audit efficiency.

Description

Technical Field

[0001] This invention relates to the field of data management technology, and in particular to a method for cross-system implementation of order financing and repayment account change locking and performance data closed-loop management. Background Technology

[0002] Order financing is a form of supply chain finance that uses trade orders and their fulfillment payments as the source of repayment. Funders typically require payers to deposit payments into a designated repayment account to secure the repayment source. In current business practices, e-commerce platforms manage orders and shipments, integrated business and finance systems handle invoice issuance and payments, and the funding party's system handles credit approval and post-loan monitoring. These three systems operate independently, each maintaining its own database. The agreed repayment account and its changes rely primarily on correspondence, emails, or offline communication for synchronization. This process is lengthy and inefficient. When account changes are delayed or tampered with, payers struggle to identify them promptly, increasing the risk of payments being deposited into unauthorized accounts. Furthermore, shipping documents, invoice data, and payment receipts are stored separately within each system, lacking machine-verifiable links. Post-loan verification and auditing rely on manual comparison of each document, which is inefficient and makes it difficult to detect subsequent document tampering. Existing blockchain-based supply chain finance solutions mostly store the hash values ​​of trade data on the blockchain, improving the tamper-proof capability of individual data entries. However, the control of changes to the payment account remains an off-chain process, with each stage of evidence storage isolated from the others, failing to form a coherent chain of evidence. If the payment amount is stored on the blockchain in plaintext, sensitive commercial information is exposed; if only the hash value is stored, the progress of payments and settlement determination cannot be completed on-chain. Therefore, there is an urgent need for a management method that can uniformly lock payment accounts across systems, accumulate payment amounts on-chain while maintaining confidentiality, and create an auditable closed loop for performance data. Summary of the Invention

[0003] In view of this, the present invention provides a method for cross-system implementation of order financing repayment account change locking and performance data closed-loop management, in order to solve the problems of lagging synchronization of repayment accounts across systems, weak change control, difficulty in balancing repayment amount on-chain and confidentiality, and difficulty in closed-loop verification of performance data in existing order financing business.

[0004] The technical solution adopted in this invention is as follows:

[0005] A method for cross-system implementation of order financing and repayment account change locking and performance data closed-loop management includes the following steps:

[0006] Step 1: Connect the e-commerce platform, the integrated business and finance system, and the funding party system as accounting nodes to the consortium blockchain network with deployed account locking smart contracts; After the funding party system approves the order financing application, it determines the total amount of financing to be repaid and the designated repayment account. Based on the account string of the designated repayment account, it performs a hash operation to obtain the account digest. The account locking smart contract then creates a repayment account locking certificate that includes the account digest and a locking status field with the value of the locked state.

[0007] Step 2: Each accounting node uploads the performance documentation to the distributed storage network and writes the obtained content identifier and corresponding stage tag into the performance evidence chain maintained by the account locking smart contract. The subsequent stage's documentation embeds the content identifier of the previous stage, forming a closed loop of performance data. When the integrated business and finance system initiates a payment, it performs the same hash operation on the payee account in the payment instruction to obtain the digest to be verified. The payment instruction is released when the digest to be verified matches the account digest and the lock status field is in the locked state. After payment, the actual payment amount is homomorphically encrypted into the ciphertext of the return amount and submitted to the account locking smart contract for homomorphic accumulation to the cumulative return ciphertext field. During the financing period, if the return account change application is approved by the account locking smart contract after verifying the signature confirmation returned by the funding party system, the return account lock certificate is updated with the account digest of the changed account.

[0008] Step 3: The funding party system decrypts the encrypted field of cumulative repayments. When the plaintext of the cumulative repayment amount reaches the total amount of financing due, it submits a signed settlement certificate to the account-locked smart contract. After the account-locked smart contract verifies the signature, it changes the lock status field from locked to settled.

[0009] Furthermore, homomorphic encryption and decryption are implemented using the Paillier algorithm. The funding system generates a Paillier public key and a Paillier private key. The Paillier private key is stored locally by the funding system, while the Paillier public key is published to the consortium blockchain network along with the repayment account locking certificate. Encryption follows... Execution, in which It is a ciphertext. The amount to be encrypted is in plaintext. and The generator and modulus in the Paillier public key. The pair is selected independently for each encryption. Coprime random numbers; the funding system will A value of 0 is used to execute encryption to generate initial ciphertext. The account-locked smart contract writes the initial ciphertext into the accumulated repayment ciphertext field; homomorphic accumulation is performed as ciphertext multiplication and modular arithmetic. ,in The current ciphertext in the cumulative repayment ciphertext field. The amount to be refunded is encrypted. To write back the new ciphertext of the cumulative repayment ciphertext field, based on the Paillier additive homomorphic property, The plaintext obtained by decrypting with Paillier's private key is equal to and The sum of the corresponding plaintext amounts; the actual payment amount is expressed as a positive integer in the smallest monetary unit, and the sum of the total amount of financing due and the total amount of actual payments is less than the modulus. .

[0010] Furthermore, the funding system assigns a financing contract number to each approved order financing application. For each financing contract number, a random account digest salt value is generated. The financing contract number, account digest salt value, and the account number string of the designated repayment account are concatenated, and a hash operation is performed using a collision-resistant hash algorithm uniformly agreed upon by the consortium blockchain network to obtain the account digest. The account digest salt value is then written into the repayment account locking certificate. The integrated business and finance system synchronizes the repayment account locking certificate from the consortium blockchain network and registers the account digest in the list of controlled collection accounts bound to the financing contract number within the payment module. The payment module is deployed in the business... Within the integrated business and finance system, when the payment module initiates a payment, it concatenates the financing contract number, the account summary salt value in the repayment account lock certificate, and the receiving account in the payment instruction in the same order and performs a hash operation to obtain the digest to be verified. If there is a difference between the digest to be verified and the account summary, the payment module transfers the payment instruction to the manual review queue and calls the account lock smart contract to write an early warning event record containing the financing contract number, payment serial number, and digest to be verified. After the integrated business and finance system detects an on-chain event where the lock status field is changed to the settlement status, it removes the account summary from the list of controlled receiving accounts.

[0011] Furthermore, the distributed storage network is the IPFS distributed storage network. The content identifier is determined by the hash result corresponding to the content of the performance document under the preset content addressing rules of the IPFS distributed storage network. The performance document includes the shipping document, the invoice data file, and the payment receipt file. After the e-commerce platform completes the shipment of a trade order, it generates a shipping document, which records the trade order number, the tracking number, and the shipment time. After uploading, it obtains the first content identifier, which, along with the shipment stage tag, is written into the performance evidence storage chain. After the integrated business and finance system completes the invoice issuance, it generates an invoice data file, which records the invoice number and the invoice issuance time. After embedding the first content identifier in the invoice data file, it is uploaded to obtain the second content identifier, which, along with the invoice stage tag, is written into the performance evidence storage chain. After the integrated business and finance system completes the payment, it generates a payment receipt file. After embedding the second content identifier in the payment receipt file, it is uploaded to obtain the third content identifier corresponding to the payment serial number, which, along with the payment stage tag, is written into the performance evidence storage chain.

[0012] Furthermore, the account-locked smart contract pre-registers the node certificates of three accounting nodes, and registers the mapping relationship between the delivery stage label and the e-commerce platform, the invoicing stage label and the payment stage label and the submission entity of the integrated business and finance system. Before writing the content identifier and stage label into the performance evidence chain, the account-locked smart contract verifies that the identity of the submitter's accounting node is consistent with the submission entity preset by the stage label based on the mapping relationship between the node certificate and the submission entity.

[0013] Furthermore, after the payment instruction is released, the integrated business and finance system pays the funds to the designated return account through the bank-enterprise direct connection interface and receives the payment receipt data returned by the bank-enterprise direct connection interface; the payment receipt document is generated based on the payment receipt data and records the payment serial number, payment time, actual payment amount and the receipt signature returned by the bank-enterprise direct connection interface; the integrated business and finance system submits the encrypted return amount, payment serial number, third content identifier and payment stage tag to the account lock smart contract, and the encrypted return amount is bound to the payment receipt document through the third content identifier for evidence storage.

[0014] Furthermore, the account-locked smart contract concatenates the trade order number and payment transaction number and performs a hash operation to obtain a unique payment transaction identifier. When the unique payment transaction identifier is registered for the first time in the payment transaction registration table maintained by the account-locked smart contract, the account-locked smart contract binds the unique payment transaction identifier with the third content identifier and writes it into the payment transaction registration table, and performs homomorphic accumulation so that the actual payment amount of each payment is accumulated exactly once.

[0015] Furthermore, the designated repayment account is the supervisory account opened by the funding party system; the funding party system pre-generates a signature private key and a verification public key, the signature private key is stored locally by the funding party system, and the verification public key is written into the repayment account lock certificate; the repayment account change application is initiated by the financing applicant for the financing contract number and submitted to the account lock smart contract through the e-commerce platform; when the lock status field is locked, the account lock smart contract assigns a change application number to the change application, registers the change application and the change application number as pending confirmation, and pushes a confirmation request to the funding party system. Subsequent change applications submitted under the same financing contract number are registered in a queue according to the submission order and processed sequentially. During the pending confirmation period, the payment module continues to perform payment verification based on the currently registered account summary in the repayment account lock certificate; after the funding party system verifies that the changed account is a supervisory account, it regenerates the account summary salt value, using the financing contract number and the regenerated account summary salt value. The account string of the changed account is used as input. The account digest of the changed account is calculated using the same concatenation order and anti-collision hash algorithm. The plaintext of the changed account is stored locally by the funding system and the integrated business and finance system. The funding system concatenates the financing contract number, change application number, original account digest, changed account digest, regenerated account digest salt value, and change timestamp into data to be signed, and uses the signing private key to generate a signature confirmation. The account locking smart contract uses the verification public key to verify the signature confirmation. After the signature confirmation is verified and the change application number in the signature confirmation matches the change application number registered in the pending confirmation status, the repayment account locking certificate is updated with the regenerated account digest salt value and the changed account digest. The update event is pushed to the integrated business and finance system to refresh the list of controlled collection accounts. When the lock status field is in the settled state, the account locking smart contract directly executes the change registration for the repayment account change application.

[0016] Furthermore, when the funding system detects an update event in the cumulative repayment encrypted field, it reads the current encrypted text in the cumulative repayment encrypted field and performs decryption. When the cumulative repayment amount in plaintext reaches the total amount of financing due, the funding system reads the payment receipt files pointed to by the third content identifiers corresponding to the payment stage tags in the performance record chain. After comparing the sum of the actual payment amounts recorded in each payment receipt file with the cumulative repayment amount in plaintext, it generates a settlement certificate containing the settlement time. After the account-locked smart contract verifies the settlement certificate, it concatenates all the content identifiers registered in the performance record chain with the corresponding stage tags according to the registration order, performs a hash operation to obtain a closed-loop evidence digest, and writes the closed-loop evidence digest along with the settlement certificate into the settlement record.

[0017] Furthermore, the e-commerce platform forwards the order financing application submitted by the financing applicant based on the trade order to the funding party's system, adds a financing lock mark to the trade order, and removes the financing lock mark after listening to the on-chain event that the lock status field is rewritten to the settlement status. Both delivery and payment are executed for trade orders carrying financing lock marks. During audit verification, the closed-loop evidence summary in the settlement record is used as the entry point. The summary is recalculated according to the same registration order and hash operation and compared with the closed-loop evidence summary. After it is consistent, the payment receipt file, invoice data file and delivery document file in the IPFS distributed storage network are traced back level by level along the third content identifier, the second content identifier and the first content identifier. The data is compared with the tags of each link in the performance evidence chain to complete the closed-loop verification of the performance data of the entire order financing process.

[0018] By adopting the above technical solution, this invention achieves the following beneficial effects: the e-commerce platform, the integrated business and finance system, and the funding party system jointly maintain the lock certificate for the repayment account as accounting nodes. The locking relationship of the repayment account is uniformly presented in the form of on-chain consensus data. The payment exit releases the payment instruction based on the comparison result of the account summary. Payments to incorrect accounts are intercepted before the funds leave the account. Changes to the repayment account must be confirmed by the signature of the funding party system to take effect. The change result takes effect synchronously on the ledgers of each accounting node, fundamentally eliminating the financial risks caused by cross-system drift and uncontrolled changes; the account is recorded on the chain in the form of a summary, and the repayment amount... By accumulating homomorphic encrypted data, the on-chain collection and settlement determination of repayment progress are completed under the premise that both account and amount plaintexts are kept confidential, thus simultaneously achieving privacy protection and verifiability. The performance documents are nested and connected in a hierarchical manner through the content identifiers of the distributed storage network to form a complete chain of evidence. Upon settlement, a closed-loop evidence summary covering the entire process is generated and sealed in the settlement record. The auditor can determine the integrity of all evidence by recalculating the summary once, and can trace back the documents at each stage along the content identifiers. Any tampering, missing, or change of registration order at any stage will be exposed during verification, significantly improving the fund security, data credibility, and audit efficiency of the entire order financing process. Attached Figure Description

[0019] Figure 1 This is a numerical experimental diagram illustrating the homomorphic accumulation of the ciphertext of the repayment amount in an embodiment of the present invention;

[0020] Figure 2 This is a schematic diagram illustrating the empirical cumulative distribution of two sets of plaintext and ciphertext corresponding to monetary amounts in an embodiment of the present invention;

[0021] Figure 3 This is a schematic diagram of the avalanche characteristics experiment with salted summary input in an embodiment of the present invention;

[0022] Figure 4This is a schematic diagram of the detection strength of content identifier tampering in an embodiment of the present invention;

[0023] Figure 5 This is a schematic diagram of the timing of cross-system states during the locking period in an embodiment of the present invention. Detailed Implementation

[0024] A method for cross-system implementation of order financing and repayment account change locking and performance data closed-loop management includes the following steps:

[0025] Step 1: Connect the e-commerce platform, the integrated business and finance system, and the funding party system as accounting nodes to the consortium blockchain network with deployed account locking smart contracts; After the funding party system approves the order financing application, it determines the total amount of financing to be repaid and the designated repayment account. Based on the account string of the designated repayment account, it performs a hash operation to obtain the account digest. The account locking smart contract then creates a repayment account locking certificate that includes the account digest and a locking status field with the value of the locked state.

[0026] Step 2: Each accounting node uploads the performance documentation to the distributed storage network and writes the obtained content identifier and corresponding stage tag into the performance evidence chain maintained by the account locking smart contract. The subsequent stage's documentation embeds the content identifier of the previous stage, forming a closed loop of performance data. When the integrated business and finance system initiates a payment, it performs the same hash operation on the payee account in the payment instruction to obtain the digest to be verified. The payment instruction is released when the digest to be verified matches the account digest and the lock status field is in the locked state. After payment, the actual payment amount is homomorphically encrypted into the ciphertext of the return amount and submitted to the account locking smart contract for homomorphic accumulation to the cumulative return ciphertext field. During the financing period, if the return account change application is approved by the account locking smart contract after verifying the signature confirmation returned by the funding party system, the return account lock certificate is updated with the account digest of the changed account.

[0027] Step 3: The funding party system decrypts the encrypted field of cumulative repayments. When the plaintext of the cumulative repayment amount reaches the total amount of financing due, it submits a signed settlement certificate to the account-locked smart contract. After the account-locked smart contract verifies the signature, it changes the lock status field from locked to settled.

[0028] The following section elaborates on the construction of the foundation for cross-system collaboration in consortium blockchains, the generation of repayment account lock credentials, and the implementation process of cross-system lock registration, using specific implementation methods as examples.

[0029] Order financing spans three independently operating systems: an e-commerce platform manages the entire lifecycle of trade orders, an integrated business and finance system handles invoice issuance and fund disbursement, and a funding party system handles credit approval and post-loan management. Each party maintains its own independent database. In traditional operations, repayment account information is transmitted between the three parties via letters, emails, and manual verification, leading to delays and the risk of tampering. Connecting each party as a ledger node to the same consortium blockchain network ensures that the locking relationships of repayment accounts exist simultaneously in the ledgers of all three parties as consensus data. Any locking information accessed by any party originates from the same on-chain record that has been jointly endorsed.

[0030] In one specific implementation, the consortium blockchain network is built on Hyperledger Fabric 2.5. The e-commerce platform, the integrated business and finance system, and the funding system each deploy one organization. Each organization is configured with two peer servers and one ordering server. The peer servers are responsible for transaction endorsement and ledger storage, while the ordering server participates in the global ordering service. The three ordering servers run the Raft consensus protocol, and the majority-party mechanism allows the consortium blockchain network to continue producing blocks even when one ordering server is down for maintenance. The block interval is configured to 500 milliseconds, and the maximum number of transactions per block is configured to 500. Based on these parameters, the consortium blockchain network's throughput reaches 1000 transactions per second, providing ample capacity for the tens of thousands of daily notarization and verification requests in order financing. Inter-entity connections are made via dedicated lines with a bandwidth of 100 Mbps, keeping the round-trip latency within 50 milliseconds, thus stabilizing the end-to-end confirmation time for endorsement and ordering in the second range. As an optional implementation, the consortium blockchain network can also be built on FISCO BCOS version 3.0, with the consensus protocol replaced by Byzantine fault-tolerant consensus, while the rest of the process remains the same.

[0031] Node access is accomplished using digital certificates. A certificate authority is established within the consortium blockchain network to issue X.509 format node certificates to the three ledger nodes. The validity period of each node certificate is set to three years, and the certificate contains the organizational identifier of the entity to which the ledger node belongs. Each on-chain transaction carries the initiator's signature, and the signature corresponds one-to-one with the node certificate, thus ensuring cryptographic traceability of the transaction's origin. Account-locked smart contracts are deployed in chaincode form: the contract code is written in Go language version 1.21. Before deployment, the maintenance personnel of the three ledger nodes review the same source code. After passing the review, each node signs the deployment transaction, and the endorsement strategy is configured so that all three ledger nodes endorse the transaction. This full endorsement configuration ensures that every upgrade of the contract logic and every write of credential data requires the complete endorsement signatures of all three parties as a prerequisite for block formation. Any change submitted by a single entity is verified by the other two parties during the endorsement process, thus upgrading cross-system mutual trust from institutional constraints to cryptographic constraints.

[0032] Once the account-locking smart contract is deployed, the initialization logic is executed: the shipping tag is bound to the node certificate of the e-commerce platform, and the invoicing and payment tags are bound to the node certificates of the integrated business and finance system. These binding relationships are written into the contract's world state in the form of a submission subject mapping relationship. This arrangement stems from the ownership of the data source: the e-commerce platform holds the first-hand record of shipping, while the integrated business and finance system holds the first-hand record of invoices and payments. By converging the on-chain submission permissions for each type of performance data to the entity that holds the source data, data credibility is constrained during the entry process, and subsequent audits can directly locate the responsible party for each record along the submission subject mapping relationship.

[0033] The financing process begins with a specific trade order. The financing applicant is the supplier in the trade order, who initiates an order financing application on the e-commerce platform for trade order number PO20250612001. The e-commerce platform forwards the order financing application, along with the order amount, information on both the shipper and consignee, and historical performance records, to the funding party's system. After the funding party's system completes the credit assessment and approves the application, the financing elements are determined as follows: principal of RMB 1,000,000, financing term of 180 days, annualized interest rate of 8%, and interest calculated by multiplying the principal by the annualized interest rate and then by the proportion of the term to the number of days in the year, resulting in RMB 40,000. The total amount to be repaid is RMB 1,040,000. The amount is recorded in the system in the smallest monetary unit, "fen," and the total amount to be repaid is recorded as 104,000,000 fen. The amount is recorded in integer form, and subsequent encryption, accumulation, and comparison all fall within the integer field, eliminating errors caused by decimal rounding at the source. This also provides mathematical convenience for the encrypted accumulation of the repayment amount. The funding party system also generates a financing contract number FC20250612000881 for this financing. The financing contract number is globally unique within the funding party system and will serve as the retrieval key for on-chain credentials throughout the entire financing process.

[0034] The selection of the designated repayment account is based on clear risk control considerations. In one specific implementation, the funding party's system opens a supervisory account at a partner bank, account number 6228480402564890018. The account name is jointly listed by the funding party and the financing applicant. Any external transfers from the supervisory account require the funding party's review and approval. Once the repayment enters the supervisory account, the flow of funds remains within the funding party's visibility and control, thus isolating and protecting the source of repayment. The funding party's system then designates the supervisory account as the designated repayment account. As an optional implementation, for financing applicants with higher credit ratings, the designated repayment account can also be a corporate settlement account registered with the funding party under the applicant's name. This approach relaxes control measures and increases business flexibility.

[0035] Account digest calculation begins with the normalization of the account string. The account string of the specified repayment account is read in UTF-8 encoding, leading and trailing whitespace and delimiters are removed, and it is unified into a continuous sequence of numeric characters. The significance of normalization is that the digest verification mechanism relies on the byte-by-byte consistency of the recalculation results from all parties. If the format of the input byte sequence deviates on any side, the recalculated digest will change as a whole. The unified normalization rules ensure that the same account will necessarily obtain the same digest, which is a fact that can be guaranteed through engineering.

[0036] The hashing process uses a collision-resistant hashing algorithm. In one specific implementation, the collision-resistant hashing algorithm used is SHA-256, with an output length of 256 bits, recorded as 64 hexadecimal characters. In scenarios compliant with Chinese cryptographic standards, the collision-resistant hashing algorithm can be replaced with SM3, also with an output length of 256 bits. The computational cost required to find collisions for both algorithms is... The computational complexity of a hash operation is given by the formula. Representing 2 to the power of 128, the event that two different account strings are mapped to the same digest is negligible in an engineering sense, given the current computing power. Therefore, the digest recorded on the chain can serve as a stable verification benchmark instead of the account plaintext.

[0037] If a hash operation is performed directly on the account string, the strength of the digest protection will be limited by the input space: taking a 19-digit bank card number as an example, the total number of valid numbers that meet the check digit rules is limited. Order of magnitude, in the formula Representing 10 to the power of 12, after obtaining the on-chain digest, an attacker can offline enumerate all candidate accounts, calculate their hashes one by one, and compare them. There is a real possibility that the plaintext of the account can be reverse-engineered. Therefore, in a preferred implementation, the funding system generates a random account digest salt value once for each financing contract number: the account digest salt value is 128 bits long, generated by a cryptographically secure random number generator, and is bound to the financing contract number for fixed use after generation. The calculation of the account digest is represented as... In the formula For account summary, For the selected collision-resistant hash algorithm, The byte sequence corresponding to the financing contract number. Salt value for account summary This is the byte sequence corresponding to the normalized account string. This indicates byte-level concatenation, with the concatenation order uniformly agreed upon by the consortium blockchain network and consistently followed by all parties. (Introduction) Subsequently, the input space that offline enumeration needs to cover expands. The cost is estimated to exceed the limits of real-world computing power; therefore, the introduction of... Subsequently, when the same account serves multiple financing transactions, the on-chain summaries are independent of each other, making cross-contract correlation analysis impossible. The basic implementation and the preferred implementation maintain isomorphism in verification logic, differing only in the composition of the hash input; in engineering, the choice can be made based on privacy requirements.

[0038] like Figure 3 As shown, to examine the sensitivity relationship between the concatenated input and the account digest, all 536 bits of the concatenated input, containing the financing contract number, account digest salt value, and account string, were flipped one by one. SHA-256 operations were performed sequentially, and the number of flipped bits relative to the original value was counted. The experimental frequency closely approximates the normality of the binomial distribution, with a measured mean of 128.5 bits, meaning that a change in any one bit in the concatenated input will cause approximately half of the bits in the digest to be flipped. The avalanche characteristic ensures that the comparison between the digest to be verified and the account digest remains sensitive to any subtle differences in the receiving account; replacing one digit in the account and replacing the entire account result in the same strength of difference signal during the verification process.

[0039] Key preparation and credential creation are completed simultaneously. The funding party's system generates a Paillier public key and a Paillier private key on its local cryptographic server: two randomly selected large prime numbers, each 1024 bits in length. and Calculate the modulus In the formula For modulus, and For large prime numbers chosen independently, the modulus The length is 2048 bits; the generator takes In the formula As the generator, the Paillier public key is generated by the generator. With modulus Composition; Paillier private key retrieval In the formula The private key parameter used for decryption. This indicates finding the least common multiple. and These are the values ​​obtained by subtracting 1 from each of the two large prime numbers. The factorization difficulty of the 2048-bit modulus is comparable to that of the RSA modulus of the same length, and it has sufficient security margin by existing large integer factorization algorithms. Paillier's private key is written into the hardware security module local to the funding system. The decryption operation is completed within the hardware security module, and the channel for the private key to leave the hardware boundary is physically closed. At the same time, the funding system generates a pair of signing keys, namely the signing private key and the verification public key: using an elliptic curve digital signature system, the curve can be either the secp256k1 curve or the national cryptographic SM2 recommended curve. The length of the signing private key is 256 bits, and it is also stored within the hardware security module; the verification public key is then published to the consortium blockchain network along with the repayment account lock certificate, so that the account lock smart contract can perform signature verification in the subsequent change confirmation and settlement confirmation stages.

[0040] The initial ciphertext is also generated at this point. The funding system then sends the amount in plaintext. The value is set to 0, and encryption is performed once using the Paillier public key to obtain the initial ciphertext. In the formula This is the initial ciphertext. The amount to be encrypted is in plaintext. The modulus is randomly selected during encryption. Coprime random numbers, coprime refers to and The greatest common divisor is 1. This represents the modulo operation. For modulus The square of 0. Using a 0-value ciphertext as the starting point for the cumulative repayment ciphertext field has two considerations: 0 is an identity in addition, so the ciphertext of each subsequent repayment amount is directly superimposed on the ciphertext field, and the starting point itself contributes zero to the cumulative result; random numbers are introduced into the encryption process. The initial ciphertext with a value of 0 appears to have the same random distribution as the ciphertext with any amount. On-chain observers read zero amount of monetary information from the initial ciphertext. The cumulative field is protected by ciphertext from the moment it is created.

[0041] After the above preparations are completed, the creation of the repayment account lock certificate is accomplished with a single on-chain transaction. The funding party system, acting as the transaction initiator, calls the certificate creation interface of the account lock smart contract. The transaction payload carries the account summary, financing contract number, account summary salt value, verification public key, Paillier public key, and initial ciphertext. The account lock smart contract assembles the repayment account lock certificate using the financing contract number as the key. In one specific implementation, the certificate fields include the account summary, financing contract number, account summary salt value, verification public key, Paillier public key, lock status field, and creation timestamp. The lock status field uses integer encoding, with a value of 1 representing a locked state and a value of 2 representing a settled state. When the certificate is created, the lock status field is directly written with a value of 1. The initial ciphertext is written to the cumulative repayment ciphertext field corresponding to the financing contract number along with the same transaction. Certificate creation and lock activation are completed atomically within a single transaction. The lock effect is generated synchronously from the moment the certificate is written to the block. The time window of the certificate being created but the lock being delayed is compressed to zero, and the timing vulnerability of lock registration is structurally eliminated. The creation of a transaction involves endorsement by three ledger nodes, sorting by a sorting service, and packaging into blocks. Each ledger node synchronously updates the world state. The world state database uses LevelDB, with the key being the financing contract number and the value being the byte string of the credential after JSON serialization. The storage overhead of a single credential is controlled within 1 kilobyte, and the total number of credentials for millions of financing contracts occupies approximately 1 gigabyte of storage space, resulting in a minimal engineering burden. As an optional implementation, the credential key can also be the account summary itself, or the hash value of the financing contract number and the account summary concatenated together. The retrieval dimensions can be adjusted according to the query habits of the business side. The lock status field can also be extended to take the value 3 to represent the pending verification state, used for temporary control when a risk event occurs. The state machine will correspondingly add a migration path from the locked state to the pending verification state and then back to the locked state.

[0042] The on-chain event triggered by the creation of the credential extends the locking effect to both business systems. Upon detecting the credential creation event, the integrated business and finance system synchronizes the payment account locking credential from the consortium blockchain network, registering the account summary in the controlled collection account list bound to the financing contract number. The payment module deployed within the integrated business and finance system performs summary verification on each payment matching the controlled collection account list. Upon detecting the same event, the e-commerce platform adds a financing lock tag to the trade order corresponding to the financing contract number. Trade orders carrying the financing lock tag enter the lock control process during both shipment and payment stages. These two registrations transform an on-chain credential into a rigid constraint within the business process. The cross-system payment account locking is thus initially registered: three accounting nodes hold identical copies of the credential, using the financing contract number as an index, the account summary as the verification basis, and a locked state field as the initial state. Subsequent payment verification, payment amount accumulation, account change control, and settlement unlocking are all based on this credential as a unified on-chain basis.

[0043] After the cross-system lock registration is completed, the financing enters the performance period. Step 2 simultaneously advances four threads during the performance period: closed-loop storage of performance documents, summary verification of payment exits, encrypted accumulation of repayment amounts, and change control of repayment accounts during the lock period. The four threads share the same repayment account lock certificate and the same performance storage chain, which will be elaborated on below.

[0044] The evidence of fulfillment begins with the shipment process. In one specific implementation, the distributed storage network is built using IPFS: the e-commerce platform, the integrated business and finance system, and the funding system each run one storage node. These three storage nodes are networked together in a private network, with three file replicas. Each storage node maintains a full copy, ensuring continued read service in the event of a single point of failure. Files are written in 256-kilobyte blocks, which are hashed and then aggregated layer by layer to form content identifiers. These content identifiers are in version 1 format and Base32 encoded, with a length of 59 characters. The key to content addressing is that the content identifier is derived from the file content through a hash operation. Any change to even a single byte of the file content alters the entire content identifier, creating a rigid correspondence between the file and the content identifier maintained by the hash function: possessing the content identifier allows verification of the retrieved file; tampering with the file renders the original content identifier invalid, and the tampering is automatically exposed during the read process. As an optional implementation, the distributed storage network can also be a self-built object storage cluster within the alliance, as long as the storage layer provides addressing semantics with content hash as the key, the effectiveness of the evidence storage mechanism remains consistent.

[0045] like Figure 4As shown, to measure the detection strength of content identifiers against file tampering, random tampering ranging from 1 byte to 1024 bytes was applied to the document files. Each tampering amount was repeated 20 times, and the number of bits flipped relative to the original value of the content identifier was counted. All test points clustered around the theoretical mean of 128 bits. Changing 1 byte and changing 1024 bytes caused the same order of magnitude of identifier flipping. The detection strength was decoupled from the tampering magnitude. Minor tampering and major tampering were equally exposed in the verification process. The hierarchically nested performance data closed loop thus achieved uniform and sufficient anti-tampering sensitivity.

[0046] After trade order number PO20250612001 is shipped, the e-commerce platform generates a shipping document. This document, organized in JSON format, records the trade order number PO20250612001, the tracking number SF1390276450876, and the shipping time: June 13, 2025, at 10:20 AM. The e-commerce platform uploads the shipping document to the IPFS distributed storage network, obtaining the first content identifier. It then submits this first content identifier, along with the shipping stage tag and the financing contract number FC20250612000881, to the account-locking smart contract. The account-locking smart contract parses the submitter's node certificate from the transaction signature and compares it item by item with the submission entity mapping relationship written during the initialization phase. The shipping stage tag defaults to the e-commerce platform as the submitter; only submissions with matching identities are entered into the ledger. Unauthorized submissions are identified during the verification process and recorded in the alarm log. After successful verification, the account-locking smart contract appends the first content identifier, the delivery stage tag, the chain list sequence number 1, and the submission timestamp to the performance record chain corresponding to the financing contract number. This fixes the submission permission to the data source entity, determining the responsible party for each record on the chain from the moment it is written. Subsequent audits can then trace responsibility line by line along the mapping relationship between the submitting entities.

[0047] The invoice documentation process exhibits a nested design. After the integrated business and finance system issues an invoice, it generates an invoice data file, recording the invoice number 24442000000123456789 and the invoice date June 20, 2025. A first content identifier is embedded in a reserved field within the invoice data file. After embedding, it is uploaded to the IPFS distributed storage network to obtain a second content identifier. Since the first content identifier is already part of the invoice data file content, the second content identifier mathematically anchors both the invoice content and the delivery content: anyone retrieving the invoice data file can verify the invoice itself and also retrieve the delivery documents for further verification by following the embedded first content identifier. This layered embedding of content identifiers from subsequent stages is recursive. The documents for delivery, invoicing, and payment are linked together in a unidirectional chain of references. The closed loop of performance data is maintained by the mathematical properties of content addressing. Tampering with any link will break the nested relationship of the downstream stages, thus allowing the integrity verification of the closed loop to be automated. As an optional implementation, the embedding location can also be chosen to be the metadata area appended at the end of the file, while maintaining consistent nesting semantics. The second content identifier, along with the invoicing stage tag, is submitted to the account that locks the smart contract. After verification by the same submitting entity, it is appended to the performance verification chain at chain number 2.

[0048] The summary verification of the payment export is the key to the effectiveness of the lock. When the integrated business and finance system initiates payment for a trade order carrying a financing lock tag, the payment module first searches the list of controlled receiving accounts by the financing contract number. If a match is found, it queries the consortium blockchain network for the receiving account lock certificate, extracts the account summary salt value and account number summary from the certificate, and then concatenates the financing contract number, account summary salt value, and receiving account number from the payment instruction in the agreed order. A hash operation is then performed using the same collision-resistant hash algorithm as when the certificate was created, resulting in the summary to be verified. The calculated summary is represented as follows: In the formula This is the digest to be verified. For the selected collision-resistant hash algorithm, The byte sequence corresponding to the financing contract number. Salt value for account summary This is the normalized byte sequence corresponding to the payee's account number in the payment instruction. This indicates byte-level concatenation. The payment module releases the payment instruction only when the digest to be verified matches the account digest byte-by-byte, and the locking state represented by a value of 1 in the lock status field is simultaneously established. Digest comparison moves the verification point forward to before funds leave the account; payments to erroneous accounts are stopped at the instruction exit point. Both ends of the comparison are digests; the plaintext account information is absent from the blockchain from beginning to end. Verification capability and privacy protection are achieved through the same hash mechanism. On-chain credential lookup takes on the order of 10 milliseconds, and hash operations take on the order of microseconds; the delay added to payment timeliness by the entire verification process is negligible.

[0049] When a discrepancy exists between the summary to be verified and the account summary, the payment module transfers the payment instruction to the manual review queue. Simultaneously, it invokes the account locking smart contract to write an alert event record. This record includes the financing contract number, payment transaction number, and the summary to be verified. This discrepancy event is thus recorded on the blockchain, and all three parties are simultaneously notified of the same alert. As an optional implementation, the alert event can also be linked to an SMS channel to push reminders to the funding party's post-loan personnel, shortening the response time for manual intervention.

[0050] After verification and approval, the payment is completed via a direct bank-enterprise connection. A direct message channel is established between the integrated business and finance system and the core system of the partner bank. After the payment instruction message is sent, the bank executes the transfer and returns payment receipt data within 3 seconds. The payment receipt data carries a receipt signature generated by the bank. The receipt signature provides cryptographic endorsement of the payment fact from the bank, thus providing the subsequent generated off-chain documents with a bank-side anchor of authenticity. The first repayment under this financing occurred at 14:05 on July 15, 2025, with payment transaction number PAY20250715000366, and an actual payment amount of 520,000 yuan, expressed in 52,000,000 fen (cents). The integrated business and finance system generates payment receipt files based on payment receipt data, recording the payment transaction number, payment time, actual payment amount (52,000,000 points), and receipt signature. After embedding a second content identifier within the payment receipt file, it is uploaded to the IPFS distributed storage network to obtain a third content identifier corresponding to the payment transaction number PAY20250715000366. Each payment generates its own payment receipt file and obtains its own third content identifier. In scenarios with multiple payments, each third content identifier is nested within the same second content identifier, and the closed-loop structure naturally extends with the number of payments.

[0051] The on-chain recording of payment amounts uses an encrypted channel. The integrated business and finance system reads the Paillier public key from the payment account lock voucher and encrypts the actual payment amount according to the encryption procedure. Proceed, in the formula The encrypted amount of the repayment is obtained through encryption. The plaintext amount to be encrypted is 52,000,000. For the generator in Paillier's public key, The modulus in the Paillier public key. The modulus was randomly selected during this encryption process. Coprime random numbers, coprime refers to and The greatest common divisor is 1. This represents the modulo operation. For modulus The square of. Random number. The method of selecting the ciphertext independently for each encryption step serves several purposes: encrypting the same amount twice results in ciphertexts that are visually distinct, ensuring that any pattern in the ciphertext sequence reads by an on-chain observer is zero; the repayment schedule and individual transaction amounts remain closed to other on-chain participants; and the funder has exclusive decryption capabilities using their Paillier private key. After encryption, the integrated business and finance system submits the ciphertext of the repayment amount, payment serial number, third-party content identifier, and payment stage tag to the account-locked smart contract. The ciphertext of the repayment amount is then linked to the payment receipt document via the third-party content identifier, creating a notarized record. The ciphertext and document mutually verify each other from the moment of submission.

[0052] like Figure 2 As shown, a distribution experiment was conducted to investigate the randomization effect of ciphertext resulting from independent selection of random numbers: two distinct monetary amounts were each encrypted 200 times, and the empirical cumulative distribution of the normalized ciphertext values ​​was statistically analyzed. The two empirical cumulative distribution curves overlapped and closely followed the uniform distribution reference line. The maximum deviation between the two distributions, i.e., the KS statistic, was 0.100, which is within the normal fluctuation range of the same distribution assumption. This indicates that the ability of the ciphertext value distribution characteristics to distinguish the monetary amounts is negligible, and the size and pace of repayments under the same financing project remain closed to other participants on the blockchain.

[0053] The account-locked smart contract performs idempotency processing before accumulation. Network jitter-induced message retransmissions and application-layer timeout retries can cause the same payment submission message to reach the chain more than twice. If directly accumulated, the same payment would be counted twice. To address this, the account-locked smart contract concatenates the trade order number and payment transaction number, performs a hash operation to obtain a unique payment transaction identifier, and then queries the payment transaction registration table corresponding to the financing contract number. If the unique payment transaction identifier is registered for the first time, the account-locked smart contract binds the unique payment transaction identifier with the third content identifier and writes it into the payment transaction registration table, then performs accumulation; if the unique payment transaction identifier is already registered, the account-locked smart contract directly ends the current processing, thus terminating the impact of duplicate messages, and the actual payment amount of each payment is accumulated exactly once. As an optional implementation, the input for concatenating the unique payment transaction identifier can also be a combination of the financing contract number and the payment transaction number. Both methods ensure the uniqueness of the identifier under the financing item.

[0054] The accumulation is performed on the ciphertext field. The account-locked smart contract retrieves the current ciphertext from the accumulated repayment ciphertext field and performs a ciphertext multiplication and modular arithmetic with the newly received repayment amount ciphertext. In the formula The current ciphertext in the cumulative repayment ciphertext field. This is the encrypted message containing the amount of repayment submitted this time. This is used to calculate and write back the new ciphertext field of the cumulative repayment. Ciphertext multiplication corresponds to plaintext addition, and the reason can be directly seen from the structure of the ciphertext: In the formula for The corresponding amount in plain text, for The corresponding amount in plain text, and The random numbers selected for each of the two encryptions are used, and the product still maintains the [previous encryption method]. The power of carries the plaintext, with random numbers The power of a power carries the randomness of a legitimate ciphertext form, where the plaintext at each power is exactly added together. The plaintext obtained by decrypting with Paillier's private key is equal to and The sum. The account-locked smart contract handles only encrypted data throughout, yet the addition semantics are fully preserved. On-chain aggregation of repayment progress and protection of monetary privacy are achieved simultaneously in the same operation. The range of amounts is subject to hard constraints in the engineering: actual payment amounts are represented as positive integers in the smallest monetary unit, and the sum of the total amount owed and all actual payments must be less than the modulus. The constraint arises because Paillier's decryption result falls within the range specified in the original text. Within the remaining system of the model, once the accumulated plaintext exceeds... This will wrap around to a number much smaller than the true value, skewing the settlement decision. Modulus The length is 2048 bits, and the value is in Order of magnitude, in the formula This represents 2 to the power of 2048, while financing amounts measured in fractions, even reaching trillions of yuan, would only be... Order of magnitude, in the formula Representing 10 to the power of 14, the two are vastly different. This constraint naturally holds true in real-world business scenarios. The validation logic is written to solidify the mathematical premise into a hard check at the code level. On September 10, 2025, the second repayment of 52,000,000 points, using payment serial number PAY20250910000871, completed the same validation, notarization, and accumulation process. The plaintext corresponding to the encrypted repayment field now reached 104,000,000 points, matching the total amount owed in financing, thus preparing the conditions for settlement.

[0055] like Figure 1 As shown, to verify the correctness and confidentiality of homomorphic accumulation in a multi-repayment scenario, a numerical experiment was conducted with 20 repayments using a real Paillier operation with reduced parameters: the horizontal axis represents the number of homomorphic accumulations, the left vertical axis represents the plaintext of the cumulative repayment amount decrypted by the funding system, and the right vertical axis represents the normalized ciphertext value of the cumulative repayment ciphertext field. The solid step curve rises precisely and monotonically with each accumulation and eventually touches the horizontal reference line corresponding to the total amount of financing due, indicating that the modular multiplication operation on the ciphertext field is strictly equivalent to the addition of amounts on the plaintext field; the dashed diamond sequence randomly walks within the value range of 0 to 1, and its correlation with the repayment progress is negligible. Each ledger node in the consortium blockchain network only needs to hold the ciphertext to complete the on-chain registration of the repayment progress, and the amount information remains closed to on-chain observers.

[0056] The change management during the lock-up period addresses another practical issue: financing applicants need to change their repayment account due to adjustments in bank cooperation. The repayment account change request is initiated by the financing applicant for financing contract number FC20250612000881, submitted to the account lock-up smart contract via the e-commerce platform. The account lock-up smart contract first reads the lock status field, confirms that a value of 1 represents the locked state, assigns a change request number CHG20250801000012 to the change request, registers the change request and its number as pending confirmation, and pushes a confirmation request to the funding party's system. When a new change request arrives under the same financing contract number, the account lock-up smart contract registers it in a queue according to the submission order, allowing it to enter the pending confirmation state sequentially after the earlier change requests have been processed. The advantage of serialization lies in the uniqueness of the state machine trajectory: when two change requests are confirmed in an interleaved manner, the final content of the voucher depends on the accidental order in which the messages arrive. The queuing mechanism converges concurrency into a single, first-come-first-served sequence. At any given time, there is at most one change request awaiting confirmation on the chain, making the evolution path of the voucher state completely predictable. During the pending confirmation period, the payment module continues to perform payment verification based on the currently registered account summary in the payment account lock voucher. Before the change takes effect, the original account remains a valid payment path, and normal payments continue as usual, thus avoiding the cost of business shutdowns.

[0057] Upon receiving the confirmation request, the funding party's system initiates verification within 24 hours, completed by two reviewers. The verification focuses on ensuring the changed account is a regulated account approved by the funding party (account number 6228480402564890026). This continued regulatory oversight ensures the same level of fund control after the account change. After successful verification, the funding party's system regenerates a 128-bit account digest salt value. Using the financing contract number, the regenerated account digest salt value, and the changed account string as input, the system calculates the changed account digest using the same concatenation order and collision-resistant hashing algorithm as when the document was created. The use of a new salt value serves two purposes: the account digest is updated along with the salt value, and the original and changed account digests are independent on-chain, keeping the account change trajectory closed to on-chain observers; if the original account digest salt value was previously exposed, its impact ends with the salt change, ensuring the digest system returns to a completely new starting point with each change. After the change, the plaintext of the account is stored locally in controlled storage by the funding system and the integrated business and finance system. Only the digest and salt value circulate on the blockchain. As an optional implementation, in a simplified scenario, the original account digest and salt value can be used, only the account string is replaced and the digest is recalculated. This approach has lower implementation costs and correspondingly reduced privacy protection. In engineering, the choice is made based on risk preference.

[0058] The signature confirmation step is the final control before the change takes effect. The funding system concatenates the financing contract number, change application number, original account summary, new account summary, regenerated account summary salt value, and change timestamp into the data to be signed. The change timestamp is a Unix timestamp in milliseconds, 1754006400000. Then, it uses the signature private key within the hardware security module to sign the data to be signed, generating a signature confirmation and submitting it to the account locking smart contract. The account locking smart contract uses the verification public key within the repayment account locking certificate to verify the signature confirmation, comparing the change application number in the signature confirmation with the change application number registered in the pending confirmation status. Only after both verifications pass will the update be executed. Including the change application number in the data to be signed addresses message replay: if a signature confirmation message from a previous change is intercepted and re-delivered, the number comparison step will immediately identify the misalignment between the old and new applications, rendering the old signature completely invalid for the new application. Each signature confirmation forms a one-time, one-key binding with each change application. After successful verification, the account locking smart contract updates the repayment account locking certificate with a newly generated account summary salt value and the account summary of the changed account. The update event is then pushed to the integrated business and finance system, and the old summary in the list of controlled receiving accounts is replaced with the new summary. From the time the update is recorded, the payment module will retrieve the new salt value and new summary when recalculating the summary to be verified. Subsequent funds will naturally flow to the regulatory account corresponding to the changed account. The change of the repayment account takes effect simultaneously on the ledgers of the three accounting nodes, and the three parties' understanding of the locking relationship is always recorded on the same chain.

[0059] At this point, the performance documents are nested hierarchically along the content identifiers to fill the performance record chain, the payment amount is accumulated in encrypted form, the account changes are completed in an orderly manner within the signature gate, the vouchers and the chain together record the entire status of the performance period, and all the inputs required for settlement determination are ready.

[0060] After each payment is received during the performance period, the process concludes on the funding side: determining when the financing has reached the settlement conditions, using cryptographic evidence to drive on-chain unlocking, and then sealing the entire performance process as an auditable closed-loop evidence summary. Step 3 revolves around these three things.

[0061] The settlement determination is triggered by an on-chain event mechanism. Each time the account-locked smart contract completes homomorphic accumulation and writes back the accumulated repayment encrypted field, it broadcasts an update event for the accumulated repayment encrypted field to the consortium blockchain network. The event payload carries the financing contract number FC20250612000881 and the block height of the latest block. The delay from block creation to delivery to the subscriber is less than one second. The funding system is permanently subscribed to these events. Upon receiving an event, it reads the current encrypted field from the accumulated repayment encrypted field from the account-locked smart contract and sends it to the local hardware security module for decryption. By replacing manual audits with event-driven mechanisms, the settlement determination is made immediately after the repayment block is created, reducing post-loan processing from a daily reconciliation cycle to a second-level response. As an optional implementation, the funding system can also use timed polling, reading the accumulated repayment encrypted field every 5 minutes. The polling method serves as a fallback path in case of event channel failure. The two triggering methods can be used in parallel for redundancy.

[0062] Decryption is performed within the hardware security module; Paillier's private key remains within the hardware boundaries throughout the process. Decryption follows... Execution, in the formula To decrypt the plaintext of the cumulative repayment amount, The current ciphertext in the cumulative repayment ciphertext field. For Paillier's private key parameters, take the least common multiple of two large prime numbers minus 1. The modulus in the Paillier public key. For modulus The square of, This represents the modulo operation. for In The multiplicative inverse of the remainder of the modulus is the multiplicative inverse of the matrix. The multiplicative inverse refers to the multiplicative inverse of the matrix. Multiplication modulus The value of remainder 1; As an auxiliary function, it is defined as follows: In the formula The intermediate value to be processed. express Subtracting 1, the auxiliary function maps the result of the modular exponentiation back to the value range of the plaintext. Generators take... The construction makes the above equation directly true, where For the generator in the Paillier public key, the main overhead of decryption is concentrated in In this modular exponentiation operation, the single decryption time within the hardware security module under a 2048-bit modulus is less than 50 milliseconds, and the burden on the timeliness of post-loan processing is negligible. The plaintext of the decrypted cumulative repayment amount is compared with the total amount of financing due (104,000,000 points) locally in the funding party's system: when the plaintext is lower than the total amount of financing due, the funding party's system records the current repayment progress and continues to wait for subsequent update events; after the second repayment is recorded on September 10, 2025, the plaintext of the decrypted cumulative repayment amount reaches 104,000,000 points, which is equal to the total amount of financing due, and the first condition for settlement is met.

[0063] Before issuing a settlement certificate, the funding party's system performs another cross-verification. The on-chain cumulative repayment ciphertext and the off-chain payment receipt document evolve along two separate paths. If a settlement certificate is issued solely based on the cumulative ciphertext result, the risk of a discrepancy between the ciphertext amount and the document amount always exists. To this end, the funding system retrieves each payment receipt file from the IPFS distributed storage network one by one, following the third content identifier corresponding to the payment link tag in the performance record chain. In this example, two receipts are retrieved, corresponding to payment transaction numbers PAY20250715000366 and PAY20250910000871, respectively. First, the receipt signature carried by each payment receipt file is verified to confirm that each payment has cryptographic endorsement from the bank. Then, the actual payment amounts recorded in each payment receipt file are summed. The sum of 52,000,000 points and 52,000,000 points equals 104,000,000 points, which matches the plaintext of the decrypted cumulative repayment amount bit by bit. The two independent paths converge on the same value. The on-chain ciphertext, off-chain documents, and bank receipts mutually verify each other. The settlement determination is based on the intersection of multiple pieces of evidence. Errors or alterations in a single data source will be revealed during the verification process. After verification, the funding party's system generates a settlement certificate, numbered SET20250910000045, containing the settlement time of 14:30 on September 10, 2025. The settlement certificate is then signed using a signing private key within the hardware security module, and submitted to the account-locking smart contract. As an optional implementation, the settlement certificate can also include the cumulative repayment amount in plaintext for easy archiving and retrieval later. Including plaintext means the total financing amount is disclosed to on-chain participants. The choice between including plaintext and omitting plaintext is based on a balance of confidentiality requirements among all parties.

[0064] On-chain unlocking is completed independently by the account-locking smart contract. The account-locking smart contract uses the verification public key within the repayment account lock certificate to verify the settlement certificate. Upon successful verification, the lock status field is changed from the locked state represented by value 1 to the settled state represented by value 2. Giving the unlocking key entirely to the funder's signature corresponds to the attribution of rights and responsibilities in the debt relationship: the lock protects the funder's repayment source, and the authority to unlock naturally belongs to the funder. The account-locking smart contract only recognizes cryptographic evidence; the ability of an e-commerce platform or an integrated business and finance system to unilaterally manipulate this state is zero. Forged settlement certificates are immediately exposed during the verification process. The state rewriting and subsequent actions are executed sequentially within the same transaction: the account-locking smart contract traverses the performance record chain in registration order, concatenates all registered content identifiers with their corresponding stage tags, and then performs a hash operation using the same collision-resistant hash algorithm as the account digest calculation to obtain a closed-loop record digest. The calculation of the closed-loop record digest is represented as follows: In the formula This is a closed-loop evidence summary. For the selected collision-resistant hash algorithm, For the first in the performance evidence storage chain The content identifier of the registration, For the first The corresponding step label for each registration item, subscript This is the registration sequence number, with values ​​ranging from 1 to... , In this example, the total number of entries in the performance record chain is [number]. Take 4, which corresponds to 1 shipment record, 1 invoice record, and 2 payment records. This indicates byte-level concatenation. This indicates that the intermediate items in the concatenation process are continued in the same way. The concatenation incorporates content identifiers and stage tags item by item in the registration order. Therefore, the summary is sensitive to both the content and order of the performance process: adding one item, deleting one item, or changing the order of two items will all change the overall summary. The closed-loop evidence summary is generated at the settlement moment, focusing on the static state of the linked list: the linked list continues to grow during the performance period, and any summary calculated midway is only a snapshot of a stage. The settlement state signifies that the evidence registration under the financing item has ended, and the summary calculated at this moment is the final fingerprint covering the entire process. The account-locking smart contract writes the closed-loop evidence summary along with the settlement certificate into the settlement record corresponding to the financing contract number. The closed-loop evidence summary is recorded in 64 hexadecimal characters. As an optional implementation, the closed-loop evidence digest can also adopt a Merkle tree organization: the hash of each registered content identifier and link label is used as the leaf node, and the root node is generated by pairwise hashing layer by layer to serve as the closed-loop evidence digest. The tree organization supports proving the ownership of a single piece of evidence with only a few layers of path nodes. The overhead of single-item verification is reduced from full splicing to logarithmic level, which is suitable for large-amount batch performance scenarios with hundreds of linked lists.

[0065] The on-chain event triggered by the settlement state block release simultaneously delivers the unlocking effect to both business systems. Upon detecting the on-chain event that the locked state field has been rewritten to the settlement state, the integrated business and finance system removes the account summary from the list of controlled receiving accounts. The receiving scenario for the escrow account reverts to the regular payment process, and the summary verification step is automatically bypassed as the list is removed. Upon detecting the same event, the e-commerce platform removes the financing lock mark from trade order PO20250612001, and subsequent operations on the order resume normal permissions. The unlocking and locking processes follow the same event chain. The effective time of locking and unlocking within all three systems is anchored to the on-chain block release moment. The local state of each party is based on the on-chain certificate, and the space for cross-system state drift is compressed to zero. After settlement, when the financing applicant initiates a change of repayment account application for financing contract number FC20250612000881, the account lock smart contract reads the lock status field. Under the settlement status represented by the value 2, the change registration is executed directly. The funder confirmation process exits along with the termination of the lock relationship. The account management right returns to the financing applicant, and the control intensity is strictly aligned with the financing life cycle.

[0066] like Figure 5As shown, the evolution of each state variable over time during the lock-up period is presented on the same timeline: from top to bottom, these are the values ​​of the lock-up state fields, the status of the controlled receiving account list, the version of the salt value and account summary in the repayment account lock-up certificate, the status of the repayment account change application, the payment exit summary verification event, and the plaintext of the cumulative repayment amount. The lock-up state takes effect on the day the certificate is created; on day 33, the first repayment is released after the summary matches version 1; on day 50, the change application enters the pending confirmation state; on day 51, after the signature confirmation verification is passed, the salt value and account summary in the certificate switch to version 2; on day 90, the second repayment is released according to the version 2 summary, the plaintext of the cumulative repayment amount reaches the total amount of financing due, the lock-up state field is rewritten from the locked state to the settled state, and the controlled receiving account list is simultaneously removed from the account summary. The switching of each state variable is anchored to the on-chain block creation time, and the three-party systems maintain a consistent understanding of the lock-up relationship throughout the entire lifecycle.

[0067] The closed-loop evidence summary provides an entry point for subsequent audits. During audit verification, the auditor starts with the closed-loop evidence summary in the settlement record, rereads all entries from the performance evidence chain, recalculates the summary using the same entry order and hash operation, and ensures that the recalculated result matches the closed-loop evidence summary in the settlement record bit by bit. This allows the auditor to determine that all evidence has been intact since the settlement time within the cost of one hash operation. If discrepancies occur, the discrepancies themselves are direct evidence of tampering or missing evidence. After confirming completeness, the auditor drilled down as needed: retrieving payment receipts along the third content marker and verifying the signatures against the actual payment amounts; retrieving invoice data files along the second content marker embedded in the payment receipts and verifying invoice number 24442000000123456789 and invoice date; then retrieving shipping documents along the first content marker embedded in the invoice data files and verifying tracking number SF1390276450876 and shipping date; the documents retrieved at each stage were also compared item by item with the corresponding stage tags in the performance record chain to confirm that the stage attribution and registration order matched. This step-by-step backtracking followed the reference chain embedded in the document files, moving from the funding end back to the trading end, exactly the opposite of the direction of the business transaction. This allowed the auditor to reconstruct the complete chain of delivery, invoicing, and payment from the starting point of payment receipts, thus completing the closed-loop verification of the entire order financing performance data. As an optional implementation method, routine annual audits can also adopt sampling backtracking, randomly selecting 5% of the total number of financing contracts to perform full-chain drill-down, while the overall comparison of closed-loop evidence summaries is performed on all financing contracts one by one. The combination of overall integrity and sampling depth verification achieves a balance between audit cost and coverage strength.

[0068] Thus, the repayment account under the financing has gone through the complete lifecycle of locking, verification, modification and unlocking. The performance process is recorded as a single on-chain record sealed with a closed-loop evidence summary. The cross-system order financing repayment account modification locking and performance data closed-loop management form a complete closed loop on the same consensus data of the three-party ledger.

[0069] This invention is not limited to the specific embodiments described above. The invention extends to any new feature or combination disclosed in this specification, as well as any new method or process step or combination disclosed herein.

Claims

1. A method for cross-system implementation of order financing and repayment account change locking and performance data closed-loop management, characterized in that, Includes the following steps: Step 1: Connect the e-commerce platform, the integrated business and finance system, and the funding party system as accounting nodes to the consortium blockchain network with deployed account locking smart contracts; After the funding party system approves the order financing application, it determines the total amount of financing to be repaid and the designated repayment account. Based on the account string of the designated repayment account, it performs a hash operation to obtain the account digest. The account locking smart contract then creates a repayment account locking certificate that includes the account digest and a locking status field with the value of the locked state. Step 2: Each accounting node uploads the performance documentation to the distributed storage network and writes the obtained content identifier and corresponding stage tag into the performance storage chain maintained by the account locking smart contract. The subsequent stage documentation embeds the content identifier of the previous stage, forming a closed loop of performance data. When the integrated business and finance system initiates a payment, it performs the same hash operation on the payee account in the payment instruction to obtain the digest to be verified. The payment instruction is released when the digest to be verified is consistent with the account digest and the lock status field is in the locked state. After payment, the actual payment amount is homomorphically encrypted into a ciphertext of the return amount, and submitted to the account lock smart contract for homomorphic accumulation into the cumulative return ciphertext field. During the financing period, if a change of repayment account is requested, the repayment account lock certificate will be updated with the account summary of the changed account after the signature confirmation verification of the signature returned by the funding party system is passed by the account lock smart contract. Step 3: The funding party system decrypts the encrypted field of cumulative repayments. When the plaintext of the cumulative repayment amount reaches the total amount of financing due, it submits a signed settlement certificate to the account-locked smart contract. After the account-locked smart contract verifies the signature, it changes the lock status field from locked to settled.

2. The method according to claim 1, characterized in that, Homomorphic encryption and decryption are implemented using the Paillier algorithm. The funding system generates a Paillier public key and a Paillier private key. The Paillier private key is stored locally on the funding system, while the Paillier public key is published to the consortium blockchain network along with the repayment account locking certificate. Encryption follows... Execution, in which It is a ciphertext. The amount to be encrypted is in plaintext. and The generator and modulus in the Paillier public key. The pair is selected independently for each encryption. Coprime random numbers; the funding system will If the value is 0, encryption is performed to generate the initial ciphertext. The account-locking smart contract writes the initial ciphertext into the cumulative repayment ciphertext field. Homomorphic accumulation is a modular operation of ciphertext multiplication. ,in The current ciphertext in the cumulative repayment ciphertext field. The amount to be refunded is encrypted. To write back the new ciphertext of the cumulative repayment ciphertext field, based on the Paillier additive homomorphic property, The plaintext obtained by decrypting with Paillier's private key is equal to and The sum of the corresponding plaintext amounts; the actual payment amount is expressed as a positive integer in the smallest monetary unit, and the sum of the total amount of financing due and the total amount of actual payments is less than the modulus. .

3. The method according to claim 1, characterized in that, The funding system assigns a financing contract number to each approved order financing application. For this contract number, it generates a random account digest salt value. The financing contract number, account digest salt value, and the account number string of the designated repayment account are concatenated. A collision-resistant hash algorithm, uniformly agreed upon by the consortium blockchain network, is then used to perform a hash operation to obtain the account digest. The account digest salt value is written to the repayment account lock certificate. The integrated business and finance system synchronizes the repayment account lock certificate from the consortium blockchain network and registers the account digest in the controlled collection account list bound to the financing contract number within the payment module. The payment module is deployed in the business and finance integration system. Within the integrated financial system, when the payment module initiates a payment, it concatenates the financing contract number, the account summary salt value in the repayment account lock certificate, and the receiving account in the payment instruction in the same order, and then performs a hash operation to obtain the digest to be verified. If there is a difference between the digest to be verified and the account summary, the payment module transfers the payment instruction to the manual review queue and calls the account lock smart contract to write an early warning event record containing the financing contract number, payment serial number, and digest to be verified. After the integrated business and financial system detects an on-chain event where the lock status field is changed to the settlement status, it removes the account summary from the list of controlled receiving accounts.

4. The method according to claim 1, characterized in that, The distributed storage network is the IPFS distributed storage network. The content identifier is determined by the hash result corresponding to the content of the performance document under the preset content addressing rules of the IPFS distributed storage network. The performance document includes the shipping document, invoice data file, and payment receipt file. After a trade order is shipped, the e-commerce platform generates a shipping document. This document records the trade order number, tracking number, and shipping time. Upon uploading, it generates the first content identifier, which, along with the shipping stage tag, is written into the performance record chain. After the integrated business and finance system issues an invoice, it generates an invoice data file. This file records the invoice number and invoicing time. The first content identifier is embedded within the invoice data file, and upon uploading, it generates the second content identifier. This second content identifier, along with the invoicing stage tag, is written into the performance record chain. After payment is completed, the integrated business and finance system generates a payment receipt. The second content identifier is embedded within the payment receipt, and upon uploading, it generates the third content identifier corresponding to the payment serial number. This third content identifier, along with the payment stage tag, is written into the performance record chain.

5. The method according to claim 4, characterized in that, The account-locked smart contract pre-registers the node certificates of three accounting nodes and registers the mapping relationship between the delivery stage label and the e-commerce platform, the invoicing stage label and the payment stage label and the submission entity of the integrated business and finance system. Before writing the content identifier and stage label into the performance storage chain, the account-locked smart contract verifies that the identity of the submitter's accounting node is consistent with the submission entity preset by the stage label based on the mapping relationship between the node certificate and the submission entity.

6. The method according to claim 4, characterized in that, After the payment instruction is released, the integrated business and finance system will pay the funds to the designated collection account through the bank-enterprise direct connection interface and receive the payment receipt data returned by the bank-enterprise direct connection interface; The payment receipt document is generated based on the payment receipt data and records the payment serial number, payment time, actual payment amount and the receipt signature returned by the bank-enterprise direct connection interface; The integrated business and finance system submits the encrypted payment amount, payment serial number, third content identifier, and payment stage tag to the account-locking smart contract. The encrypted payment amount is then linked to the payment receipt document for evidence storage.

7. The method according to claim 6, characterized in that, The account-locked smart contract concatenates the trade order number and payment transaction number and performs a hash operation to obtain a unique payment transaction identifier. When the unique payment transaction identifier is registered for the first time in the payment transaction registration table maintained by the account-locked smart contract, the account-locked smart contract binds the unique payment transaction identifier with the third content identifier and writes it into the payment transaction registration table, and performs homomorphic accumulation so that the actual payment amount of each payment is accumulated exactly once.

8. The method according to claim 3, characterized in that, The designated repayment account is a supervisory account opened by the funding party system. The funding party system pre-generates a signature private key and a verification public key. The signature private key is stored locally within the funding party system, and the verification public key is written into the repayment account lock certificate. The repayment account change application is initiated by the financing applicant for the financing contract number and submitted to the account lock smart contract via the e-commerce platform. When the lock status field is locked, the account lock smart contract assigns a change application number to the change application, registers the change application and change application number as pending confirmation, and pushes a confirmation request to the funding party system. Subsequent change applications submitted under the same financing contract number are registered in a queue and processed sequentially according to the submission order. During the pending confirmation period, the payment module... The payment verification continues based on the currently registered account summary in the repayment account lock certificate. After the funding system verifies that the changed account is a regulated account, it regenerates the account summary salt value. Using the financing contract number, the regenerated account summary salt value, and the account string of the changed account as input, it calculates the account summary of the changed account using the same concatenation order and anti-collision hash algorithm. The plaintext of the changed account is stored locally by the funding system and the integrated business and finance system. The funding system concatenates the financing contract number, change application number, original account summary, changed account summary, regenerated account summary salt value, and change timestamp into data to be signed, and uses the signing private key to generate a signature confirmation. The account locking smart contract uses the signature verification public key to confirm that the signature verification is successful. After confirming that the change application number in the signature verification is consistent with the change application number registered in the pending confirmation status, the contract updates the repayment account locking certificate with the regenerated account digest salt value and the account digest of the changed account, and pushes the update event to the business and finance integrated system to refresh the list of controlled collection accounts. When the lock status field is in the settlement state, the account locking smart contract directly executes the change registration for the repayment account change application.

9. The method according to claim 6, characterized in that, When the funding system detects an update event in the cumulative repayment encrypted field, it reads the current encrypted text in the cumulative repayment encrypted field and decrypts it. When the cumulative repayment amount in plaintext reaches the total amount due for financing, the funding system reads the payment receipt files pointed to by the third content identifiers corresponding to the payment stage tags in the performance record chain. After comparing the sum of the actual payment amounts recorded in each payment receipt file with the cumulative repayment amount in plaintext, it generates a settlement certificate containing the settlement time. After the account-locked smart contract verifies the settlement certificate, it concatenates all the content identifiers registered in the performance record chain with the corresponding stage tags in the registration order, performs a hash operation to obtain a closed-loop evidence digest, and writes the closed-loop evidence digest along with the settlement certificate into the settlement record.

10. The method according to claim 9, characterized in that, The e-commerce platform forwards the order financing application submitted by the financing applicant based on the trade order to the funding party's system, adds a financing lock mark to the trade order, and removes the financing lock mark after listening to the on-chain event that the lock status field is rewritten to the settlement status. Both shipment and payment are executed for trade orders with financing lock marks. During the audit and verification process, the closed-loop evidence summary in the settlement record is used as the entry point. The summary is recalculated using the same registration order and hash operation and compared with the closed-loop evidence summary. Then, the process is traced back step by step along the third content identifier, the second content identifier, and the first content identifier to each payment receipt file, invoice data file, and delivery document file in the IPFS distributed storage network. The data is then compared with the tags of each link in the performance evidence chain to complete the closed-loop verification of the performance data of the entire order financing process.

Images