Method for mutually transmitting flow between banks

Abstract

The invention discloses a method for mutually transmitting a flow between banks, which comprises the following steps that: a customer applies for a flow to a bank A of a flow sender, and the bank A generates an XML (Extensible Markup Language) document according to a preset format; after the XML document is generated, the bank A adopts a Hash algorithm to encrypt the document; transmitting the Hash value and sending the flow file: after the Hash value of the XML file is correctly calculated and linked, the bank A transmits the Hash value to a preset auditing system and sends the flow file to a flow receiving line; before or after the bank A sends the flow file, the bank A uses a private key of the bank A to digitally sign the hash value; performing hash value comparison and digital signature verification; and after the bank B of the flow receiver receives the flow file and the hash value, the operation is verified to ensure the security and credibility of the transaction, so that the method has the technical characteristics of ensuring the security and credibility of the transaction, providing powerful guarantee for healthy and stable development of financial services and the like.

Description

Technical Field

[0001] The present invention relates to a method for mutually transmitting bank statements, and more specifically, to a method for mutually transmitting bank statements between banks, belonging to the field of information transmission. Background Art

[0002] With the rapid development of fintech, the transaction frequency and transaction amount between banks have increased significantly. Against this background, ensuring the security and accuracy of transaction information has become an important challenge faced by financial institutions. Traditional methods for transmitting bank transaction statements between banks often rely on centralized systems, which may face performance bottlenecks in high-volume transaction environments and are easily targeted by attacks.

[0003] In the current financial environment, security not only means protecting data from unauthorized access, but also includes ensuring the integrity and non-repudiation of data during transmission. However, existing solutions often struggle to balance security and efficiency, resulting in risks of information leakage and transaction errors. In addition, the complexity of cross-bank transactions also makes information sharing more difficult and increases the vulnerability of the system.

[0004] Therefore, it is particularly important to develop a new method for securely transmitting bank statements to enhance the security of transactions between banks, improve data transmission efficiency, and reduce transaction risks. Such a method should not only effectively prevent data leakage, but also ensure the authenticity and consistency of transaction information, providing a more secure and reliable transaction environment for financial institutions. Summary of the Invention

[0005] To solve the above problems in the prior art, the present invention provides a method for mutually transmitting bank statements between banks, which has technical features such as ensuring the security and credibility of transactions and providing a strong guarantee for the healthy and stable development of financial services.

[0006] To achieve the above object, the present invention is realized through the following technical solutions:

[0007] A method for mutually transmitting bank statements between banks according to the present invention includes the following steps:

[0008] Step 1: A customer applies for a bank statement to Bank A, the sender of the bank statement, and Bank A generates an XML document according to a preset format;

[0009] Step 2: Calculating the hash value of the XML file and uploading it to the blockchain: After generating the XML document, in order to ensure the integrity and security of the file, Bank A encrypts the file using a hash algorithm;

[0010] Step 3. Hash Value Transmission and Transaction File Sending: After the hash value of the XML file is correctly calculated and uploaded to the blockchain, Bank A transmits the hash value to a preset audit system (third-party credit enhancement platform) and sends the transaction file to the receiving bank of the transaction file.

[0011] Step 4. Digital Signature Generation and Authenticity Assurance: Before or after sending the transaction file, Bank A (i.e., the provider of the transaction file) uses its own private key to digitally sign the hash value.

[0012] Step 5. Hash Value Comparison and Digital Signature Verification: After receiving the transaction file and the hash value, Bank B (i.e., the receiving bank of the transaction file) at the receiving end of the transaction file performs verification operations to ensure the security and credibility of the transaction.

[0013] Preferably, Step 1 specifically includes: In the field of financial services, transaction records are important bases for evaluating the credit status of individuals or enterprises and conducting financial audits. When a customer needs to obtain the transaction records of their bank account within a certain period of time, they first need to initiate an application to the provider of the transaction file (such as China Construction Bank, Industrial and Commercial Bank of China, etc.). This step usually includes the following key links:

[0014] 1) Filling in application information: The customer provides application information (which needs to be filled in through channels such as the counter, online banking, mobile banking, or telephone banking, and the detailed transaction record application information), and the application information includes: applicant's name, ID number, bank card number, required transaction record time period (start and end time), and application purpose.

[0015] 2) Identity verification and authorization: After submitting the application information, the customer needs to undergo identity verification, which is verified by entering the reserved mobile verification code, password, or through biometric technologies (such as fingerprint, facial recognition). After successful verification, the customer performs an authorization operation, clearly agreeing to Bank A to query and provide their account transaction records.

[0016] 3) Request transmission and processing: After the customer completes information filling, identity verification, and authorization, the application request will be automatically transmitted to the bank system (backend service system) of Bank A (such as China Construction Bank), the bank that generates the transaction file. In the bank system, Bank A queries the corresponding transaction data from the database through identity verification and data matching based on the information provided by the customer.

[0017] 4) Generating an XML document: After querying the transaction data, Bank A generates a document containing detailed transaction records in the agreed-upon XML format; the XML document will serve as the carrier of the transaction record information required by the customer for subsequent transmission and processing.

[0018] Preferably, Step 2 specifically includes:

[0019] 1) Open the XML file path: The banking system of Bank A first opens the path of the XML file in binary form; implemented using the Java programming language; because Java provides powerful file handling capabilities and rich encryption libraries;

[0020] 2) Create an SHA-256 instance: In a Java program, the bank uses the MessageDigest class to create an instance of the SHA-256 hashing algorithm; SHA-256 is a widely used secure hashing algorithm that can generate a fixed-length (256-bit) hash value, which is extremely sensitive to any minor changes in the input data;

[0021] 3) Calculate the hash value: Whenever a new XML file is generated, the banking system of Bank A reads the file content and passes it to the SHA-256 instance for calculation. After the calculation is completed, the SHA-256 instance returns a unique hash value as the digital fingerprint of the file;

[0022] 4) The process of uploading to the chain: The process of associating the generated hash value with the XML file is called uploading to the chain. Although the term "uploading to the chain" here does not directly involve blockchain technology (blockchain is a decentralized distributed ledger technology), this term vividly describes the process of binding the file content with the hash value; In this way, the bank can ensure the integrity and security of the file and prevent the file from being tampered with or damaged during transmission;

[0023] 5) Storage and backup: After calculating the hash value, the bank stores the hash value and the XML file together and makes a backup to prevent data loss. The hash value can be stored in a database or other secure storage systems for subsequent comparison and verification

[0024] Preferably, step 3 specifically includes:

[0025] 1) Select a preset audit system (third-party credit enhancement platform): To ensure the security and credibility of transactions, Bank A selects a preset audit system (third-party credit enhancement platform) with credibility and authority. This platform can be a government institution, industry association, or financial institution with a high reputation, etc. It is preferred to select the National Financial Regulatory Administration (hereinafter referred to as the "Financial Regulatory Bureau") as the preset audit system (third-party credit enhancement platform), the Banking and Insurance Regulatory Bureau's Golden Comprehensive Chain;

[0026] 2) Transmit the hash value: Bank A transmits the calculated hash value to the preset audit system (Financial Regulatory Bureau) through a secure channel (such as HTTPS, SSL / TLS, etc.); During the transmission process, Bank A takes security measures (such as encryption, signature, etc.) to ensure the security and integrity of the hash value;

[0027] 3) Sending the transaction file: Simultaneously with or after transmitting the hash value, Bank A will send the generated XML transaction file to the receiving bank, Bank B (such as another bank), via a secure channel. Security measures will also be taken during the sending process to ensure the security and integrity of the file;

[0028] 4) Recording and tracking: Bank A will record the sending time of the hash value and the transaction file, as well as the recipient information, and provide tracking for customers or recipients to query the transaction status.

[0029] Preferably, step 4 specifically includes: This step is crucial for ensuring the authenticity of the information and preventing the sender from denying that it has sent the request.

[0030] 1) Selecting the private key: The sender bank, Bank A, will select a private key for digital signature from the private key library. This private key is unique and confidential;

[0031] 2) Generating the digital signature: Bank A encrypts the hash value using the selected private key to generate a digital signature. This digital signature corresponds to the hash value and can only be verified for its validity using the corresponding public key;

[0032] 3) Attaching the digital signature: After generating the digital signature, Bank A attaches it to the hash value or the transaction file and sends them together to the receiving bank, Bank B, or the preset audit system (third-party credit enhancement platform) (such as the Banking and Insurance Regulatory Bureau);

[0033] 4) Authenticity guarantee: The existence of the digital signature ensures the authenticity and integrity of the information. If the receiving bank, Bank B, or the preset audit system (third-party credit enhancement platform) can successfully verify the validity of the digital signature using the corresponding public key, it can be certain that the hash value or the transaction file has not been tampered with or damaged during transmission. At the same time, since the digital signature is generated by the sender using its own private key, the sender cannot deny that it has sent the request.

[0034] Preferably, step 5 specifically includes:

[0035] 1) Generating the received hash value: Bank B will calculate its own hash value based on the content of the received transaction file. This hash value should be the same as the hash value transmitted by the sender to the preset audit system (third-party credit enhancement platform) (such as the Banking and Insurance Regulatory Bureau) (if the file has not been tampered with or damaged during transmission);

[0036] 2) Sending the hash value to the preset audit system: Bank B sends the calculated hash value to the preset audit system via a secure channel for comparison; Necessary security measures will also be taken during the sending process to ensure the security and integrity of the hash value;

[0037] 3) Hash value comparison: The preset audit system will receive the hash value sent by the receiving party and the hash value previously transmitted by the sending party. Then, the preset audit system will compare whether these two hash values are the same. If they are the same, it indicates that the transaction file has not been tampered with or damaged during the transmission process. If they are different, it indicates that there may be security issues or fraud;

[0038] 4) Feedback of comparison result: The preset audit system will feedback the comparison result to the receiving bank B (i.e., the transaction receiving bank); if the comparison is successful (i.e., the two hash values are the same), the receiving bank B is convinced that the received transaction file is authentic and valid. If the comparison fails (i.e., the two hash values are different), the receiving bank B needs to further confirm security issues or fraud;

[0039] 5) Digital signature verification: In addition to hash value comparison, the receiving bank A also needs to verify the received digital signature, which is specifically achieved by decrypting the digital signature using the public key of the sending party; if the decrypted hash value is the same as the hash value calculated by the receiving party itself and the digital signature itself is also valid, then it can be convinced that the sending party has indeed sent the request and the request content has not been tampered with;

[0040] 6) Processing and feedback: Once the hash value comparison and digital signature verification are completed, the receiving bank B can process the transaction file according to the verification results. If the verification is successful, the receiving bank B can use it for subsequent financial audits and credit evaluations. If the verification fails, the receiving bank B needs to promptly feedback the processing results to the sending bank A and the preset audit system (third-party credit enhancement platform) (such as the banking regulatory bureau).

[0041] Preferably, the transaction sender can also be any one or more of Bank B, Bank C, and Bank D, and the transaction receiver can be one or more of Bank A, Bank C, and Bank D; the transaction sender and the transaction receiver cannot be the same bank. As shown in the figure, the mutual transmission of transactions can be simultaneously achieved among several banks.

[0042] Beneficial effects: The present invention uses the hash algorithm to perform encrypted hash processing on the transmitted transaction flow, ensuring the integrity of data during the transmission process. The receiving party can verify whether the data has been tampered with by comparing the received data hash value with the hash value provided by the sending party, thereby effectively preventing data damage and malicious tampering. The asymmetric encryption algorithm uses a pair of keys (public key and private key) for data encryption and decryption. Even in an insecure network environment, transaction data can be securely transmitted, and only the receiving party holding the corresponding private key can decrypt the received data, greatly reducing the risk of illegal access to data. Description of the Drawings

[0043] Figure 1This is the principle block diagram of the present invention.

[0044] Figure 2 This is the schematic flow diagram of the present invention. Detailed implementation manners

[0045] The present invention will be further described below in conjunction with the accompanying drawings of the specification, but the present invention is not limited to the following embodiments.

[0046] As Figure 1-2 shown is a specific embodiment of a method for inter-bank transaction record transfer. This embodiment is a method for inter-bank transaction record transfer, and the method includes the following steps:

[0047] Step 1: The customer applies for transaction records to Bank A, the sender of the transaction records, and Bank A generates an XML document according to a preset format;

[0048] Step 2: Calculation of the hash value of the XML file and uploading to the blockchain: After generating the XML document, in order to ensure the integrity and security of the file, Bank A uses a hash algorithm to encrypt the file;

[0049] Step 3: Transmission of the hash value and sending of the transaction record file: After the hash value of the XML file is correctly calculated and uploaded to the blockchain, Bank A transmits the hash value to a preset audit system (third-party credit enhancement platform), and sends the transaction record file to the receiving bank of the transaction records;

[0050] Step 4: Generation of digital signature and guarantee of authenticity: Before or after sending the transaction record file, Bank A (i.e., the provider of the transaction records) uses its own private key to digitally sign the hash value;

[0051] Step 5: Comparison of the hash value and verification of the digital signature; After the receiving bank of the transaction records (i.e., Bank B) receives the transaction record file and the hash value, verification operations are performed to ensure the security and credibility of the transaction.

[0052] In the above steps, the sender of the transaction records can also be any one or more of Bank B, Bank C, and Bank D, and the receiver of the transaction records can be one or more of Bank A, Bank C, and Bank D; the sender and the receiver of the transaction records cannot be the same bank. As shown in the figure, the transfer of transaction records can be realized simultaneously among several banks.

[0053] In a preferred embodiment, Step 1 specifically includes: In the field of financial services, transaction records are an important basis for evaluating the credit status of individuals or enterprises and conducting financial audits. When a customer needs to obtain the transaction records of their bank account within a certain period of time, they first need to initiate an application to the provider of the transaction records (such as China Construction Bank, Industrial and Commercial Bank of China, etc.). This step usually includes the following key links:

[0054] 1) Fill in the application information: The customer provides the application information (which needs to fill in the detailed transaction application information through channels such as the counter, online banking, mobile banking, or telephone banking). The application information includes: applicant's name, ID number, bank card number, the required transaction time period (start and end times), and the application purpose;

[0055] 2) Identity verification and authorization: After submitting the application information, the customer needs to undergo identity verification. This is done by entering the reserved mobile verification code, password, or through biometric technologies (such as fingerprint, facial recognition) for verification. After successful verification, the customer performs an authorization operation, clearly agreeing to Bank A to query and provide their account transaction records;

[0056] 3) Request transmission and processing: After the customer completes information filling, identity verification, and authorization, the application request will be automatically transmitted to the banking system (backend service system) of Bank A (such as China Construction Bank), the bank that generates the transactions. In the banking system, Bank A queries the corresponding transaction data from the database based on the information provided by the customer through identity verification and data matching;

[0057] 4) Generate an XML document: After querying the transaction data, Bank A generates a document containing detailed transaction records in the agreed XML format; the XML document will serve as the carrier of the transaction information required by the customer for subsequent transmission and processing.

[0058] In a preferred embodiment, step 2 specifically includes:

[0059] 1) Open the XML file path: The banking system of Bank A first opens the path of the XML file in binary form; implemented using the Java programming language; because Java provides powerful file handling capabilities and rich encryption libraries;

[0060] 2) Create an SHA-256 instance: In the Java program, the bank uses the MessageDigest class to create an instance of the SHA-256 hashing algorithm; SHA-256 is a widely used secure hashing algorithm that can generate a hash value of a fixed length (256 bits), which is extremely sensitive to any minor changes in the input data;

[0061] 3) Calculate the hash value: Each time a new XML file is generated, the banking system of Bank A reads the file content and passes it to the SHA-256 instance for calculation. After the calculation is completed, the SHA-256 instance returns a unique hash value as the digital fingerprint of the file;

[0062] 4) Process of uploading to the chain: The process of associating the generated hash value with the XML file is called uploading to the chain. Although the "uploading to the chain" here does not directly involve blockchain technology (blockchain is a decentralized distributed ledger technology), this term vividly describes the process of binding the file content with the hash value. In this way, the bank can ensure the integrity and security of the file and prevent the file from being tampered with or damaged during transmission.

[0063] 5) Storage and backup: After calculating the hash value, the bank will store the hash value and the XML file together and make a backup to prevent data loss. The hash value can be stored in a database or other secure storage systems for subsequent comparison and verification.

[0064] In a preferred embodiment, step 3 specifically includes:

[0065] 1) Select a preset audit system (third-party credit enhancement platform): To ensure the security and credibility of the transaction, Bank A selects a preset audit system (third-party credit enhancement platform) with credibility and authority. This platform can be a government institution, industry association, or financial institution with a high reputation, etc. It is preferred to select the National Financial Regulatory Administration (hereinafter referred to as the "Financial Regulatory Bureau") as the preset audit system (third-party credit enhancement platform), the Banking and Insurance Regulatory Commission's Gold Comprehensive Chain.

[0066] 2) Transmit the hash value: Bank A transmits the calculated hash value to the preset audit system (Financial Regulatory Bureau) through a secure channel (such as HTTPS, SSL / TLS, etc.). During the transmission process, Bank A takes security measures (such as encryption, signature, etc.) to ensure the security and integrity of the hash value.

[0067] 3) Send the transaction file: At the same time as or after transmitting the hash value, Bank A will send the generated XML transaction file to Bank B, the receiving bank of the transaction (such as another bank), through a secure channel. Security measures will also be taken during the sending process to ensure the security and integrity of the file.

[0068] 4) Record and track: Bank A will record the sending time of the hash value and the transaction file, the receiving party information, and provide tracking for customers or the receiving party to query the transaction status.

[0069] In a preferred embodiment, step 4 specifically includes: This step is crucial for ensuring the authenticity of the information and preventing the sender from denying that it has sent the request.

[0070] 1) Select a private key: The sending bank of the transaction, Bank A, will select a private key for digital signature from the private key library. This private key is unique and confidential.

[0071] 2) Generate a digital signature: Bank A encrypts the hash value using the selected private key to generate a digital signature, which corresponds to the hash value and can only be verified for its validity using the corresponding public key;

[0072] 3) Attach the digital signature: After generating the digital signature, Bank A attaches it to the hash value or the transaction file and sends them together to the receiving Bank B or the preset audit system (third-party credit enhancement platform) (such as the Banking and Insurance Regulatory Bureau);

[0073] 4) Authenticity assurance: The existence of the digital signature ensures the authenticity and integrity of the information. If the receiving Bank B or the preset audit system (third-party credit enhancement platform) can successfully verify the validity of the digital signature using the corresponding public key, it can be convinced that the hash value or the transaction file has not been tampered with or damaged during the transmission. At the same time, since the digital signature is generated by the sender using its own private key, the sender cannot deny having sent the request.

[0074] Preferably, in one embodiment, step 5 specifically includes:

[0075] 1) Generate a received hash value: Bank B calculates its own hash value based on the content of the received transaction file, which should be the same as the hash value transmitted by the sender to the preset audit system (third-party credit enhancement platform) (such as the Banking and Insurance Regulatory Bureau) (if the file has not been tampered with or damaged during the transmission);

[0076] 2) Send the hash value to the preset audit system: Bank B sends the calculated hash value to the preset audit system through a secure channel for comparison; necessary security measures will also be taken during the transmission to ensure the security and integrity of the hash value;

[0077] 3) Hash value comparison: The preset audit system will receive the hash value sent by the receiver and the hash value previously transmitted by the sender, and then the preset audit system will compare whether the two hash values are the same. If they are the same, it means that the transaction file has not been tampered with or damaged during the transmission; if they are different, it means that there may be security issues or fraud;

[0078] 4) Feedback the comparison result: The preset audit system will feedback the comparison result to the receiving Bank B (i.e., the transaction receiving bank); if the comparison is successful (i.e., the two hash values are the same), the receiving Bank B is convinced that the received transaction file is authentic and valid; if the comparison fails (i.e., the two hash values are different), the receiving Bank B needs to further confirm the security issues or fraud;

[0079] 5) Digital signature verification: In addition to hash value comparison, the receiving bank A also needs to verify the received digital signature, which is achieved by decrypting the digital signature using the sender's public key. If the decrypted hash value is consistent with the hash value calculated by the recipient, and the digital signature itself is valid, then it can be confirmed that the sender has indeed sent the request and the request content has not been tampered with.

[0080] 6) Processing and feedback: Once the hash value comparison and digital signature verification are completed, the receiving bank B can process the transaction file based on the verification results. If the verification is successful, the receiving bank B can use it for subsequent financial review and credit assessment; if the verification fails, the receiving bank B needs to promptly feedback the processing results to the sending bank A and the preset review system (third-party credit enhancement platform) (such as the Financial Regulatory Bureau).

[0081] The method of bank-to-bank transaction flow transmission recorded in this application not only involves multiple participants (including customers, transaction flow providing banks, transaction flow receiving banks and preset review systems (third-party credit enhancement platforms), etc., but also ensures the security and credibility of transactions through a variety of security technologies and means (such as hash algorithms, digital signatures, encryption technologies, etc.), providing strong guarantees for the healthy and stable development of financial services.

[0082] Finally, it should be noted that the present invention is not limited to the above embodiments, and there are many variations. All variations that can be directly derived or associated with the content disclosed by ordinary technicians in this field should be considered as the protection scope of the present invention.

Claims

1. A method for transmitting bank statements between banks, characterized in that The method comprises the following steps: Step 1: The customer applies for a bank statement from the bank A, which sends the bank statement. Bank A generates an XML document according to the preset format. Step 2: Calculate the hash value of the XML file and upload it to the blockchain: After generating the XML document, Bank A uses a hash algorithm to encrypt the file; Step 3: Hash value transmission and transaction file sending: After the hash value of the XML file is correctly calculated and uploaded to the chain, Bank A transmits the hash value to the preset review system and sends the transaction file to the transaction receiving bank; Step 4: Digital signature generation and authenticity assurance: Before or after Bank A sends the transaction file, Bank A uses its own private key to digitally sign the hash value; Step 5: Hash value comparison and digital signature verification: After the bank receiving the transaction, Bank B (i.e., the receiving bank), receives the transaction file and hash value, it verifies the operation to ensure the security and credibility of the transaction.

2. A method for transferring bank statements between banks according to claim 1, characterized in that: Step 1 specifically includes: 1) Fill in application information: The customer provides application information, including: applicant's name, ID number, bank card number, required transaction time period, and application purpose; 2) Identity verification and authorization: After submitting the application information, the customer needs to conduct identity verification by entering the reserved mobile phone verification code, password or through biometric technology. After the verification is passed, the customer performs the authorization operation and explicitly agrees that Bank A can query and provide its account transaction records; 3) Request transmission and processing: After the customer completes information filling, identity verification and authorization, the application request will be automatically transmitted to the bank system of Bank A where the transaction data is generated. In the bank system, Bank A will query the corresponding transaction data from the database based on the information provided by the customer, through identity verification and data matching; 4) Generate XML document: After querying the transaction data, Bank A generates a document containing detailed transaction records in accordance with the agreed format XML; the XML document will serve as the carrier of the transaction information required by the customer for subsequent transmission and processing.

3. A method for transmitting bank statements between banks according to claim 1 or 2, characterized in that: Step 2 specifically includes: 1) Open the XML file path: The banking system of Bank A first opens the XML file path in binary form; this is done using the Java programming language; 2) Create a SHA-256 instance: In the Java program, the bank will use the MessageDigest class to create an instance of the SHA-256 hash algorithm; 3) Calculate the hash value: Every time a new XML file is generated, the banking system of Bank A reads the file content and passes it to the SHA-256 instance for calculation. After the calculation is completed, the SHA-256 instance returns a unique hash value as the digital fingerprint of the file; 4) On-chain process: The process of associating the generated hash value with the XML file is called on-chain. By doing so, the bank can ensure the integrity and security of the file and prevent it from being tampered with or damaged during transmission. 5) Storage and backup: After calculating the hash value, the bank will store the hash value along with the XML file and back it up to prevent data loss.

4. A method for transferring bank statements between banks according to claim 3, characterized in that: Step 3 specifically includes: 1) Select a preset audit system: To ensure the security and credibility of the transaction, Bank A selects a preset audit system; 2) Transmitting hash value: Bank A transmits the calculated hash value to the preset audit system through a secure channel. During the transmission process, Bank A takes security measures to ensure the security and integrity of the hash value. 3) Sending transaction files: At the same time or after transmitting the hash value, Bank A will send the generated XML transaction file to the transaction receiving bank, Bank B, through a secure channel; 4) Recording and tracking: Bank A will record the sending time and recipient information of the hash value and transaction file, and provide tracking so that the customer or recipient can query the transaction status.

5. A method for transferring bank statements between banks according to claim 4, characterized in that: Step 4 specifically includes: 1) Select a private key: The bank A that sends the transaction will select a private key for digital signature from the private key library. This private key is unique and confidential. 2) Generate a digital signature: Bank A uses the selected private key to encrypt the hash value to generate a digital signature. This digital signature corresponds to the hash value and its validity can only be verified using the corresponding public key. 3) Attaching digital signature: After generating the digital signature, Bank A attaches it to the hash value or transaction file and sends it together to the recipient Bank B or the preset review system; 4) Authenticity guarantee: The existence of digital signature ensures the authenticity and integrity of the information. If the receiving bank B or the preset audit system can successfully verify the validity of the digital signature using the corresponding public key, it can be sure that the hash value or transaction file has not been tampered with or damaged during the transmission process.

6. A method for transferring bank statements between banks according to claim 5, characterized in that: Step 5 specifically includes: 1) Generate the received hash value: Bank B will calculate its own hash value based on the content of the received transaction file. This hash value should be the same as the hash value transmitted by the sender to the preset audit system; 2) Send the hash value to the preset audit system: Bank B sends the calculated hash value to the preset audit system through a secure channel for comparison; during the sending process, necessary security measures will also be taken to ensure the security and integrity of the hash value; 3) Hash value comparison: The preset audit system will receive the hash value sent by the receiver and the hash value previously transmitted by the sender, and then the preset audit system will compare whether the two hash values ​​are consistent. If they are consistent, it means that the transaction file has not been tampered with or damaged during the transmission process; if they are inconsistent, it means that there may be security issues or fraud; 4) Feedback of comparison results: The preset audit system will feedback the comparison results to the recipient bank B; if the comparison is successful, the recipient bank B is convinced that the received transaction file is authentic and valid; if the comparison fails, the recipient bank B needs to further confirm the security issue or fraudulent behavior; 5) Digital signature verification: In addition to hash value comparison, the receiving bank A also needs to verify the received digital signature, which is achieved by decrypting the digital signature using the sender's public key. If the decrypted hash value is consistent with the hash value calculated by the recipient, and the digital signature itself is valid, then it can be confirmed that the sender has indeed sent the request and the request content has not been tampered with. 6) Processing and feedback: Once the hash value comparison and digital signature verification are completed, the receiving bank B can process the transaction file based on the verification results. If the verification is successful, the receiving bank B can use it for subsequent financial review and credit assessment; if the verification fails, the receiving bank B needs to promptly feedback the processing results to the sending bank A and the preset review system.

7. The method for transferring bank statements between banks according to claim 1, characterized in that: The transaction sender may also be any one or more of Bank B, Bank C, and Bank D, and the transaction receiver may be one or more of Bank A, Bank C, and Bank D; the transaction sender and the transaction receiver cannot be the same bank.

Images