Financial reconciliation file processing method and system

Abstract

The invention discloses a financial reconciliation file processing method and system, and the method comprises the steps: adding a file identifier to a to-be-processed reconciliation file, and partitioning the to-be-processed reconciliation file according to a partitioning size determined by a network bandwidth and a network round-trip delay; generating metadata comprising a block identifier, a block index and an anti-replay token for each block, and performing encryption transmission; after transmission succeeds, block-level verification based on double hash values and field-level verification based on a state transition rule are carried out on the blocks; if the block-level verification is not passed, the abnormal blocks are retransmitted until the block-level verification is passed; when all the fields pass the verification, verifying the business logic, and generating a reconciliation report according to a file passing the verification; otherwise, error codes are generated for exception processing. Cooperative optimization of a transmission layer and a verification layer is realized in a heterogeneous financial system, and the contradiction between large file transmission efficiency and verification flexibility is solved through block-level real-time verification and dynamic rule loading.

Description

Technical Field

[0001] This invention relates to the field of reconciliation system technology, and in particular to a method and system for processing financial reconciliation documents. Background Technology

[0002] The statements in this section are merely background information related to the present invention and do not necessarily constitute prior art.

[0003] The following defects exist in the document processing of reconciliation systems in financial institutions: (1) File transfer layer: When traditional FTP / HTTP protocols transfer large files in a single thread, network fluctuations cause a transmission failure rate of >35%; and breakpoint resume requires maintaining TCP session state, resulting in server memory usage of over 60%.

[0004] (2) Data verification layer: Static verification rule updates require downtime maintenance, and error feedback is delayed by more than 30 seconds, affecting processing efficiency.

[0005] Existing technologies cannot simultaneously meet the requirements of stability and efficiency in large file transfer, dynamic adaptation and real-time effectiveness of verification rules, and immediacy of error detection and feedback. Summary of the Invention

[0006] To address the aforementioned issues, this invention proposes a financial reconciliation file processing method and system. This method achieves collaborative optimization between the transport layer and the verification layer in a heterogeneous financial system. By implementing block-level real-time verification and dynamic rule loading, it resolves the contradiction between large file transmission efficiency and verification flexibility.

[0007] To achieve the above objectives, the present invention adopts the following technical solution: In a first aspect, the present invention provides a method for processing financial reconciliation documents, comprising: After adding a file identifier to the reconciliation file to be processed, the reconciliation file to be processed is divided into blocks according to the block size determined by network bandwidth and network round-trip latency; After generating metadata for each block, including a block identifier, block index, and anti-replay token, the data is transmitted in encrypted form. After successful transmission, block-level verification based on double hash values ​​and field-level verification based on state transition rules are performed on the blocks. If the block-level validation fails, the abnormal block is retransmitted until the block-level validation passes. When all fields pass validation, the business logic validation is performed, and a reconciliation report is generated based on the validated file. Otherwise, an error code is generated for exception handling.

[0008] As an alternative implementation, the process of generating a file identifier includes: obtaining the institution code, current timestamp, and random number of the financial institution; concatenating them in the order of institution code, current timestamp, and random number; processing the concatenated data using a hash algorithm to generate a fixed-length file identifier; associating the file identifier with the reconciliation file to be processed; and writing it into the file metadata header.

[0009] As an alternative implementation, the block size is S = B*RTT / k; where B is the bandwidth; RTT is the round-trip time; and k is the congestion coefficient. The system monitors network fluctuations in real time. When the network fluctuations exceed a threshold, the block size is recalculated, and subsequent blocks are transmitted according to the new block size.

[0010] As an alternative implementation method, block-level verification includes: Calculate the SHA-256 digest and CRC32 checksum of the block, generate the block double hash value, and write the block double hash value into the block metadata header; Layered verification is performed based on the block double hash value, including: Transport layer verification: Calculate the CRC32 checksum of the received block and compare it with the CRC32 checksum in the block metadata header; Application layer verification: Calculate the SHA-256 digest of the received chunk content and compare it with the SHA-256 digest in the chunk metadata header; If any verification fails, the coordinates of the abnormal block are recorded, the differential update mechanism is triggered, and the abnormal block is retransmitted.

[0011] As an optional implementation method, the process of retransmitting abnormal blocks through a differential update mechanism specifically includes: Based on the file identifier, block index and field position, locate the data anomaly point, generate the retransmission identifier of the abnormal block, which includes the source file version number, the abnormal block index list and the data verification fingerprint; Request that abnormal data chunks be specified and that a version consistency flag be attached during transmission; Replace the corresponding block in the original file with the received abnormal block, and perform block-level hash verification and field-level CRC32 dual verification.

[0012] As an alternative implementation method, the field-level validation process includes: Read the content of the field to be verified and set the current state of the verification state machine to the initial state; Read each character in the field sequentially, and check whether the current character triggers a valid state transition according to the preset state transition rules, including the allowed character set and state transition conditions. If a valid transition is triggered, update the current state to the next state. If a valid transition is not triggered, mark the verification as failed and terminate the process. After the field content is read, check whether the current state belongs to the preset acceptance state set; if so, the field validation is considered successful; otherwise, the field validation is considered to have failed and exception handling is performed.

[0013] Secondly, the present invention provides a financial reconciliation document processing system, comprising: The chunking module is configured to add file identifiers to the reconciliation files to be processed, and then chunk the reconciliation files to be processed according to the chunk size determined by network bandwidth and network round-trip latency. The transmission module is configured to generate metadata for each chunk, including a chunk identifier, a chunk index, and a replay protection token, and then transmit it in encrypted form. The verification module is configured to perform block-level verification based on double hash values ​​and field-level verification based on state transition rules after successful transmission. The processing module is configured to retransmit the abnormal block if the block-level validation fails, until the block-level validation passes; when all fields pass validation, the business logic validation is performed, and a reconciliation report is generated based on the validated file; otherwise, an error code is generated for exception handling.

[0014] Thirdly, the present invention provides an electronic device including a memory and a processor, and computer instructions stored in the memory and running on the processor, wherein the computer instructions, when executed by the processor, perform the method described in the first aspect.

[0015] Fourthly, the present invention provides a computer-readable storage medium for storing computer instructions, which, when executed by a processor, perform the method described in the first aspect.

[0016] Fifthly, the present invention provides a computer program product, including a computer program that, when executed by a processor, implements the method described in the first aspect.

[0017] Compared with the prior art, the beneficial effects of the present invention are as follows: This invention proposes a method and system for processing financial reconciliation files. It employs a dynamic block-based strategy, a dual-hash verification mechanism, and indexed records. Through block-based upload and breakpoint resume mechanisms, it achieves efficient transmission of large files and rapid recovery from network interruptions. A dynamic rule engine is designed to support online updates of verification rules, adapting to the needs of different financial institutions without system downtime. Asynchronous processing and result callbacks improve system throughput. It is suitable for automated reconciliation scenarios in financial institutions such as banks and securities firms, achieving collaborative optimization of the transport and verification layers in heterogeneous financial systems. Through block-level real-time verification and dynamic rule loading, it resolves the contradiction between large file transmission efficiency and verification flexibility.

[0018] The method of this invention improves transmission reliability and reduces transmission failure rate through a block verification mechanism, enhances system availability and achieves business continuity through a rule hot update mechanism, and reduces server memory usage and improves resource utilization through an asynchronous processing mechanism.

[0019] Advantages of additional aspects of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. Attached Figure Description

[0020] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0021] Figure 1 This is a flowchart of the financial reconciliation document processing method provided in Embodiment 1 of the present invention; Figure 2 This is a flowchart of the rule verification process provided in Embodiment 1 of the present invention; Figure 3 This is a diagram of the financial reconciliation file processing system architecture provided in Embodiment 1 of the present invention. Detailed Implementation

[0022] The present invention will be further described below with reference to the accompanying drawings and embodiments.

[0023] It should be noted that the following detailed descriptions are exemplary and intended to provide further illustration of the invention. Unless otherwise specified, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains.

[0024] It should be noted that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the scope of exemplary embodiments according to the invention. As used herein, unless the context clearly indicates otherwise, the singular form is intended to include the plural form as well. Furthermore, it should be understood that the terms “comprising” and “including”, and any variations thereof, are intended to cover non-exclusive inclusion, for example, a process, method, system, product, or apparatus that includes a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0025] Where there is no conflict, the embodiments and features in the embodiments of the present invention can be combined with each other.

[0026] Example 1 This embodiment provides a method for processing financial reconciliation documents, including: After adding a file identifier to the reconciliation file to be processed, the reconciliation file to be processed is divided into blocks according to the block size determined by network bandwidth and network round-trip latency; After generating metadata for each block, including a block identifier, block index, and anti-replay token, the data is transmitted in encrypted form. After successful transmission, block-level verification based on double hash values ​​and field-level verification based on state transition rules are performed on the blocks. If the block-level validation fails, the abnormal block is retransmitted until the block-level validation passes. When all fields pass validation, the business logic validation is performed, and a reconciliation report is generated based on the validated file. Otherwise, an error code is generated for exception handling.

[0027] The following is combined with Figure 1 The method of this embodiment will be described in detail.

[0028] S1: After uploading the reconciliation file to be processed, generate a unique identifier for the reconciliation file to be processed.

[0029] Specifically, it includes: 1. Obtain the financial institution's unique institution code, the current system's timestamp accurate to milliseconds, and the generated cryptographically secure random number (length ≥ 128 bits).

[0030] 2. Assemble the above three elements in a fixed order, namely: organization code + timestamp + random number, and use the separator || to ensure clear data boundaries.

[0031] 3. Use the SHA-256 hash algorithm to process the concatenated data and generate a fixed-length (256-bit) file identifier, FileID.

[0032] 4. Identifier binding: Establish a permanent association between the FileID and the source file, write it to the file metadata header and synchronize it to the transfer log.

[0033] S2: After adding a file identifier to the reconciliation file to be processed, the reconciliation file to be processed is divided into blocks according to the dynamic block division strategy and the block size determined by the network bandwidth and network round-trip latency, and metadata is generated for each block.

[0034] Specifically: 1. Dynamic block partitioning strategies include: Monitor network bandwidth B in real time, measure network round-trip time (RTT), and then calculate the block size: S = B*RTT / k; Where B is bandwidth in Mbps; RTT is round-trip time in ms; and k is the congestion coefficient, which can be initially set to 2.0.

[0035] 2. When performing block partitioning, the dynamic block partitioning adjustment rules include: The system monitors network fluctuations in real time. When the network fluctuation exceeds the threshold (±30%), it automatically recalculates the block size S, and subsequent blocks are transmitted according to the new size.

[0036] 3. Construction of segmented metadata: Generate a metadata structure for each block that includes the following fields: { "bid": "Unique identifier for each block (generated using the UUIDv4 algorithm)", "index": "The sequential number of the block in the file (numbered consecutively starting from 0)", "nonce": "Anti-replay token (an encrypted random number based on a timestamp and counter)" } The method for generating the anti-replay token nonce includes: obtaining the SHA-1 digest value of the sender's IP address, generating an encrypted random number, and using this to calculate the anti-replay token; and effectively preventing network replay attacks by combining the HMAC-SHA1 operation based on the sender's IP address with a monotonically increasing counter value.

[0037] The block index has a dual function: it identifies the block order position and serves as a key basis for file reorganization.

[0038] S3: Encrypts and transmits block data and its metadata.

[0039] Specifically: 1. Each block is encrypted using the AES-256 algorithm. Metadata is appended to the encrypted block to form a transmission unit, which is then transmitted via the TLS 1.3 channel.

[0040] 2. Determine if the transmission was successful. If the transmission was successful, the server will start real-time verification after receiving the chunks; otherwise, record the breakpoint and wait for retransmission.

[0041] S4: Real-time validation, including block-level validation and field-level dynamic rule validation.

[0042] Specifically: S4-1: Block-level verification, used to verify block integrity; includes: 1. At the sending end, calculate the SHA-256 digest and CRC32 checksum of the block to generate the block double hash value (SHA-256+CRC32), and write the block double hash value into the block metadata header.

[0043] 2. Perform layered verification at the receiving end to verify the matching of the block double hash values ​​in real time; 2-1. Transport layer verification (at reception): Calculate the CRC32 instant check value of the received block and compare it with the CRC32 in the metadata; 2-2 Application Layer Verification (Before Processing): Calculate the SHA-256 digest of the chunked content and compare it with the digest value in the metadata.

[0044] 3. If any verification fails, record the coordinates of the abnormal block, trigger the differential update mechanism, retransmit the abnormal block, update the network congestion coefficient k value, until the block-level verification passes, and perform field-level verification on the block.

[0045] Specifically, the differential update mechanism retransmits only the abnormal blocks, including: 3-1. Anomaly Location: Accurately locate data anomalies based on the three-dimensional coordinate system (file ID + block number + field position).

[0046] 3-2. Incremental identifier: The retransmission identifier for generating abnormal blocks, which includes: source file version number, abnormal block index list and data verification fingerprint.

[0047] 3-3. Differential Transmission: Only request the specified abnormal chunk data from the client, and attach a version consistency flag during transmission.

[0048] 3-4. Data Fusion: Replace the corresponding blocks in the original file with the received abnormal blocks, and perform dual verification of block-level hash check (SHA-256) and field-level CRC32.

[0049] 3-5. Version Activation: Update the file version number and notify associated systems.

[0050] S4-2: Field-level dynamic rule validation process (corresponding state machine model), such as Figure 2 As shown, it includes: 1. Initialize state: Read the content of the field to be verified and set the current state of the verification state machine to the initial state.

[0051] 2. Character Traversal Validation: Read each character in the field sequentially, and check whether the current character triggers a valid state transition according to the preset state transition rules (including allowed character sets and state transition conditions); if a valid transition is triggered, update the current state to the next state; if a valid transition is not triggered, mark the validation as failed and terminate the process.

[0052] 3. Termination Status Determination: After the field content is read, check whether the current status belongs to the preset acceptance status set; if so, the field validation is deemed to have passed, and transaction-level business logic validation is initiated for asynchronous processing; otherwise, the field validation is deemed to have failed, and exception handling is performed.

[0053] 4. Based on the verification file that has passed the transaction-level business logic verification, enter the message queue, store the data in the database, and generate a reconciliation report.

[0054] 5. The exception handling process includes: 5-1. Use a three-dimensional coordinate system (file ID + block number + field position) to locate the error location; Coordinate generation: First dimension: Unique file identifier (organization code + timestamp + random hash value); The second dimension: block number (sequential numbering starting from 0); The third dimension: field position (using a block offset + field length tuple).

[0055] 5-2. Exception Mapping: When verification fails, generate error coordinates: FileID@BlockIndex:Offset:Length.

[0056] 5-3. Traceability Mechanism: Reverse positioning based on coordinates: retrieve source organization information by FileID, locate physical storage location by block sequence number, and extract original data content by field offset.

[0057] The field position calculation rules are as follows: Field offset = (starting byte address within the block >> 8); Field length = ending byte address - starting byte address.

[0058] 6. Versioning rules are hot-updated, implemented through atomic switching, specifically including: 6-1 Shadow Construction: Create a shadow rule chain in memory that runs parallel to the currently running rule chain, load the new shadow rule chain, and establish a rule dependency graph.

[0059] 6-2. Perform integrity verification on the new rule chain, including: Syntax check: Verifies the validity of the rule expression; Conflict detection: Checks for logical contradictions between rules; Stress testing: Verify execution stability using historical data samples.

[0060] 6-3. Switching rule chain versions via atomic operations: Set a global rule version lock, point the system rule pointer to the new rule chain address, and release the version lock (switching process <10ms).

[0061] 6-4. Old Chain Reclamation: After confirming that no pending transactions reference the old rule chain, memory resources are asynchronously reclaimed.

[0062] In this embodiment, Figure 3This is a system architecture diagram. The above technical processes can be achieved collaboratively through the functional modules shown in the system architecture diagram, including: 1. Chunked transmission subsystem; mainly includes: Adaptive chunking: dynamically adjusts chunk size based on network bandwidth; Collision-resistant verification: A double hash verification mechanism (SHA-256+CRC32) is adopted.

[0063] 2. Dynamic rule engine subsystem; mainly includes: Hot-loading rules: Achieving zero-downtime updates through version control; Context-aware: Automatically matches the set of verification rules based on the document's source organization.

[0064] 3. Asynchronous processing subsystem, mainly including: Message queue dispatcher: Uses priority queues to handle urgent reconciliation tasks; Transaction compensation unit: Automatically rolls back and retryes failed blocks.

[0065] Verification example.

[0066] Test environment: Network: simulated gigabit bandwidth (fluctuation range ±40%); Server: 4-core CPU / 16GB memory; Sample: 1000 500MB SWIFT MT940 files. Test results are shown in Table 1.

[0067] Table 1. Test Results;

[0068] The method described in this embodiment employs a dynamic block partitioning strategy, a dual hash verification mechanism, and index records. Through block upload and breakpoint resume mechanism, it achieves efficient transmission of large files and rapid recovery from network interruptions. A dynamic rule engine is designed to support online updates of verification rules, adapting to the needs of different financial institutions without system downtime. Asynchronous processing and result callbacks improve system throughput.

[0069] The method described in this embodiment improves transmission reliability and reduces transmission failure rate through a block verification mechanism, enhances system availability and achieves business continuity through a rule hot update mechanism, and reduces server memory usage and improves resource utilization through an asynchronous processing mechanism.

[0070] It should be noted that all data acquisition is conducted in accordance with laws and regulations and with user consent, and the data is used legally.

[0071] Example 2 This embodiment provides a financial reconciliation file processing system, including: The chunking module is configured to add file identifiers to the reconciliation files to be processed, and then chunk the reconciliation files to be processed according to the chunk size determined by network bandwidth and network round-trip latency. The transmission module is configured to generate metadata for each chunk, including a chunk identifier, a chunk index, and a replay protection token, and then transmit it in encrypted form. The verification module is configured to perform block-level verification based on double hash values ​​and field-level verification based on state transition rules after successful transmission. The processing module is configured to retransmit the abnormal block if the block-level validation fails, until the block-level validation passes; when all fields pass validation, the business logic validation is performed, and a reconciliation report is generated based on the validated file; otherwise, an error code is generated for exception handling.

[0072] It should be noted that the above modules correspond to the steps described in Embodiment 1, and the examples and application scenarios implemented by the above modules and the corresponding steps are the same, but are not limited to the content disclosed in Embodiment 1. It should also be noted that the above modules, as part of the system, can be executed in a computer system such as a set of computer-executable instructions.

[0073] In further embodiments, the following is also provided: An electronic device includes a memory and a processor, as well as computer instructions stored in the memory and running on the processor, wherein the computer instructions, when executed by the processor, perform the method described in Embodiment 1. For brevity, further details are omitted here.

[0074] It should be understood that in this embodiment, the processor can be a central processing unit (CPU), or it can be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor, etc.

[0075] Memory may include read-only memory and random access memory, and provides instructions and data to the processor. A portion of memory may also include non-volatile random access memory. For example, memory may also store information about the device type.

[0076] A computer-readable storage medium for storing computer instructions, which, when executed by a processor, perform the method described in Embodiment 1.

[0077] The method in Example 1 can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor. The software modules can reside in readily available storage media in the field, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. This storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method. To avoid repetition, a detailed description is not provided here.

[0078] A computer program product includes a computer program that, when executed by a processor, implements the method described in Embodiment 1.

[0079] The present invention also provides at least one computer program product tangibly stored on a non-transitory computer-readable storage medium. The computer program product includes computer-executable instructions, such as instructions included in program modules, which execute in a device on a target real or virtual processor to perform the processes / methods described above. Typically, program modules include routines, programs, libraries, objects, classes, components, data structures, etc., that perform specific tasks or implement specific abstract data types. In various embodiments, the functionality of program modules can be combined or divided among program modules as needed. The machine-executable instructions for the program modules can execute within a local or distributed device. In a distributed device, the program modules can reside in both local and remote storage media.

[0080] The computer program code used to implement the methods of the present invention may be written in one or more programming languages. This computer program code may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the computer or other programmable data processing device, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a computer, partially on a computer, as a stand-alone software package, partially on a computer and partially on a remote computer, or entirely on a remote computer or server.

[0081] In the context of this invention, computer program code or related data may be carried by any suitable carrier to enable a device, apparatus, or processor to perform the various processes and operations described above. Examples of carriers include signals, computer-readable media, and the like. Examples of signals may include electrical, optical, radio, sound, or other forms of propagation signals, such as carrier waves, infrared signals, etc.

[0082] Those skilled in the art will recognize that the units and algorithm steps described in connection with the various examples of this embodiment can be implemented in electronic hardware or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this invention.

[0083] While the specific embodiments of the present invention have been described above in conjunction with the accompanying drawings, this is not intended to limit the scope of protection of the present invention. Those skilled in the art should understand that various modifications or variations that can be made by those skilled in the art without creative effort based on the technical solutions of the present invention are still within the scope of protection of the present invention.

Claims

1. A method for processing financial reconciliation documents, characterized in that, include: After adding a file identifier to the reconciliation file to be processed, the reconciliation file to be processed is divided into blocks according to the block size determined by network bandwidth and network round-trip latency; After generating metadata for each block, including a block identifier, block index, and anti-replay token, the data is transmitted in encrypted form. After successful transmission, block-level verification based on double hash values ​​and field-level verification based on state transition rules are performed on the blocks. If the block-level verification fails, the abnormal block will be retransmitted until the block-level verification passes. If all fields pass validation, validate the business logic and generate a reconciliation report based on the validated file; otherwise, generate an error code for exception handling.

2. The financial reconciliation document processing method as described in claim 1, characterized in that, The process of generating a file identifier includes: obtaining the institution code, current timestamp, and random number of the financial institution; concatenating them in the order of institution code, current timestamp, and random number; processing the concatenated data using a hash algorithm to generate a fixed-length file identifier; associating the file identifier with the reconciliation file to be processed; and writing it into the file metadata header.

3. The financial reconciliation document processing method as described in claim 1, characterized in that, The block size is S = B*RTT / k; where B is the bandwidth; RTT is the round-trip time; and k is the congestion coefficient. The system monitors network fluctuations in real time. When the network fluctuations exceed a threshold, the block size is recalculated, and subsequent blocks are transmitted according to the new block size.

4. The financial reconciliation document processing method as described in claim 1, characterized in that, Block-level verification includes: Calculate the SHA-256 digest and CRC32 checksum of the block, generate the block double hash value, and write the block double hash value into the block metadata header; Layered verification is performed based on the block double hash value, including: Transport layer verification: Calculate the CRC32 checksum of the received block and compare it with the CRC32 checksum in the block metadata header; Application layer verification: Calculate the SHA-256 digest of the received chunk content and compare it with the SHA-256 digest in the chunk metadata header; If any verification fails, the coordinates of the abnormal block are recorded, the differential update mechanism is triggered, and the abnormal block is retransmitted.

5. The financial reconciliation document processing method as described in claim 4, characterized in that, The process of retransmitting abnormal blocks using the differential update mechanism specifically includes: Based on the file identifier, block index and field position, locate the data anomaly point, generate the retransmission identifier of the abnormal block, which includes the source file version number, the abnormal block index list and the data verification fingerprint; Request that abnormal data chunks be specified and that a version consistency flag be attached during transmission; Replace the corresponding block in the original file with the received abnormal block, and perform block-level hash verification and field-level CRC32 dual verification.

6. The financial reconciliation document processing method as described in claim 1, characterized in that, The field-level validation process includes: Read the content of the field to be verified and set the current state of the verification state machine to the initial state; Read each character in the field sequentially, and check whether the current character triggers a valid state transition according to the preset state transition rules, including the allowed character set and state transition conditions. If a valid transition is triggered, update the current state to the next state. If a valid transition is not triggered, mark the verification as failed and terminate the process. After the field content is read, check whether the current state belongs to the preset acceptance state set; if so, the field validation is considered successful; otherwise, the field validation is considered to have failed and exception handling is performed.

7. A financial reconciliation file processing system, characterized in that, include: The chunking module is configured to add file identifiers to the reconciliation files to be processed, and then chunk the reconciliation files to be processed according to the chunk size determined by network bandwidth and network round-trip latency. The transmission module is configured to generate metadata for each chunk, including a chunk identifier, a chunk index, and a replay protection token, and then transmit it in encrypted form. The verification module is configured to perform block-level verification based on double hash values ​​and field-level verification based on state transition rules after successful transmission. The processing module is configured to retransmit the abnormal block if the block-level verification fails, until the block-level verification passes. If all fields pass validation, validate the business logic and generate a reconciliation report based on the validated file; otherwise, generate an error code for exception handling.

8. An electronic device, characterized in that, It includes a memory and a processor, as well as computer instructions stored in the memory and running on the processor, which, when executed by the processor, perform the method according to any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, Used to store computer instructions, which, when executed by a processor, perform the method described in any one of claims 1-6.

10. A computer program product, characterized in that, Includes a computer program, which, when executed by a processor, implements the method described in any one of claims 1-6.

Images