A method and system for batch merging and signing electronic bank documents

Abstract

This invention proposes a method and system for batch merging and signing electronic documents in banking. The method includes: obtaining a business batch identifier and a list of documents to be signed; performing page normalization processing on the electronic documents to calculate page-level summaries and generating a batch status lock table; reading the electronic documents in file order and appending pages to generate merged documents to be signed, while simultaneously generating a sub-file boundary table containing page number boundaries and sub-file boundary anchor values; performing a pre-signing consistency check, recalculating the summaries and anchor values, generating and comparing the current and record boundary order chains, and generating a signing permission record when they match; and generating a signed merged document by performing an electronic signature based on the permission record and encapsulating it into an archiveable evidence package. This application effectively prevents the risks of document replacement and out-of-order issues in batch signing and ensures that the source of the split documents after signing is verifiable.

Description

Technical Field

[0001] This invention belongs to the field of information security technology, and in particular relates to a method and system for batch merging and signing electronic documents in banks. Background Technology

[0002] When banks conduct business such as account opening, credit granting, loan issuance, guarantee issuance, corporate online banking authorization, receipt confirmation, account reconciliation, and document retrieval, they typically need to organize, batch merge, electronically sign, and archive multiple electronic documents, including application forms, contracts, supplementary agreements, authorization letters, risk disclosure statements, guarantee documents, and supporting materials, within the same business batch. Existing electronic signature systems usually have capabilities such as single document signing, multiple document uploading, PDF or OFD merging, designated location stamping, digital signatures, timestamps, and post-signature verification. Their technical foundation mainly involves converting documents to be signed into formatted files, sequentially concatenating them, and applying an electronic signature to the merged document to verify whether the document has been tampered with after signing. However, in the actual engineering process of bank batch business, documents to be signed are not generated all at once by a single system, but may come from business systems, image systems, counter upload systems, approval systems, electronic signature systems, and document systems. These systems may also undergo multiple stages, including file format conversion, image rescanning, template version updates, attachment supplementation, approval workflow, signing task queuing, and archiving storage. Because of the large number of documents in the same batch, their complex origins, and different types, existing systems that rely solely on file names, upload order, template numbers, manual selection results, or the overall summary after merging to control the batch signing process are prone to inconsistencies between the signed objects and the original batch objects. For example, a set of documents may be confirmed during approval, but an attachment may have been replaced or missing a page during actual signing; the order of a contract or authorization letter may have been adjusted during merging without being detected; the signing configuration version may have changed after merging; and multiple merged documents with the same or similar names may exist in the same batch, with the signing service using the wrong file. On the other hand, existing post-signature verification mainly proves that the overall document has not been modified after signing, but it does not adequately preserve the boundary relationships between the original documents before merging and the merged pages. When banks subsequently need to extract a specific authorization letter, contract, or attachment for auditing, litigation, customer access, or internal review, it is often difficult to directly prove the starting page, ending page, page-level content, business batch to which the sub-file belongs, and the relationship between adjacent documents in the original merged document. It is evident that while existing technologies can complete batch file merging and overall electronic signing, they still lack continuous technical constraints on the signing object locking, merging boundary solidification, pre-signing consistency verification, and post-signing archiving evidence binding during the bank's batch merging and signing process. This can lead to problems such as incorrect signing, missing signing, replacement signing, out-of-order signing, and difficulty in proving the source after splitting. Summary of the Invention

[0003] This invention discloses a method and system for batch merging and signing electronic bank documents to solve the problems mentioned in the background art.

[0004] To achieve the above objectives, the first aspect of the present invention provides a method for batch merging and signing of bank electronic documents, the method comprising: Obtain the business batch identifier, the list of documents to be signed, and the business document types; The electronic documents in the list of documents to be signed are subjected to page normalization processing to obtain standard page data, and the page-level summary of each page in the electronic documents is calculated; Generate a signing configuration summary and a batch status lock table. The batch status lock table records the de-identified file identifier, file type, file order, number of pages, page-level summary list, signing configuration summary, and encrypted file storage pointer of the electronic file. According to the batch status lock table, the electronic files are read in file order to append pages and generate a merged file to be signed. At the same time, a sub-file boundary table is generated. The merged file to be signed, the sub-file boundary table, the summary of the batch status lock table, and the summary of the merged file to be signed are encapsulated into a merged file package to be verified. The sub-file boundary table records the page number boundaries, page-level summary list, boundary context description, and sub-file boundary anchor values ​​of the electronic files in the merged file to be signed. Based on the merged file to be signed and the sub-file boundary table, perform a consistency check before signing, recalculate the current overall digest, the current page-level digest list and the current sub-file boundary anchor value, generate the current boundary sequence chain and the record boundary sequence chain, compare the tail digest of the current boundary sequence chain with the tail digest of the record boundary sequence chain, and generate a signing license record when the two are consistent. Based on the signing permission record, an electronic signature is performed on the merged document to be signed to generate a signed merged document. The summary of the signed merged document, the signing permission record, the summary of the sub-document boundary table, and the summary of the boundary sequence chain tail are encapsulated into an archiveable evidence package.

[0005] Furthermore, the step of performing page normalization processing on the electronic documents in the list of documents to be signed to obtain standard page data includes: The page object of the electronic file is read through the file parsing interface, and the visible text, table lines, images, QR codes, existing seal images, headers and footers and fixed layout elements are retained. Standard page data is formed according to fixed page output rules. The calculation of page-level summaries for each page in the electronic file includes: The standard page data of the page is used as input, and a page-level digest is calculated using a deterministic digest algorithm. The page-level digest is then written into the batch status lock table.

[0006] Furthermore, the method for generating the de-identified file identifier includes: The internal file number, business batch identifier, and file receipt sequence number of the electronic file are concatenated in a fixed field order and then processed into a summary to obtain a string used to uniquely locate the file within the batch.

[0007] Furthermore, the method for generating the sub-file boundary anchor values ​​includes: The page-level summary list of the electronic document is calculated by concatenating the page-level summary list in page order; The batch status lock table summary, the page-level list summary of the preceding electronic file, the page-level list summary of the following electronic file, and the signature configuration summary are serialized in a fixed field order to obtain a boundary context description. For the electronic file that is first in the sort, a fixed start marker is written in the previous position; for the electronic file that is last in the sort, a fixed end marker is written in the next position. The de-identified file identifier, the page number boundary, the page-level list summary, and the boundary context description are concatenated in a fixed field order and then input into a summary algorithm to obtain the sub-file boundary anchor value.

[0008] Further, generating the current boundary sequence chain and recording the boundary sequence chain includes: The batch status lock table summary in the merged file package to be verified is used as the starting point of the chain; The sub-file boundary anchor values ​​and page number boundaries of the electronic file are used as chain node data in the order of the files. The previous chain node summary and the current chain node data are concatenated in a fixed field order and then input into the summary algorithm to recursively obtain the current boundary order chain. Based on the sub-file boundary anchor values ​​and page number boundaries recorded in the sub-file boundary table, the same chain starting point and recursive method are used to obtain the record boundary sequence chain.

[0009] Furthermore, the pre-signature consistency verification also includes: The structural integrity of the merged file package to be verified is checked. If any object of the merged file to be signed, the sub-file boundary table, the batch status lock table summary, or the merged file summary to be signed is missing, or if the number of records in the sub-file boundary table is inconsistent with the number of files in the batch status lock table, a signing prohibition record is generated. Recalculate the current overall summary and compare it with the summary of the merged file to be signed recorded in the merged file package to be verified; The expected page number boundaries are regenerated based on the file order and file page number in the batch status lock table, and compared item by item with the page number boundaries recorded in the sub-file boundary table; Based on the page number boundaries recorded in the sub-file boundary table, consecutive page segments are extracted one by one from the electronic files in the merged file to be signed, generating current standard page data and calculating the current page-level summary list, which is then compared with the page-level summary list recorded in the sub-file boundary table.

[0010] Furthermore, the conditions for generating the signing license record include: The current overall summary is consistent with the summary of the merged document to be signed recorded in the merged document package to be verified; The current boundary sequence tail digest is consistent with the record boundary sequence tail digest; When both of the above conditions are met, a signing license record is generated. The signing license record contains the following: summary of the merged file to be signed, summary of the batch status lock table, summary of the sub-file boundary table, summary of the boundary order chain tail, set of signing configuration summaries, verification time, and identifier of the merged file package to be verified. If any of the above conditions are not met, a signing prohibition record will be generated.

[0011] Furthermore, the method also includes: Establish a one-time binding relationship between the signing license record and the identifier of the merged file package to be verified and the summary of the merged file to be signed, restricting the same signing license record to be consumed only once; Set the validity period of the signing permission record, which shall not exceed the validity period of the electronic signature service session or the validity period of the certificate retrieval session; If the signing task queue time exceeds the effective duration, or if the merged file package to be verified is rewritten after the license is granted, the signing license record will be set to invalid and the pre-signing consistency verification will be re-executed.

[0012] Furthermore, the packaged evidence into an archiveable evidence package includes: The signed merged document digest, signing license record digest, sub-document boundary table digest, and boundary order chain tail digest are concatenated in a fixed field order and then input into the digest algorithm to calculate the evidence package anchor digest. The signed merged document digest, signing license record, batch status lock table digest, sub-file boundary table and sub-file boundary table digest, boundary sequence chain tail digest, evidence package anchoring digest, signature value digest, certificate digest, signing time, timestamp information and archive storage pointer are written into the same evidence structure to obtain an archiveable evidence package.

[0013] A second aspect of the present invention provides a batch merging and signing system for bank electronic documents, the system comprising: The batch status locking module is used to obtain the business batch identifier, the list of documents to be signed, and the business document type; perform page normalization processing on the electronic documents in the list of documents to be signed to obtain standard page data, and calculate the page-level summary of each page in the electronic documents; generate a signing configuration summary and a batch status locking table, wherein the batch status locking table records the de-identified file identifier, file type, file order, number of pages, page-level summary list, signing configuration summary, and encrypted file storage pointer of the electronic documents; The file merging and boundary generation module is used to read the electronic files in file order according to the batch status lock table to add pages and generate a merged file to be signed, and at the same time generate a sub-file boundary table. The module encapsulates the merged file to be signed, the sub-file boundary table, the summary of the batch status lock table, and the summary of the merged file to be signed into a merged file package to be verified. The sub-file boundary table records the page number boundaries, page-level summary list, boundary context description, and sub-file boundary anchor values ​​of the electronic files in the merged file to be signed. The pre-signing consistency verification module is used to perform pre-signing consistency verification based on the merged file to be signed and the sub-file boundary table, recalculate the current overall digest, the current page-level digest list and the current sub-file boundary anchor value, generate the current boundary sequence chain and the record boundary sequence chain, compare the tail digest of the current boundary sequence chain with the tail digest of the record boundary sequence chain, and generate a signing license record when the two are consistent. The electronic signature recall module is used to perform an electronic signature on the document to be signed and merge it according to the signing permission record to generate a signed and merged document. The evidence package encapsulation module is used to encapsulate signed merged document digests, signing license records, sub-file boundary table digests, and boundary order chain tail digests into archiveable evidence packages.

[0014] The beneficial technical effects of this invention are as follows: By generating a batch status locking table to fix the signing objects, a sub-file boundary table is generated synchronously during merging to solidify the mapping relationship between the original files and the merged pages, and a consistency check is performed using a boundary sequence closed chain before signing, effectively preventing risks of file replacement, missing pages, out-of-order issues, and configuration inconsistencies in batch signing. Simultaneously, the pre-signing permission status, sub-file boundary structure, and post-signing signature result are bound and encapsulated into an archiveable evidence package, making the entire document verifiable. Furthermore, when a single sub-file is split and invoked in subsequent audits or litigation, page-level summaries and boundary anchor values ​​can accurately prove that it originated from the original signing batch and that no page removal or replacement occurred, significantly improving the data integrity, object consistency, and verifiability of post-signing evidence in batch signing of bank electronic documents. Attached Figure Description

[0015] The present invention will be further described with reference to the accompanying drawings, but the embodiments in the drawings do not constitute any limitation on the present invention. For those skilled in the art, other drawings can be obtained based on the following drawings without creative effort.

[0016] Figure 1 This is a flowchart of a method for batch merging and signing bank electronic documents according to an embodiment of the present invention.

[0017] Figure 2 This is a flowchart of page normalization processing and page-level summary calculation in an embodiment of the present invention.

[0018] Figure 3 A logic block diagram is generated for the sub-file boundary anchoring values ​​in this embodiment of the invention.

[0019] Figure 4 This is a block diagram of the bank electronic document batch merging and signing system in an embodiment of the present invention. Detailed Implementation

[0020] Embodiments of the present invention are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention, and should not be construed as limiting the present invention.

[0021] This application provides a method for batch merging and signing electronic bank documents. For example... Figure 1 As shown, the method includes the following steps: Step S101: Obtain the business batch identifier, the list of documents to be signed, and the business document type; perform page normalization processing on the electronic documents in the list of documents to be signed to obtain standard page data; calculate the page-level summary of each page in the electronic documents; generate a signing configuration summary and a batch status lock table; the batch status lock table records the de-identified file identifier, file type, file order, number of pages, page-level summary list, signing configuration summary, and encrypted file storage pointer of the electronic documents.

[0022] Specifically, step S101 generates a batch status lock table after the bank's electronic document batch merging and signing task is initiated. This table is used to fix the file range, merging order, page content, and signing configuration version of the electronic documents in this batch. Bank electronic documents are usually provided by multiple systems. For example, the credit system generates the main contract, the imaging system supplements the attachments, the counter system uploads the authorization letter, and the signature task management system aggregates and initiates the batch signing task. Documents in the same batch may undergo engineering steps such as uploading, format conversion, image rescanning, and task flow. After receiving the batch signing task, the system reads the business batch identifier, the list of documents to be signed, and the business document type information from the task interface. The business batch identifier is generated by the bank's business system when creating the signing task, such as the account opening batch number, credit batch number, or contract signing batch number. The list of documents to be signed is provided by the bank's document storage system or imaging system. Each record contains an internal document number, a file storage pointer, a file format, a file receiving sequence number, and a file type code. The business document type information comes from the existing file type codes in the business system, such as main contracts, guarantee contracts, authorization letters, risk disclosure statements, and attachment materials. The batch status lock table uses desensitized file identifiers, page-level digests, signed configuration digests, and encrypted file storage pointers to store processing results, ensuring that subsequent merging and verification are performed around the determined file technical status.

[0023] like Figure 2 As shown, after reading the list of documents to be signed, the system retrieves the corresponding electronic documents one by one through the bank's document processing service. For PDF files, the system reads the number of pages and page objects through the PDF parsing interface; for OFD files, the system reads the page packets and display objects through the OFD parsing interface; for scanned image files, the system obtains the standard pages through the format conversion interface provided by the image platform. Subsequently, the system generates a de-identified file identifier for each electronic document. Specifically, it concatenates the internal document number, business batch identifier, and document receipt sequence number in a fixed field order and performs digest processing to obtain a string used to uniquely locate the file within the batch. For example, if the original file name of the second document in a batch is "Authorization Letter of a Company.pdf", the system concatenates the corresponding internal document number, batch identifier, and receipt sequence number to generate a de-identified file identifier and writes this de-identified file identifier into the batch status lock table. Next, the system determines the document order based on pre-configured business document sorting rules in the bank's signature management system or business process system. For example, for a certain type of corporate credit business, the sorting rules may stipulate that the main contract comes first, followed by the guarantee contract, then the authorization letter, and finally the supporting documents. When there are multiple attachments under the same type, they are arranged according to the document receipt number. The system matches the document type codes in the list of documents to be signed with the sorting rules to obtain the document order of each document in this batch, and uses this document order as the fixed order source for subsequent merging.

[0024] To avoid unclear field boundaries caused by directly concatenating different fields, the system employs a unified field serialization rule when generating desensitized file identifiers, signature configuration summaries, batch status lock table summaries, page-level list summaries, boundary context descriptions, and subsequent evidence package summaries. This rule writes the field name, field length, field value, and field order into the byte string to be digested. Field values ​​are represented using character encoding or raw binary bytes as agreed upon by the banking system. Empty fields are marked with a fixed null value, and non-existent preceding or following files are marked with a fixed start or end marker. This process ensures consistent digest input for the same set of fields across different servers, task nodes, and file format conversion environments. It also avoids the possibility of accidentally concatenating "field one plus field two" and "field three plus field four" at the byte level, which could lead to unclear boundary meanings.

[0025] After the file order is determined, the system performs page normalization on each electronic document. Page normalization is used to obtain stable page display data. The bank document processing service reads the electronic document page by page, retaining visible text, table lines, images, QR codes, existing seal images, headers and footers, and fixed layout elements, and forming standard page data according to fixed page output rules. This process unifies the underlying differences caused by differences in creation time, conversion task number, temporary cache object number, or the arrangement of objects within the PDF when the same page is exported from different systems. For example, if the same authorization letter is exported twice from the counter system, and the signature field, body text, and page numbers are consistent on the page, after page normalization, the same page exported in both cases will form the same standard page data. If the last page of the authorization letter is replaced, or a section of authorization content is removed from the body text of a page, the normalized standard page data will change accordingly. After obtaining the standard page data, the system calculates a page-level summary for each page. The page-level digest uses the SHA-256 hash algorithm from cryptography. The original purpose of SHA-256 is to convert any byte string into a fixed-length digest. This application uses standard page data from bank electronic documents after page normalization as input to the algorithm, enabling changes in the displayed page content to be reflected through digest comparison. The page-level digest is generated using the following formula: ; in, Indicates the first The first electronic document The page-level summary of a page is calculated by the system and written into the batch status lock table; Indicates the first The first electronic document The standard page data obtained after page normalization is output page by page by the bank's document processing service; This indicates the file's sequence number within this batch, derived from the bank's pre-configured business file sorting rules. This indicates the page number within the associated electronic document, derived from the page order read by the file parsing interface; This represents a deterministic digest algorithm. The input is the byte string corresponding to the page, and the output is a digest string.

[0026] In the engineering implementation, if the test byte string obtained after page normalization is "abc", the system executes... The resulting page-level digest is ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad. In actual operation of the banking system... This corresponds to a complete standard page data byte string, such as a byte string containing the page text display result, image objects, and the serialized result of layout elements; the same The input returned the same When the content displayed on the page changes, the corresponding Changes, calculations This also changes accordingly. Therefore, the system can locate page replacements, missing pages, or changes in page content in subsequent steps using page-level summaries, without needing to read and save plaintext business data fields.

[0027] After generating the page-level summary, the system generates a signing configuration summary. The signing configuration summary comes from existing configuration records in the bank's signature management system. The system reads the configuration version number, applicable file type, signature type, authorized signing entity code, and signature service identifier corresponding to the current business type and file type. These fields are serialized in a fixed field order, and the same summary algorithm is used to generate the signing configuration summary. For example, if the signing configuration for a certain type of authorization letter is "Configuration version V3, Applicable authorization letter, Use of enterprise electronic signature and bank business seal, Call specified signature service channel," the system serializes this configuration, calculates the summary, and writes the result to the batch status lock table. Finally, the system generates file records in the batch status lock table one by one according to the determined file order. Each file record includes a de-identified file identifier, file type, file order, number of file pages, page-level summary list, signing configuration summary, and encrypted file storage pointer. The number of file pages is obtained from the number of pages read by the file parsing interface; the page-level summary list is calculated page by page in this step; the encrypted file storage pointer is returned by the bank's file storage system and can be an encrypted object number, a controlled file handle, or an encrypted storage address. Taking a batch signing task for a bank's corporate credit line as an example, the task includes a 12-page main contract, a 3-page authorization letter, and 5 pages of supporting materials. The system determines the order of the main contract, authorization letter, and supporting materials according to existing sorting rules, and then generates 12, 3, and 5 page-level summaries respectively. For each of the three documents, it writes an anonymized file identifier, file type, file order, number of pages, a list of page-level summaries, a signing configuration summary, and an encrypted file storage pointer. The generated batch status lock table serves as the input for step S102. Step S102 reads the files according to the file order and encrypted file storage pointer recorded in the table and generates a merged file to be signed.

[0028] If the task interface returns an empty list of documents to be signed, the same internal file number appears repeatedly in the same batch, the file type code cannot match the existing sorting rules, the file parsing interface cannot read the page count, any file has zero pages, the signing configuration record does not exist, or the configuration version is in a disabled state, the system will not generate a batch status lock table. Instead, it will generate a batch lock failure record and terminate the subsequent merging and signing process for that batch. If the scanned image files have inconsistent page counts, timeouts, or missing standard page data during format conversion, the system will write the corresponding de-identified file identifier and the reason for failure into the lock failure record. This exception handling ensures that the batch status lock table is generated only when the file range, page count, file order, and signing configuration are all determined, preventing subsequent steps from continuing to execute based on an incomplete state.

[0029] Step S102: According to the batch status lock table, the electronic files are read in file order to append pages and generate a merged file to be signed. At the same time, a sub-file boundary table is generated. The sub-file boundary table records the page number boundaries, page-level summary list, boundary context description, and sub-file boundary anchor values ​​of the electronic files in the merged file to be signed.

[0030] like Figure 3 As shown, specifically, step S102 receives the batch status lock table generated in step S101 and uses this table as the sole source of status for generating the merged documents to be signed. The de-identified file identifier in the batch status lock table is used to mark the source of each sub-file after merging; the file type is used to retain the banking business category to which the sub-file belongs; the file order is used to determine the order in which pages are appended; the file page number is used to calculate the page number boundary of each sub-file in the merged file; the page-level summary list is used to establish the correspondence between the original pages and the merged pages; the signature configuration summary is used to bind the applicable signature configuration version for the sub-file; and the encrypted file storage pointer is used to read the electronic documents actually involved in the merging from the bank's document storage system. The merged objects in bank batch signing are usually not isolated documents, but a group of contracts, authorizations, attachments, and risk documents belonging to the same business batch; these documents may be archived as a whole after signing, or a single document may be extracted for use during audits, litigation, customer access, or internal review. Therefore, this step generates a sub-file boundary table while generating the merged document to be signed, so that the correspondence between the start page, end page, page summary and batch context of each original electronic document in the merged document is simultaneously solidified.

[0031] The system reads file records from smallest to largest according to the file order in the batch status lock table, and uses the encrypted file storage pointer in each record to call the controlled read interface of the bank's document storage system to obtain the corresponding electronic file or a standardized file copy. For PDF files, the merging service appends page objects page by page through the PDF page import interface, preserving page size, page orientation, visible text, images, table lines, and existing seal images; for OFD files, the merging service appends page packages sequentially through the OFD page assembly interface; for formatted files converted from scanned images, the merging service writes standard pages into the target formatted file according to the page order obtained in step S101. Before appending each file, the system reads the number of file pages in the batch status lock table and confirms the consistency between the actual number of pages read and the number of pages in the file; then, it appends pages sequentially according to the internal page order of the file, so that the first... The first electronic document The pages in the merged document to be signed fall into the corresponding consecutive page segments of that document. Taking a corporate credit business as an example, the order of the main contract, authorization letter, and supporting materials in the batch status lock table has been determined. The merging service reads the three documents in sequence and appends the pages. The page arrangement in the generated merged document to be signed directly inherits the file order locked in step S101.

[0032] If the file entity read by the merging service based on the encrypted file storage pointer does not match the number of file pages recorded in the batch status lock table, or if issues such as inaccessible files, inconsistent file formats with record formats, missing page objects, or page import failures occur during the reading process, the system will stop generating the merged file to be signed and generate a merge exception record. This record includes the business batch identifier, the de-identified file identifier, the file order, the number of locked pages, the actual number of pages, the exception type, and the processing time. Only when all files are successfully appended in the locked order, and the actual number of pages in each file matches the batch status lock table, will the system continue to calculate the sub-file boundary table. This process clarifies the interruption conditions of the merging phase, ensuring that step S102 will not output a seemingly complete merged file package to be verified even when there are missing pages, overwrite during rescanning, or when the storage pointer fails.

[0033] The start and end pages in the sub-file boundary table are determined according to the prefix page number relationship of the concatenated ordered segments. This relationship originates from the prefix sum calculation of finite ordered sequences in discrete mathematics: when multiple segments are concatenated sequentially, the starting position of a segment is determined by the lengths of all preceding segments, and the ending position is determined by its starting position and its own length. This application applies this prefix sum relationship to the scenario of batch merging and signing bank electronic documents, treating each electronic document as an ordered page segment, and using the file page number in the batch status lock table as the length of that segment, thereby obtaining the page number boundary mapping between the original electronic document and the document to be signed and merged: ; in, Indicates the first The page number boundaries of the electronic document in the merged document to be signed are as follows: the first page is the starting page of the electronic document, and the second page is the ending page of the electronic document. These represent the first item in the batch status lock table. The first copy The number of pages in the electronic document is derived from the number of pages read by the file parsing interface in step S101; This indicates the file order of the currently processed electronic files in the batch status lock table, derived from the bank's pre-configured business file sorting rules. This formula is directly derived from the prefix page number accumulation relationship and is used to convert the file page numbers before merging into consecutive page number boundaries after merging.

[0034] In a batch signing embodiment for corporate credit lines, the batch status lock table records the following document order in sequence: main contract, authorization letter, and supporting materials, with corresponding page numbers as follows: , , Regarding the main contract, This indicates that it occupies the first position in the merger documents to be signed. Pages to number Page; for the power of attorney, This indicates that it occupies the first position in the merger documents to be signed. Pages to number Page; for attachments, This indicates that it occupies the first position in the merger documents to be signed. Pages to number The merging service writes these page number boundaries synchronously when writing pages, ensuring that the merged authorization is not just the first page in the overall file. Pages to number Instead of individual pages, they correspond to the authorization document records, page-level summary lists, and signature configuration summary locked in step S101.

[0035] After determining the page number boundaries, the system generates sub-file boundary anchor values ​​for each electronic document. These anchor values ​​employ the "field concatenation followed by digest binding" concept from cryptographic digest algorithms. The original algorithm is based on the SHA-256 digest algorithm, which converts the input byte string into a fixed-length digest. This application designs the input byte string as a combination of boundary fields adapted to the scenario of merging and signing bank electronic documents, enabling the anchor value to simultaneously bind the sub-file identity, page number boundaries, page content, and batch context. The system first... The page-level summary list of the electronic document is concatenated according to page order, and the summary is calculated to obtain the page-level list summary. Regenerate boundary context description This description is obtained by serializing the batch status lock table summary, the page-level list summary of the previous electronic document, the page-level list summary of the next electronic document, and the signature configuration summary in a fixed field order. For the first electronic document, a fixed start marker is written at the position of the previous electronic document; for the last electronic document, a fixed end marker is written at the position of the next electronic document. The sub-file boundary anchor values ​​of an electronic document are generated using the following formula: When this batch contains only one electronic document, the boundary context description of that electronic document is written to both a fixed start marker and a fixed end marker, and is still written to the batch status lock table summary and signing configuration summary. This allows single-document batch signing scenarios to form sub-file boundary anchor values ​​through the same field structure. Page-level list summary The generation order strictly follows the page number within the corresponding electronic file. If any page-level abstract is missing or the page number is not consecutive, the system will not calculate it. The file is then logged as a boundary generation failure. Thus, the input fields, boundary conditions, and failure conditions for the subfile boundary anchoring values ​​remain defined.

[0036] ; in, Indicates the first The sub-file boundary anchoring values ​​of an electronic document are calculated by the system and written into the sub-file boundary table; Indicates the first The desensitized file identifier of the electronic document is derived from the batch status lock table generated in step S101; The page number boundaries of the electronic document in the merged document to be signed are calculated from the aforementioned prefix page number relationship; The page-level list summary of the electronic document is calculated by concatenating the page-level summary list formed in step S101 according to page order. The boundary context description is obtained by serializing the batch status lock table summary, the page-level list summary of adjacent files, and the signature configuration summary in a fixed field order. Deterministic digest algorithm; This indicates byte concatenation according to a fixed field order. In this formula... It is a context constraint item set for bank batch merging and signing scenarios. It is used to bind a single sub-file to its business batch, the relationship between preceding and following files, and the signing configuration version. This avoids the difficulty in distinguishing the same file fragments in different batches or different merging orders when relying solely on the start and end pages to describe the boundaries of sub-files.

[0037] Taking the power of attorney as an example again, the power of attorney is the first... The electronic document has page number boundaries of [number]. The system will grant authorization letter number [number]. Pages to number The page-level summary of each page is obtained by concatenating and calculating the page-level summary in page order. Then, serialize the batch status lock table summary, the page-level list summary of the main contract, the page-level list summary of the attachment materials, and the signing configuration summary corresponding to the authorization letter to obtain... Subsequently, the system will identify the de-identified version of the authorization letter. Page number boundaries Page-level list summary and boundary context description Concatenate the data according to a fixed field order and then send it in. The algorithm obtains During interface integration testing, if a set of boundary anchor fields, after serialization, forms the test byte string "abc", then... The output is ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad; In the actual operation of the bank system, the input byte string is... , , and The actual serialization result is composed of [the following]. Therefore, it can be seen that if a page within the authorization document is replaced, It will change as the page-level summary list changes; if the authorization letter is moved to a later file, It will change depending on the relationship between adjacent files; if the start and end pages of the authorization letter change in the merged file, It will change; any change in any field will result in a different sub-file boundary anchor value.

[0038] The system generates sub-file boundary records for each file. Each sub-file boundary record includes a de-identified file identifier, file type, page number boundary, page-level summary list, signature configuration summary, boundary context description, and sub-file boundary anchor value. The de-identified file identifier, file type, page-level summary list, and signature configuration summary are directly taken from the batch status lock table; the page number boundary is calculated from the prefix page number relationship; the boundary context description is obtained by serializing the batch status lock table summary, the page-level list summary of adjacent files, and the signature configuration summary; the sub-file boundary anchor value is calculated from the above fields in a fixed order. For common situations in actual bank projects, such as the increase in page count due to supplementary scanning of attachments, replacement of authorization letter versions, reversal of the order of guarantee contracts and main contracts, and switching of signature configuration versions, the sub-file boundary table can reflect the differences through page number boundaries, page-level summary lists, boundary context descriptions, or sub-file boundary anchor values.

[0039] After the merged document to be signed is generated, the system calculates the overall summary of the merged document to be signed and encapsulates the merged document to be signed, the sub-file boundary table, the batch status lock table summary, and the merged document summary to be signed into a merged document package to be verified. The merged document to be signed is generated by the merge service according to the file order in the batch status lock table; the sub-file boundary table is generated synchronously during the merge process in this step; the batch status lock table summary is calculated by serializing the batch status lock table output in step S101 according to a fixed field order; the merged document summary to be signed is calculated by the merged complete version file according to a fixed serialization rule. This merged document package to be verified serves as the input to step S103, enabling step S103 to simultaneously read the merged document body, the sub-file boundary table, and the batch status source based on the same object, and perform pre-signing consistency checks on the number of pages, page content, sub-file boundaries, boundary anchor values, and signing configuration summary.

[0040] In the complete embodiment, the batch signing task for corporate credit lines of a certain bank generates a batch status lock table through step S101, which contains the master contract. Page, Letter of Authorization Pages and attachments Page, the merge order is locked. After reading the batch status lock table in step S102, three electronic files are obtained sequentially through three encrypted file storage pointers, and a total of [number] files are generated according to the locked order. The page to be signed merged document; simultaneously forming three sub-document boundary records: the main contract corresponding to the page... Pages to number Page [number] of the authorization letter, corresponding to [page number]. Pages to number Page [page number], attachment materials correspond to page [number]. Pages to number Page. Each boundary record is bound to the corresponding file's page-level summary list, signing configuration summary, boundary context description, and sub-file boundary anchor value. The final output merged file package to be verified contains both the merged file to be signed for subsequent electronic signing and a sub-file boundary table that can prove the position, content, and contextual relationship of each original electronic file in the merged file. After reading the merged file package to be verified in step S103, a pre-signing consistency verification can be performed around the current merged file page, sub-file boundary table, and batch status lock table summary.

[0041] Step S103: Perform a pre-signing consistency check based on the merged file to be signed and the sub-file boundary table, recalculate the current overall digest, the current page-level digest list and the current sub-file boundary anchor value, generate the current boundary sequence chain and the record boundary sequence chain, compare the tail digest of the current boundary sequence chain with the tail digest of the record boundary sequence chain, and generate a signing license record if they match.

[0042] Specifically, step S103 receives the merged file package to be verified output from step S102 and performs pre-signing consistency verification based on this package. The merged file package to be verified contains the merged file to be signed, a sub-file boundary table, a batch status lock table summary, and a merged file summary to be signed. The system first uses the batch status lock table summary to read the batch status lock table formed in step S101 from the signing task storage area, and then reads the merged file to be signed and the sub-file boundary table. The batch status lock table provides the original locked file order, file page number, page-level summary list, signing configuration summary, and encrypted file storage pointer; the sub-file boundary table provides the page number boundary, page-level summary list, boundary context description, and sub-file boundary anchor value formed during the merging process in step S102; the merged file to be signed provides the actual file entity that will soon enter the electronic signature service. In bank batch merging and signing scenarios, the process from merging completion to signing call usually involves process approval, task queuing, file caching, and signing service retrieval. Within the same batch, situations may occur such as re-exporting merged files, rescanning attachments to overwrite the original attachments, switching signing configuration versions, or the task pointer pointing to another file with the same name. This step transforms these engineering risks into an executable pre-signing gate: the system rereads the current merged file to be signed, recalculates the current overall summary, current sub-file boundaries, current page-level summary, and current boundary anchor values, and performs a deterministic comparison with the records in the merged file package to be verified.

[0043] During the pre-signing consistency check, the system also checks the structural integrity of the merged file package to be verified. If any object in the merged file to be signed, the sub-file boundary table, the batch status lock table summary, or the merged file summary to be signed is missing, or the number of records in the sub-file boundary table is inconsistent with the number of files in the batch status lock table, or a sub-file boundary record lacks a de-identified file identifier, page number boundary, page-level summary list, signing configuration summary, boundary context description, or sub-file boundary anchor value, the system directly generates a signing prohibition record. This structural integrity check is performed before the summary comparison to avoid continuing to calculate the current boundary sequence chain when objects within the package are incomplete, thereby ensuring that the signing permission determination is based on complete input objects.

[0044] The system first recalculates the current overall summary of the merged documents to be signed. During the calculation, the same fixed file serialization rule used in step S102 to generate the summary of the merged documents to be signed is employed. This means that page objects, page order, page size, visible text, images, table lines, existing seal images, and layout elements in the merged documents are serialized in a fixed order and then input into the summary algorithm to obtain the current overall summary. The system compares the current overall summary with the summary of the merged documents to be signed recorded in the merged document package to be verified. If the business personnel re-exported a merged document with the same name before signing, or if the file in the signing task cache is replaced, the current overall summary will differ from the summary of the merged documents to be signed recorded in the package. Subsequently, the system regenerates the expected page number boundaries for each electronic document according to the file order and page number in the batch status lock table, following the prefix page number relationship in step S102. For example, if the batch status lock table records the main contract... Page, Letter of Authorization Pages and attachments Page, the system regains access to the main contract. Pages to number Page, Letter of Authorization Pages to number Page 1, Attachment Materials Pages to number The page number boundary is then compared item by item with the page number boundaries recorded in the sub-file boundary table. This comparison connects the number of file pages locked in step S101, the merge boundary formed in step S102, and the current file to be signed and merged read in step S103, so that missing pages, added pages, and sub-file boundary offsets can be located to specific sub-files before the signing call.

[0045] The system then extracts consecutive page segments from each sub-file in the file to be signed and merged according to the page number boundaries recorded in the sub-file boundary table, and generates the current standard page data using the standard page output rules in step S101, and then calculates the current page-level summary list. Taking the authorization letter as an example, if the page number boundary of the authorization letter in the sub-file boundary table is the... Pages to number The system extracts these three pages from the currently pending merged document, sorted by page number. Page, No. Page, No. The system generates the current standard page data in page order and calculates three current page-level summaries accordingly. These three summaries are then concatenated in page order to calculate the current page-level list summary. The system compares the current page-level list summary with the page-level list summaries recorded in the subfile boundary table. If the authorization letter... If page 1 is replaced by the rescanned version, then the page 2 of the merged document to be signed... When the standard page data corresponding to a page changes, the current page-level list summary changes accordingly; the system identifies this difference as the first page within the authorization document segment. Page. For other sub-documents such as the main contract, guarantee contract, and supporting materials, the system uses the same method to extract, calculate, and compare each segment, thereby avoiding the problem of difficulty in explaining the location of differing pages when relying solely on the overall summary.

[0046] Based on the comparison of page number boundaries and page-level content, the system recalculates the current sub-file boundary anchor value. The current sub-file boundary anchor value follows the field combination rules of step S102, and is obtained by concatenating the de-identified file identifier, the current expected page number boundary, the current page-level list summary, and the current boundary context description in a fixed field order and inputting them into the summary algorithm. The current boundary context description is obtained by serializing the batch status lock table summary, the current page-level list summary of the previous electronic file, the current page-level list summary of the next electronic file, and the signing configuration summary. For the first electronic file, a fixed start marker is written at the previous position; for the last electronic file, a fixed end marker is written at the next position. This process ensures that the verification result of a single sub-file is simultaneously constrained by its own page content, merge position, the relationship between preceding and following files, and the signing configuration version. For example, if the content of the authorization letter page remains the same, but the authorization letter is moved to the attachment materials, the current page-level list summary of the authorization letter can remain the same, but the relationship between the preceding and following documents in the current boundary context description changes. The recalculated current sub-file boundary anchor value is different from the sub-file boundary anchor value recorded in the sub-file boundary table. If the signing configuration corresponding to the authorization letter is switched from version V3 to version V4, the change in the signing configuration summary will also be included in the current boundary context description, causing the recalculated current sub-file boundary anchor value to change.

[0047] The system then generates a boundary order closed chain. This chain calculation originates from the hash chain algorithm in cryptographic integrity verification. The original idea is to input the digest of the previous node and the data of the current node into the digest algorithm, so that any change in the data or order of any node will propagate to the tail digest. This application applies this idea to the scenario of batch merging and signing of electronic documents in banks. The boundary anchor value and page number boundary of each sub-file are used as the chain node data, and the batch status lock table digest is used as the chain starting point, so that the file order, page number boundary, page content, and batch source of the entire batch are merged into a comparable tail result. The system generates a current boundary order chain and a record boundary order chain respectively. The current boundary order chain uses the current sub-file boundary anchor value and the current expected page number boundary obtained by recalculation in this step, and the record boundary order chain uses the sub-file boundary anchor value and page number boundary recorded in the sub-file boundary table. The two chains use the same starting point and the same recursive method: ; in, This indicates that the system recursively calculates up to the next step based on the currently pending merged documents. The current boundary order chain digest obtained when creating a sub-file; This indicates that the system recursively calculates to the next level based on the sub-file boundary table records. A summary of the record boundary sequence chain obtained when creating a sub-file; Indicates the first The current subfile boundary anchor value of the subfile is recalculated by the system in this step according to the field combination rules of step S102. The recalculation uses the de-identified file identifier, the current expected page number boundary, the current page level list summary, and the current boundary context description. This indicates the first record in the subfile boundary table. Sub-file boundary anchoring values; This indicates that the system recalculated the first batch based on the batch status lock table. Expected page number boundaries for component documents; This indicates the first record in the subfile boundary table. Sub-document page number boundaries; This represents a summary of the batch status lock table in the merged file package to be verified, and serves as the common starting point for the two boundary sequence chains; This refers to a deterministic digest algorithm, which originates from cryptographic digest algorithms; This indicates byte concatenation in a fixed field order. The formula is derived from the recursive structure of a hash chain. Node data is limited to sub-file boundary anchor values ​​and page number boundaries in a bank consolidation signing scenario. The chain starting point is limited to the batch status lock table digest, thus connecting the batch lock status of step S101 and the sub-file boundary structure of step S102 into the pre-signature verification object of step S103. The current page-level list digest is used for recalculation. The input enters the boundary sequence chain, and then through... The link tail summary reflects the page content validation results.

[0048] In the public credit granting implementation, the number of sub-files is: The summary of the batch status lock table is as follows: The three sub-files are the main contract, the authorization letter, and the supporting documents. The system first uses the current sub-file boundary anchor value of the main contract. and expected page number boundaries calculate Then use the current sub-file boundary anchor value of the authorization letter. and expected page number boundaries calculate Finally, use the current subfile boundary anchor value from the attachment material. and expected page number boundaries calculate Meanwhile, the system uses the sub-file boundary table as a reference. , , , , , Calculate the record boundary sequence chain to obtain During interface integration testing, if the serialization input of a certain chain node is the test byte string "abc", then the corresponding... The calculation result is ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad; In actual operation of the banking system, the chain node input consists of the previous chain node summary, subfile boundary anchor values, and the actual serialization result of the page number boundaries. If the order of the authorization letter and attachments is interchanged, the chain node input order changes, and the chain tail summary changes accordingly; if the authorization letter boundary is changed by… Become When the page number boundaries in a chain node change, the chain tail summary also changes accordingly.

[0049] The signing license determination employs the conjunction relation from mathematical logic. The original meaning of the conjunction relation is that the overall proposition is true when multiple propositions are true simultaneously; this application uses this logical relation as a pre-signing gate, taking overall digest consistency and boundary sequence chain consistency as the final licensing conditions. Boundary sequence chain consistency already includes the consistency of each sub-file boundary anchor value and page number boundary. The sub-file boundary anchor value is generated jointly by the de-identified file identifier, page number boundary, page-level list summary, batch context, and signing configuration summary. Therefore, this licensing condition can cover overall file replacement, sub-file page offset, page content changes, sub-file order changes, and signing configuration changes. The system generates the signing license determination value using the following formula: ; in, This indicates the signing permission determination value, used to determine whether to generate a signing permission record or a signing prohibition record; This indicates the current overall summary obtained by the system in this step after recalculating the currently pending merged documents; This indicates that the summary of the merged file to be signed, recorded in the merged file package to be verified, originates from step S102; This indicates that the current boundary sequence chain is recursively pushed to the th... The end-of-chain summary following the sub-file; This indicates that the record boundary sequence chain is recursively pushed to the th... The end-of-chain summary following the sub-file; The number of subfiles is derived from the number of records in the subfile boundary table; symbol This indicates logical conjunction. The equation within the square brackets is true when the corresponding proposition is true; if both propositions are true, then... Take the truth value.

[0050] Includes the main contract, power of attorney, and supporting documents. Taking page merging files as an example, the system recalculates the current overall summary. and merge with the file package to be verified Compare; then, based on the boundary records of the three sub-files and the current page recalculation result, recursively derive... And based on the original records of the sub-file boundary table, it is recursively obtained .when and hour, If true, the system generates a signed license record. If the authorization letter is true... The page was replaced, and the system extracted the first page. Pages to number When calculating the current page-level list summary, a different result is obtained than the subfile boundary table. The current subfile boundary anchor value changes accordingly, and the current boundary sequence tail summary is updated. Summary of record tail Inconsistent False. If the entire file is replaced by another merged file with the same name, the current overall summary will be false, even if the subfile boundary table still exists with the package. With record summary Inconsistent It is also false.

[0051] The system in When true, a signing permission record is generated. The signing permission record includes the following: a summary of the file to be signed and merged, a batch status lock table summary, a sub-file boundary table summary, a boundary order chain tail summary, a set of signing configuration summaries, verification time, and the identifier of the merged file package to be verified. The set of signing configuration summaries is formed by summarizing the signing configuration summaries of each sub-file in the sub-file boundary table in file order, and is used in step S104 to read and match the corresponding signing configuration from the bank's signature management system. The summary of the file to be signed and merged is used in step S104 to locate the same file to be signed and merged; the batch status lock table summary indicates the lock status of the permission record in step S101; and the sub-file boundary table summary and the boundary order chain tail summary indicate the boundary structure formed in step S102. The system in... If the result is false, a signing prohibition record is generated, recording the difference type, corresponding de-identified file identifier, corresponding page number boundary, difference page sequence, verification time, and identifier of the merged file package to be verified, and the batch signing call is terminated. After receiving the signing permission record in step S104, the actual electronic signing is performed based on the digest of the merged file to be signed and the set of signing configuration digests contained therein.

[0052] After a signing license record is generated, the system writes the record's status to the signing task storage area and establishes a one-time binding relationship between it and the identifier of the merged file package to be verified and the summary of the merged file to be signed. This binding relationship restricts the same license record to be consumed only once in step S104. The validity period of the signing license record is configured by the signing task management system according to the business type and written into the license record when it is generated. This validity period must not exceed the validity period of the electronic signature service session or the validity period of the certificate call session. If the queuing time of the signing task exceeds this validity period, or if the merged file package to be verified is rewritten after the license is granted, the system sets the license record to an invalid state and requires re-execution of step S103. This process avoids the deviation between the actual signing object and the licensed object due to asynchronous queuing, cache replacement, or concurrent task retrieval after the pre-signing verification is passed.

[0053] Step S104: Perform electronic signature on the merged document to be signed according to the signing permission record to generate a signed merged document, and encapsulate the signed merged document summary, signing permission record, sub-document boundary table summary and boundary sequence chain tail summary into an archiveable evidence package.

[0054] Specifically, step S104 receives the signing permission record generated in step S103 and completes the batch merging and signing of bank electronic documents based on the record, generating signed merged documents and archiveable evidence packages. The identifier of the merged document package to be verified in the signing permission record is used to read the merged document package to be verified formed in step S102 from the signing task storage area. The summary of the merged document to be signed is used to lock the file object that will soon enter the electronic signature service. The batch status lock table summary is used to associate the batch file status fixed in step S101. The sub-file boundary table summary is used to associate the sub-file boundary structure formed in step S102. The boundary order chain tail summary is used to associate the batch order verification result completed in step S103. The signing configuration summary set is used to read the corresponding signing configuration from the bank signature management system. The verification time is used to record the pre-signing verification time point on which the signing action is based. The system uses these fields to limit the signing action to the same merged document to be signed that has already completed pre-signing consistency verification, ensuring that the final signing result simultaneously corresponds to the original batch status, merged document boundaries, and pre-signing permission result.

[0055] The system first reads the merged file package to be verified from the signing task storage area based on the identifier of the merged file package to be verified in the signing permission record, and obtains the merged file to be signed and the sub-file boundary table from the package. Then, the system recalculates the digest of the merged file to be signed according to the fixed file serialization rule used in step S102, and confirms the consistency of the calculation result with the merged file digest to be signed in the signing permission record. This fixed file serialization rule follows the merged file generation rule of step S102, serializing page objects, page order, page size, page orientation, visible text, images, table lines, existing seal images, and layout elements in a fixed order before inputting them into the digest algorithm. Through this process, the system reconfirms that the currently obtained file entity is consistent with the file entity permitted in step S103 before calling the electronic signature service. For example, a batch of corporate credit granting documents, with a merged file digest permitted in step S103, corresponds to a total of... For merged files, the system recalculates the page count before signing. The document summary is used as the basis for locating the document for signing services, and the consistency between this summary and the summary of the merged document to be signed in the signing license record is used as the basis for locating the document.

[0056] If the summary of the merged document to be signed, recalculated in step S104, is inconsistent with the signing license record, or if the signing license record has been consumed, expired, or revoked, the system will not invoke the electronic signature service. Instead, it will generate a signing execution failure record and transfer the batch back to the pre-signing consistency verification process. This execution failure record will at least include the identifier of the merged document package to be verified, the license record identifier, the current summary, the license summary, the reason for failure, and the processing time. By re-verifying the license status and document entity before the actual signing is invoked, this step extends the pre-signing gate of step S103 to the signing service entry point, avoiding the risk of a time window between the license record and the actual signed document.

[0057] The system reads the corresponding signing configuration record from the bank's signature management system based on the set of signing configuration digests in the signing license record. The signing configuration record includes a configuration version number, applicable file type, signature type, authorized signing entity code, signature service identifier, and certificate invocation identifier. The system serializes the read signing configuration record according to a fixed field order, calculates a digest, and matches it with the set of signing configuration digests in the signing license record. After matching, the system submits the file to be signed, the signature type, authorized signing entity code, signature service identifier, and certificate invocation identifier to the bank's electronic signature service. For PDF files, the electronic signature service writes electronic signature data into the PDF incremental update structure or signature field and generates a visual signature representation in the specified page area according to the signing configuration record. For OFD files, the electronic signature service writes electronic signature data into the OFD signature node and generates the corresponding signature appearance. The bank's electronic signature service generates the signature value through a controlled certificate service or key device and returns the signature value digest, certificate digest, signing time, and timestamp information. After receiving the results from the electronic signature service, the system obtains the signed merged document and calculates the summary of the signed merged document according to the fixed document serialization rules.

[0058] Because the electronic signature service may write new signature objects into the PDF incremental update structure, OFD signature nodes, or visual signature appearance area, the system distinguishes between pre-signature page content verification and post-signature electronic signature verification. The page-level digests in steps S101 to S103 are used to verify the pre-signature business page content, page order, and sub-file boundaries; the signed merged file digest, signature value digest, certificate digest, and timestamp information in step S104 are used to verify the signed file entity and signature object. When subsequently splitting sub-files from the signed merged file and recalculating the page-level digest, the standard page output rules exclude signature objects, timestamp objects, and identifiable signature appearance objects written by the electronic signature service, generating standard page data only for the pre-signature business page content; the signature object itself is verified through whole-file signing and evidence package anchored digests. This distinction avoids inconsistencies arising from direct comparison between the pre-signature page-level digest and the post-signature page after the visual signature appearance changes the page display layer.

[0059] In banking operations, signed consolidation documents typically serve as both business archives and the basis for customer access, internal review, and external evidence presentation. Taking the corporate credit batches described in steps S102 and S103 as an example, there are a total of [number missing] consolidation documents to be signed. Page [page number], where the main contract corresponds to [page number]. Pages to number Page [number] of the authorization letter, corresponding to [page number]. Pages to number Page [page number], attachment materials correspond to page [number]. Pages to number Page. After step S104 invokes the electronic signature service, the electronic signature structure, visual signature representation, and time information are written to this page. The system merges the pages to form a signed merged file. It also retains the signature value digest, certificate digest, and timestamp information returned by the signing service, and incorporates these signing results, along with the signing license record, sub-file boundary table, batch status lock table digest, and boundary order chain tail digest, into the evidence encapsulation process.

[0060] The archiveable evidence package uses a digest anchoring method to generate an anchor digest. The algorithm for this calculation originates from the SHA-256 digest algorithm and the digest binding concept in cryptography. The original purpose of SHA-256 is to convert any input byte string into a fixed-length digest; the digest binding concept concatenates the digests of multiple objects in a fixed field order and then performs another digest, making multiple objects form the same integrity anchor point. This application extends this concept to the scenario of batch merging and signing electronic documents in banks, using the digest of the signed merged document, the digest of the signing permission record, the digest of the sub-file boundary table, and the digest of the boundary order chain tail as input fields, so that the signed document entity, the permission status before signing, the sub-file boundary structure, and the batch order verification result are all bound together. The evidence package anchor digest is generated according to the following formula: ; in, This indicates that the anchored summary of the evidence package is calculated by the system and written into the archiveable evidence package. This indicates that the merged document summary has been signed. It is calculated by the system from the signed merged document returned by the electronic signature service according to fixed document serialization rules. The signature license record summary is calculated by the system after serializing the following data in the signature license record: the summary of the merged file to be signed, the batch status lock table summary, the sub-file boundary table summary, the boundary order chain tail summary, the signature configuration summary set, the verification time, and the identifier of the merged file package to be verified, according to a fixed field order. This represents the sub-file boundary table summary, calculated by the system after serializing the de-identified file identifier, file type, page number boundary, page-level summary list, signature configuration summary, boundary context description, and sub-file boundary anchor value in a fixed field order within the sub-file boundary table. Consistent with the sub-file boundary table summary recorded in the signing license record; This indicates that step S103 generates and writes the boundary order chain tail digest of the signed license record; Deterministic digest algorithm; This indicates byte concatenation in a fixed field order. The formula is derived from the idea of ​​digest binding; the input side consists of four defined digest fields, and the output side consists of a fixed-length digest field. Any change in any input field will result in... The changes solidify the signed document status, the pre-signing license status, the sub-file boundary structure, and the batch sequence verification results into the same archiving anchor point.

[0061] In engineering calculations, the system first obtains... , , and For example, after the electronic signature service returns a signed merged document, the system calculates the following for that document: The system serializes and calculates the fields of the signed license record in a fixed order. The system serializes each record in the subfile boundary table according to the file order and calculates the result. and the The system performs consistency verification with the sub-file boundary table summary in the signing license record; the system reads the data generated in step S103 from the signing license record. Then, the system will , , and Concatenate the bytes into a single input byte string in a fixed order, then execute. The calculation yields During interface integration testing, if the concatenated test input byte string is "abc", the calculated digest result is ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad; in actual operation of the banking system, the input byte string consists of the actual serialization results of the above four fields. If the previously signed merged file is replaced, Changes; if the signed license record is replaced, Changes; if the page number boundaries of the authorization document are modified in the sub-file boundary table, Change; if the order verification result of sub-files within the batch is replaced, Change; any change will yield different evidence packages anchored in the summary. .

[0062] When the system generates an archiveable evidence package, it writes the following into the same evidence structure: signed merged document digest, signing permission record, batch status lock table digest, sub-file boundary table and its digest, boundary sequence chain tail digest, evidence package anchoring digest, signature value digest, certificate digest, signing time, timestamp information, and archive storage pointer. The signed merged document digest comes from the digest calculation result of the file returned by the electronic signature service; the signing permission record comes from step S103; the batch status lock table digest comes from the signing permission record and corresponds to the batch status lock table generated in step S101; the sub-file boundary table comes from the merged document package to be verified and corresponds to the boundary record generated in step S102; the boundary sequence chain tail digest comes from step S103; the signature value digest, certificate digest, signing time, and timestamp information come from the results returned by the bank's electronic signature service or timestamp service; the archive storage pointer is generated by the bank's archive system when it receives the signed merged document and the archiveable evidence package, and is used to locate the archived object later. The document source, signing subject, and archive location in the archiveable evidence package are represented by a de-identified document identifier, a digest field, and a controlled storage pointer. The bank's archive system reads the complete archived document through the access control interface.

[0063] After receiving the signed merged document and the archiveable evidence package, the archiving system establishes a one-to-one correspondence between the two and saves the archive storage pointer. During the final signing process, the system reads the signed merged document, verifies the electronic signature value, certificate digest, and timestamp information, and recalculates the signed merged document digest, comparing it with the data in the archiveable evidence package. A comparison was performed; subsequently, the signature authorization record summary, sub-document boundary table summary, and evidence package anchoring summary were recalculated and compared with those in the archiveable evidence package. , and A comparison is performed. When splitting a sub-file, the system reads the sub-file boundary table from the archived evidence package. For example, the authorization letter corresponds to the... Pages to number Page [number], the system extracts the [number]th page from the signed merged document. Page, No. Page and The system calculates the page number of the split page and regenerates the page-level summary list for that page segment according to the standard page output rules in step S101. If the recalculated page-level summary list matches the page-level summary list corresponding to the authorization in the sub-file boundary table, the system confirms that the split authorization originates from the original authorization page segment in the signed merged file. If the split file lacks the first... Page, or the When a page is replaced with another version, the recalculated page-level summary list differs from the page-level summary list recorded in the subfile boundary table. The system is able to locate the differing page in the corresponding page segment of the authorization document.

[0064] During the split verification process, if the requested page range does not fall within any consecutive page segment in the sub-file boundary table, or if the requested page segment crosses two sub-file boundaries, the system does not output a verifiable sub-file but instead generates a split out-of-bounds record. If the requested sub-file page segment matches the boundary table, but the regenerated page-level summary list is inconsistent with the boundary table, the system outputs a split failure result and records the difference page order. Only if the entire document passes the verification, the evidence package anchor summary is consistent, the requested page segment falls within a single sub-file boundary, and the page-level summary list is consistent, will the system output the split file and its source verification result. This process ensures that the retrieval of archived sub-files is not simply extracted page by page, but forms a closed loop together with pre-signature boundary fixing, post-signature entire document verification, and page-level content review.

[0065] This step ultimately outputs the signed merged document and an archiveable evidence package. The signed merged document is generated by the bank's electronic signature service based on the merged document to be signed bound in the signing permission record, and includes the electronic signature structure, visual signature appearance, and time information. The archiveable evidence package is generated by the system based on the signing permission record, sub-file boundary table, batch status lock table summary, boundary sequence tail summary, and signing result encapsulation. Through this processing, the bank's electronic document batch merging and signing process completes the actual signing action and connects the pre-signing consistency verification, sub-file boundary binding, and post-signing archiving results into the same evidence structure.

[0066] This application also provides a system for batch merging and signing electronic documents in banks, such as... Figure 4 As shown, it includes: The batch status locking module is used to obtain the business batch identifier, the list of documents to be signed, and the business document type; perform page normalization processing on the electronic documents in the list of documents to be signed to obtain standard page data, and calculate the page-level summary of each page in the electronic documents; generate a signing configuration summary and a batch status locking table, wherein the batch status locking table records the de-identified file identifier, file type, file order, number of pages, page-level summary list, signing configuration summary, and encrypted file storage pointer of the electronic documents; The file merging and boundary generation module is used to read the electronic files in the order of the files according to the batch status locking table, add pages to generate a merged file to be signed, and generate a sub-file boundary table. The sub-file boundary table records the page number boundaries, page-level summary list, boundary context description and sub-file boundary anchor values ​​of the electronic files in the merged file to be signed. The pre-signing consistency verification module is used to perform pre-signing consistency verification based on the merged file to be signed and the sub-file boundary table, recalculate the current overall digest, the current page-level digest list and the current sub-file boundary anchor value, generate the current boundary sequence chain and the record boundary sequence chain, compare the tail digest of the current boundary sequence chain with the tail digest of the record boundary sequence chain, and generate a signing license record when they are consistent. The electronic signature recall module is used to perform an electronic signature on the document to be signed and merge it according to the signing permission record to generate a signed and merged document. The evidence package encapsulation module is used to encapsulate signed merged document digests, signing license records, sub-file boundary table digests, and boundary order chain tail digests into archiveable evidence packages.

[0067] It is worth noting that the specific workflow of the bank electronic document batch merging and signing system provided in this embodiment of the invention is the same as that of the bank electronic document batch merging and signing method described in the above embodiment, and will not be repeated here.

[0068] The above description represents the preferred embodiments of the present invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of the present invention, and these improvements and modifications are also considered to be within the scope of protection of the present invention.

Claims

1. A method for batch merging and signing electronic bank documents, characterized in that, include: Obtain the business batch identifier, the list of documents to be signed, and the business document types; The electronic documents in the list of documents to be signed are subjected to page normalization processing to obtain standard page data, and the page-level summary of each page in the electronic documents is calculated; Generate a signing configuration summary and a batch status lock table. The batch status lock table records the de-identified file identifier, file type, file order, number of pages, page-level summary list, signing configuration summary, and encrypted file storage pointer of the electronic file. According to the batch status lock table, the electronic files are read in file order to append pages and generate a merged file to be signed. At the same time, a sub-file boundary table is generated. The merged file to be signed, the sub-file boundary table, the summary of the batch status lock table, and the summary of the merged file to be signed are encapsulated into a merged file package to be verified. The sub-file boundary table records the page number boundaries, page-level summary list, boundary context description, and sub-file boundary anchor values ​​of the electronic files in the merged file to be signed. Based on the merged file to be signed and the sub-file boundary table, perform a consistency check before signing, recalculate the current overall digest, the current page-level digest list and the current sub-file boundary anchor value, generate the current boundary sequence chain and the record boundary sequence chain, compare the tail digest of the current boundary sequence chain with the tail digest of the record boundary sequence chain, and generate a signing license record when the two are consistent. Based on the signing permission record, an electronic signature is performed on the merged document to be signed to generate a signed merged document. The summary of the signed merged document, the signing permission record, the summary of the sub-document boundary table, and the summary of the boundary sequence chain tail are encapsulated into an archiveable evidence package.

2. The method for batch merging and signing bank electronic documents according to claim 1, characterized in that, The step of normalizing the electronic documents in the list of documents to be signed to obtain standard page data includes: The page object of the electronic file is read through the file parsing interface, and the visible text, table lines, images, QR codes, existing seal images, headers and footers and fixed layout elements are retained. Standard page data is formed according to fixed page output rules. The calculation of page-level summaries for each page in the electronic file includes: The standard page data of the page is used as input, and a page-level digest is calculated using a deterministic digest algorithm. The page-level digest is then written into the batch status lock table.

3. The method for batch merging and signing bank electronic documents according to claim 1, characterized in that, The methods for generating the de-identified file identifier include: The internal file number, business batch identifier, and file receipt sequence number of the electronic file are concatenated in a fixed field order and then processed into a summary to obtain a string used to uniquely locate the file within the batch.

4. The method for batch merging and signing bank electronic documents according to claim 1, characterized in that, The methods for generating the sub-file boundary anchor values ​​include: The page-level summary list of the electronic document is calculated by concatenating the page-level summary list in page order; The batch status lock table summary, the page-level list summary of the preceding electronic file, the page-level list summary of the following electronic file, and the signature configuration summary are serialized in a fixed field order to obtain a boundary context description. For the electronic file that is first in the sort, a fixed start marker is written in the previous position; for the electronic file that is last in the sort, a fixed end marker is written in the next position. The de-identified file identifier, the page number boundary, the page-level list summary, and the boundary context description are concatenated in a fixed field order and then input into a summary algorithm to obtain the sub-file boundary anchor value.

5. The method for batch merging and signing bank electronic documents according to claim 1, characterized in that, The generation of the current boundary sequence chain and the recording of the boundary sequence chain include: The batch status lock table summary in the merged file package to be verified is used as the starting point of the chain; The sub-file boundary anchor values ​​and page number boundaries of the electronic file are used as chain node data in the order of the files. The previous chain node summary and the current chain node data are concatenated in a fixed field order and then input into the summary algorithm to recursively obtain the current boundary order chain. Based on the sub-file boundary anchor values ​​and page number boundaries recorded in the sub-file boundary table, the same chain starting point and recursive method are used to obtain the record boundary sequence chain.

6. The method for batch merging and signing bank electronic documents according to claim 1, characterized in that, The pre-signature consistency verification also includes: The structural integrity of the merged file package to be verified is checked. If any object of the merged file to be signed, the sub-file boundary table, the batch status lock table summary, or the merged file summary to be signed is missing, or if the number of records in the sub-file boundary table is inconsistent with the number of files in the batch status lock table, a signing prohibition record is generated. Recalculate the current overall summary and compare it with the summary of the merged file to be signed recorded in the merged file package to be verified; The expected page number boundaries are regenerated based on the file order and file page number in the batch status lock table, and compared item by item with the page number boundaries recorded in the sub-file boundary table; Based on the page number boundaries recorded in the sub-file boundary table, consecutive page segments are extracted one by one from the electronic files in the merged file to be signed, generating current standard page data and calculating the current page-level summary list, which is then compared with the page-level summary list recorded in the sub-file boundary table.

7. The method for batch merging and signing bank electronic documents according to claim 1, characterized in that, The conditions for generating the signing license record include: The current overall summary is consistent with the summary of the merged document to be signed recorded in the merged document package to be verified; The current boundary sequence tail digest is consistent with the record boundary sequence tail digest; When both of the above conditions are met, a signing license record is generated. The signing license record contains the following: summary of the merged file to be signed, summary of the batch status lock table, summary of the sub-file boundary table, summary of the boundary order chain tail, set of signing configuration summaries, verification time, and identifier of the merged file package to be verified. If any of the above conditions are not met, a signing prohibition record will be generated.

8. The method for batch merging and signing bank electronic documents according to claim 1, characterized in that, The method further includes: Establish a one-time binding relationship between the signing license record and the identifier of the merged file package to be verified and the summary of the merged file to be signed, restricting the same signing license record to be consumed only once; Set the validity period of the signing permission record, which shall not exceed the validity period of the electronic signature service session or the validity period of the certificate retrieval session; If the signing task queue time exceeds the effective duration, or if the merged file package to be verified is rewritten after the license is granted, the signing license record will be set to invalid and the pre-signing consistency verification will be re-executed.

9. The method for batch merging and signing bank electronic documents according to claim 1, characterized in that, The packaged evidence is archived and includes: The signed merged document digest, signing license record digest, sub-document boundary table digest, and boundary order chain tail digest are concatenated in a fixed field order and then input into the digest algorithm to calculate the evidence package anchor digest. The signed merged document digest, signing license record, batch status lock table digest, sub-file boundary table and sub-file boundary table digest, boundary sequence chain tail digest, evidence package anchoring digest, signature value digest, certificate digest, signing time, timestamp information and archive storage pointer are written into the same evidence structure to obtain an archiveable evidence package.

10. A batch merging and signing system for bank electronic documents, characterized in that, include: The batch status locking module is used to obtain the business batch identifier, the list of documents to be signed, and the business document type; The electronic documents in the list of documents to be signed are subjected to page normalization processing to obtain standard page data, and the page-level summary of each page in the electronic documents is calculated; Generate a signing configuration summary and a batch status lock table. The batch status lock table records the de-identified file identifier, file type, file order, number of pages, page-level summary list, signing configuration summary, and encrypted file storage pointer of the electronic file. The file merging and boundary generation module is used to read the electronic files in file order according to the batch status lock table to add pages and generate a merged file to be signed, and at the same time generate a sub-file boundary table. The module encapsulates the merged file to be signed, the sub-file boundary table, the summary of the batch status lock table, and the summary of the merged file to be signed into a merged file package to be verified. The sub-file boundary table records the page number boundaries, page-level summary list, boundary context description, and sub-file boundary anchor values ​​of the electronic files in the merged file to be signed. The pre-signing consistency verification module is used to perform pre-signing consistency verification based on the merged file to be signed and the sub-file boundary table, recalculate the current overall digest, the current page-level digest list and the current sub-file boundary anchor value, generate the current boundary sequence chain and the record boundary sequence chain, compare the tail digest of the current boundary sequence chain with the tail digest of the record boundary sequence chain, and generate a signing license record when the two are consistent. The electronic signature recall module is used to perform an electronic signature on the document to be signed and merge it according to the signing permission record to generate a signed and merged document. The evidence package encapsulation module is used to encapsulate signed merged document digests, signing license records, sub-file boundary table digests, and boundary order chain tail digests into archiveable evidence packages.

Images