Multi-source heterogeneous shared result credible solidification method and system for provident fund business
Patent Information
- Application Number
- CN202610727340.7
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-05-25
- Publication Date
- 2026-09-15
Smart Images
Figure CN122758445A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of data processing technology, and in particular to a method and system for reliable solidification of multi-source heterogeneous shared results for housing provident fund business. Background Technology
[0002] The business processing model of the Housing Provident Fund Management Center (hereinafter referred to as the "Provident Fund Center") has been transformed from traditional offline counter processing to online and cross-departmental collaborative processing. A typical provident fund loan transaction often requires frequent data exchange and business collaboration between the Provident Fund Center and multiple external institutions such as commercial banks, real estate registration centers, tax authorities, and human resources and social security departments. In this process, a massive amount of business data with diverse sources and formats is generated, namely multi-source heterogeneous shared data.
[0003] Currently, for financial business data involving significant public welfare, there are four main technical bottlenecks in the sharing, solidification, evidence storage, and post-audit stages:
[0004] 1. Insufficient assurance of data source credibility: Existing data sharing mechanisms mostly rely on security authentication at the interface protocol level, such as HTTPS two-way authentication and API keys. These mechanisms can ensure the security of data transmission channels, but they cannot provide tamper-proof evidence of the received data content itself. In the event of a business dispute, the housing provident fund center can hardly prove that the original state of a certain bank approval message or a certain piece of real estate registration information it received was tamper-proof at the time of receipt, that is, it lacks an effective means of securing the "first scene" of the data.
[0005] 2. Fixed Format and Lack of Legal Validity for Important Business Documents: Key documents in housing provident fund transactions, such as the "Loan Acceptance Notice," "Approval Result Notification," and "Loan Disbursement Confirmation," are important legal documents. Currently, these documents are mostly in JSON / XML message format or dynamically generated PDF files through code. This approach has two major drawbacks: First, although the PDF format can fix the format, it is not my country's national standard format for electronic document storage and exchange (GB / T 33190-2016), making it weaker than the OFD format in terms of long-term archiving and legal validity. Second, the generated PDF files often lack electronic signatures that comply with national cryptographic standards, or the signatures are not closely related to the document content itself, making it difficult to independently verify the authenticity and integrity of the documents during subsequent circulation.
[0006] 3. Insufficient Identity Authentication and Non-Repudiation Strength for Large-Value Transactions: For transactions involving significant financial security, such as housing provident fund loan approvals and large withdrawals, existing systems often employ weak authentication methods like "username + password + SMS verification code," or rely on bank-side USB token authentication. For customers, there is a lack of a direct, convenient, and legally valid electronic signature method to express their final confirmation of the transaction. This results in a lack of sufficiently strong electronic evidence to reconstruct the customer's true intentions when a customer denies the transaction.
[0007] 4. Low efficiency and incomplete evidence chain in post-audit verification: When reviewing historical business transactions, auditors typically need to retrieve interface logs, business data, electronic vouchers, and signature records from multiple systems, manually comparing data and verifying signature validity. This process is not only inefficient, but also makes it difficult to form a complete and reliable evidence chain from "data reception" to "voucher generation" and then to "customer confirmation" because the data is stored independently in each system. In particular, there is a lack of effective technical means to trace whether a particular OFD voucher was faithfully generated from the original message received at the time.
[0008] Therefore, there is an urgent need for an innovative technical solution that can organically integrate the reception and storage of multi-source heterogeneous data, the OFD format solidification of important documents, the CA electronic signature for large transactions, and post-audit and signature verification, to build a trusted solidification and verification system covering the entire data lifecycle, in order to solve the above-mentioned technical problems. Summary of the Invention
[0009] The present invention aims to at least partially solve one of the technical problems in the related art.
[0010] Therefore, the first objective of this invention is to propose a reliable method for solidifying multi-source heterogeneous shared results in housing provident fund business, comprising the following steps: S1, receives raw business data from different external business systems through multiple communication protocols, and parses the raw business data to obtain message content, data source identifier and receiving timestamp; S2, based on the preset data mapping model, the parsed original business data is converted into a standardized data object containing metadata header, and the standardized data object is subjected to the first hash calculation to obtain the first hash value. The first hash value and business association information are stored in the blockchain network to complete the data source evidence storage. S3. Identify key business messages based on the business type in the standardized data object, generate a format file using the matching format template, perform institutional digital signature processing on the format file to obtain a signed format file, perform secondary hash calculation on the signed format file to obtain a second hash value, and store the second hash value in the blockchain network to complete the certificate solidification and notarization. S4, in response to an audit and verification request for the target business, obtains the corresponding standardized data object, signature format file and evidence storage certificate from the storage medium and the blockchain network, automatically verifies the data integrity, format file integrity and the validity of the organization's digital signature according to the preset verification rules, and generates a structured audit report containing the verification results.
[0011] In one embodiment of the present invention, S2 includes: S21, call the configurable data mapping model library to dynamically map specific fields in the parsed original business data to internal standard format fields; S22, use the data transformation engine to uniformly convert all key business fields into a standardized data body in JSON format, and forcibly attach a metadata header containing sourceSystem, receiveTimestamp, businessType and businessSerialNo fields to the top layer of the standardized data body to generate a complete standardized data object; S23, use the SM3 algorithm to perform hash calculation on the string content of the complete standardized data object to generate the first hash value; S24, call the smart contract interface of the blockchain evidence storage network of the consortium blockchain architecture, package the first hash value, business serial number, data source identifier, receiving timestamp and original length into a transaction and submit it to the blockchain network. After consensus is reached, obtain the evidence storage certificate containing block height, transaction hash value and on-chain time, and complete the data source evidence storage.
[0012] In one embodiment of the present invention, S22 includes: S221, Match the corresponding mapping rule from the data mapping model library according to the data source identifier. For the ISO 8583 message of Bank A, read the preset rule to extract the transaction amount data of the 4th field and assign it to the standardized field transactionAmount, and extract the transmission date and time data of the 7th field and assign it to the standardized field transmissionDateTime. S222. For the XML data of the real estate registration system, perform XPath parsing to locate the / Response / Body / PropertyInfo / Address node, extract the text content under this node and assign it to the standardized field propertyAddress, and obtain the mapped set of key business fields to generate standardized data objects.
[0013] In one embodiment of the present invention, S3 includes: S31, Read the businessType field value in the standardized data object. When the businessType field value is LOAN_RECEIPT, APPROVAL_NOTICE, or LOAN_DISBURSEMENT, it is determined to be a critical business message. S32, based on the judgment result, match the corresponding template or approval result notification template from the OFD template management unit, fill the loan amount, loan term and borrower name of the businessData part of the standardized data object into the template preset placeholders, and generate an OFD layout file; S33, using the unit's digital certificate stored in the hardware encryption machine or server certificate store, call the electronic signature middleware to digitally sign the OFD format file, embedding the signature value, certificate serial number and signature time into the signature field of the OFD file, to obtain a signed format file with the organization's digital signature; S34, the SM3 algorithm is used to perform hash calculation on the binary stream of the signature version file to obtain a second hash value, and the second hash value, together with the business serial number and OFD file version information, is written into the blockchain ledger to obtain a second certificate of evidence to complete the certificate solidification and evidence preservation.
[0014] In one embodiment of the present invention, S33 includes: S331, Load the corresponding unit's digital certificate private key and initialize the electronic signature middleware; S332, perform a digest operation on the content of the OFD format file, and use the private key of the unit's digital certificate to perform an encryption operation on the digest value to generate a digital signature value; S333, the digital signature value, certificate serial number, signature time, and certificate chain information are encapsulated in a standardized format and embedded into a dedicated signature field within the OFD format file.
[0015] In one embodiment of the present invention, the method further includes executing a large-value transaction triggering CA electronic visa process during the business approval or contract signing stage, specifically including: Read the value of the transactionAmount field in the standardized data object and compare it with a preset threshold, or read the risk level marked by the risk control system. When the transaction amount exceeds the threshold or the risk level is marked as high risk, the CA electronic visa process is automatically triggered. Extract the business transaction number, business type, transaction amount, transaction date, customer name, ID number, and key contract terms to form a deterministic structured text string. Use the SM3 algorithm to calculate the hash value of the text string as the business data digest to be signed. Send a visa request to the client terminal, and receive a digital signature value generated by the client after authorizing through biometrics or payment password by calling the private key of the personal CA digital certificate to perform a signature operation on the business data digest; The CA authentication server interface is called to verify the validity of the digital signature value and the legality of the certificate. After the verification is successful, the digital signature value, certificate serial number and signature timestamp are permanently bound and stored with the standardized data object and signature template file, and recorded in the audit log.
[0016] In one embodiment of the present invention, S4 includes: S41, retrieve the original first hash value from the blockchain network based on the business transaction number. Retrieve standardized data objects stored in the database and recalculate their hash values. ,like The data integrity verification is then deemed successful. S42, retrieve the stored signature template file and recalculate its hash value. , and the second hash value stored on the blockchain Perform a comparison, if The integrity verification of the layout file is then deemed successful. S43, parse the digital signature field in the signature format file, verify the mathematical validity of the signature, whether the signature certificate is a trusted provident fund center certificate, and whether the signature certificate is valid at the time of signing, and generate the institution's digital signature validity verification result. S44. Based on the Boolean values and detailed verification information of the above verification results, the data receiving log, standardized data record, initial evidence certificate, OFD generation log, secondary evidence certificate and CA visa record are linked in timeline form to form an evidence chain traceability view, and a structured audit report containing a report header, verification summary, detailed verification results and final audit conclusion is automatically generated.
[0017] To achieve the above objectives, a second aspect of the present invention proposes a trusted and reliable data persistence system for multi-source heterogeneous sharing of results in housing provident fund business, comprising: The multi-source data access and parsing module is used to receive raw business data from different external business systems through multiple communication protocols, and parse the raw business data to obtain message content, data source identifier and receiving timestamp; The data standardization and source evidence preservation module is used to convert the parsed original business data into a standardized data object containing metadata header based on a preset data mapping model, and to perform an initial hash calculation on the standardized data object to obtain a first hash value. The first hash value and business association information are then stored in the blockchain network to complete the source evidence preservation of the data. The format file generation and certificate solidification module is used to identify key business messages according to the business type in the standardized data object, generate format files using matching format templates, perform institutional digital signature processing on the format files to obtain signed format files, perform secondary hash calculation on the signed format files to obtain a second hash value, and store the second hash value in the blockchain network to complete the certificate solidification and notarization. The audit verification and automatic signature verification module is used to respond to audit verification requests for target businesses, obtain corresponding standardized data objects, signature format files and evidence storage certificates from the storage medium and the blockchain network, automatically verify the data integrity, format file integrity and the validity of the organization's digital signature according to preset verification rules, and generate a structured audit report containing the verification results.
[0018] In one embodiment of the present invention, the data standardization and source evidence preservation module is further used for: Call the configurable data mapping model library to dynamically map specific fields in the parsed original business data to internal standard format fields; The data transformation engine is used to uniformly convert all key business fields into a standardized data body in JSON format, and a metadata header containing sourceSystem, receiveTimestamp, businessType and businessSerialNo fields is forcibly attached to the top layer of the standardized data body to generate a complete standardized data object; The SM3 algorithm is used to perform hash calculation on the string content of the complete standardized data object to generate a first hash value; The smart contract interface of the blockchain evidence storage network with consortium blockchain architecture is invoked to package the first hash value, business serial number, data source identifier, receiving timestamp and original length into a transaction and submit it to the blockchain network. After consensus is reached, the evidence storage certificate containing block height, transaction hash value and on-chain time is obtained, and the data source evidence storage is completed.
[0019] To achieve the above objectives, a third aspect of the present invention provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method described in the first aspect.
[0020] The method, system, and storage medium of this invention, through dual-layer hash notarization and OFD format solidification technology, achieve reliable traceability of multi-source heterogeneous data from source reception to voucher generation, effectively solving the problems of difficulty in detecting data tampering and insufficient legal validity of electronic vouchers. Combined with CA electronic signature for large-value transactions and automated audit and verification mechanisms, it significantly enhances the non-repudiation capability of transactions and greatly improves the efficiency and integrity of post-audit verification.
[0021] Additional aspects and advantages of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. Attached Figure Description
[0022] The above and / or additional aspects and advantages of the present invention will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, wherein: Figure 1 This is a flowchart of a method for reliable solidification of multi-source heterogeneous sharing results for housing provident fund business according to an embodiment of the present invention; Figure 2 This is a flowchart illustrating a specific implementation of a method for reliable solidification of multi-source heterogeneous sharing results for housing provident fund business, according to an embodiment of the present invention. Figure 3 This is a structural diagram of a trusted and solidified system for multi-source heterogeneous sharing results in housing provident fund business, according to an embodiment of the present invention. Detailed Implementation
[0023] It should be noted that, unless otherwise specified, the embodiments and features described in the present invention can be combined with each other. The present invention will now be described in detail with reference to the accompanying drawings and embodiments.
[0024] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.
[0025] The following describes, with reference to the accompanying drawings, a method and system for reliable solidification of multi-source heterogeneous sharing results for housing provident fund business, according to an embodiment of the present invention.
[0026] Example 1 like Figure 1 As shown, Figure 1 This is a flowchart of a method for reliable solidification of multi-source heterogeneous sharing results for housing provident fund business, according to an embodiment of the present invention.
[0027] like Figure 1 As shown, the trusted solidification method for multi-source heterogeneous sharing results in housing provident fund business includes the following steps: S1 receives raw business data from different external business systems through multiple communication protocols, and parses the raw business data to obtain message content, data source identifier and receiving timestamp.
[0028] Step S1 aims to address the technical challenges of inconsistent source status and format differences in business data access within a multi-source, heterogeneous environment, leading to processing difficulties. This step establishes a universal data access module that connects to multiple external business systems, encompassing heterogeneous data sources in fields such as finance, government affairs, and public services. The data access module supports various standard communication protocols and can adapt to the differentiated data transmission specifications adopted by different external systems, thereby receiving raw business data streams. Upon receiving the data, the module performs a parsing operation, extracting the core message content from the raw data stream and identifying and separating the data source identifier representing the data initiator and the receiving timestamp representing the data arrival time. Through this processing, raw inputs with different protocols and formats are uniformly transformed into a basic data structure containing three-dimensional elements: content, source, and time, providing a unified input benchmark for subsequent data standardization and evidence preservation.
[0029] In one implementation, step S1 includes: The system establishes communication connections with the loan approval systems of partner commercial banks, mortgage registration systems of real estate registration centers, tax information inquiry systems of tax bureaus, or social insurance payment inquiry systems of human resources and social security bureaus via HTTP / RESTful API, WebService / SOAP protocol, or Kafka / RabbitMQ message queue interfaces; it receives financial transaction messages conforming to ISO 8583 standards, complex nested XML format data, or lightweight JSON format data as the raw business data; it performs deep parsing on the received raw data stream to extract the raw message content, and marks the data source as BANK_A or TAX_BUREAU, while recording a high-precision timestamp accurate to milliseconds at the time of reception, thus obtaining parsed raw business data containing complete context information.
[0030] The beneficial effect of this step is that by shielding the differences in underlying communication protocols and data formats, it enables unified access to multi-source heterogeneous data and automatic extraction of key metadata, ensuring the traceability of data sources and the immutability of reception time, thus laying a solid data foundation for building a credible evidence chain throughout the entire process.
[0031] S2, based on a preset data mapping model, the parsed raw business data is converted into a standardized data object containing metadata headers, and the standardized data object is subjected to an initial hash calculation to obtain a first hash value. The first hash value and business association information are then stored in the blockchain network to complete the data source notarization. This step aims to solve the challenges of unified processing and source credibility assurance for multi-source heterogeneous data caused by format differences. Its core lies in constructing a standardized and solidified mechanism from heterogeneous parsing to blockchain-based notarization. Specifically, firstly, based on a pre-defined data mapping model, raw business data received from different external business systems undergoes deep transformation, mapping the diverse protocol formats and field structures into standardized data objects with internal standards. A metadata header containing contextual information such as data source identifier, receiving timestamp, and business type is forcibly appended to the top layer of this object, thus forming a standard data unit with a complete business context. Subsequently, an initial hash calculation is performed on this standardized data object containing the metadata header, generating a first hash value that uniquely represents the original state of the data, thereby locking in the "first scene" of the data at the time of receipt. Finally, this first hash value, along with business-related information such as the business serial number, is packaged and submitted to the blockchain network for storage. Utilizing the distributed consensus and immutability of the blockchain, trusted notarization of the data source is achieved, establishing a trust foundation for subsequent business processing.
[0032] Specifically, step S2 includes: S21, call the configurable data mapping model library to dynamically map specific fields in the parsed original business data to internal standard format fields.
[0033] S22. Use the data transformation engine to uniformly convert all key business fields into a standardized data body in JSON format, and forcibly attach a metadata header containing sourceSystem, receiveTimestamp, businessType and businessSerialNo fields to the top layer of the standardized data body to generate a complete standardized data object.
[0034] Further, step S22 includes: S221, Match the corresponding mapping rule from the data mapping model library according to the data source identifier. For the ISO 8583 message of Bank A, read the preset rule to extract the transaction amount data of the 4th field and assign it to the standardized field transactionAmount, and extract the transmission date and time data of the 7th field and assign it to the standardized field transmissionDateTime. S222. For the XML data of the real estate registration system, perform XPath parsing to locate the / Response / Body / PropertyInfo / Address node, extract the text content under this node and assign it to the standardized field propertyAddress, and obtain the mapped set of key business fields to generate standardized data objects.
[0035] S23, use the SM3 algorithm to perform hash calculation on the string content of the complete standardized data object to generate the first hash value.
[0036] S24, call the smart contract interface of the blockchain evidence storage network of the consortium blockchain architecture, package the first hash value, business serial number, data source identifier, receiving timestamp and original length into a transaction and submit it to the blockchain network. After consensus is reached, obtain the evidence storage certificate containing block height, transaction hash value and on-chain time, and complete the data source evidence storage.
[0037] Through the above technical means, this step achieves standardized fusion of multi-source heterogeneous data and cryptographic fixation of the source state. This not only shields the differences in the underlying data sources and provides a consistent data foundation for subsequent business processing, but also ensures the integrity and non-repudiation of the original business data from the date of receipt by leveraging the blockchain evidence storage mechanism. This effectively solves the technical defect of traditional interface authentication that cannot prove that the data content has not been tampered with.
[0038] S3. Identify key business messages based on the business type in the standardized data object, generate a format file conforming to national standards using a matching format template, perform institutional digital signature processing on the format file to obtain a signed format file, perform a second hash calculation on the signed format file to obtain a second hash value, and store the second hash value in the blockchain network to complete the certificate solidification and notarization. This step aims to address the technical issues of insufficient legal validity and susceptibility to tampering in the formatting process of important business documents. Its core lies in establishing an automated conversion and evidence preservation mechanism from standardized data to trusted formatted documents. Specifically, the system automatically determines whether the current data belongs to a critical business message requiring formatting based on the business type identifier carried in the standardized data object. If confirmed as a critical message, it calls the format template matching that business type, filling the business fields from the standardized data into the template's preset positions, thereby generating a formatted document conforming to national standards. To ensure the authenticity and integrity of this formatted document, the system further uses the institution's digital certificate to digitally sign the generated document, embedding the signature information into the file to form a signed formatted document. This ensures that any subsequent modification to the document content will invalidate the signature. Subsequently, a second hash calculation is performed on the signed formatted document to obtain a second hash value, which, along with business-related information, is written to the blockchain network. Utilizing the immutability of the blockchain, the document is solidified and preserved, thus constructing an evidence anchor point independent of the original data.
[0039] Specifically, step S3 includes: S31, Read the businessType field value in the standardized data object. When the businessType field value is LOAN_RECEIPT, APPROVAL_NOTICE, or LOAN_DISBURSEMENT, it is determined to be a critical business message.
[0040] S32, based on the judgment result, match the corresponding template or approval result notification template from the OFD template management unit, fill the loan amount, loan term and borrower name of the businessData part of the standardized data object into the template preset placeholders, and generate an OFD layout file.
[0041] S33. Using the organization's digital certificate stored in the hardware encryption machine or server certificate store, call the electronic signature middleware to digitally sign the OFD format file, embedding the signature value, certificate serial number and signature time into the signature field of the OFD file, to obtain a signed format file with the organization's digital signature.
[0042] Further, step S33 includes: S331, Load the corresponding unit's digital certificate private key and initialize the electronic signature middleware; S332, perform a digest operation on the content of the OFD format file, and use the private key of the unit's digital certificate to perform an encryption operation on the digest value to generate a digital signature value; S333, the digital signature value, certificate serial number, signature time, and certificate chain information are encapsulated in a standardized format and embedded into a dedicated signature field within the OFD format file.
[0043] S34, the SM3 algorithm is used to perform hash calculation on the binary stream of the signature version file to obtain a second hash value, and the second hash value, together with the business serial number and OFD file version information, is written into the blockchain ledger to obtain a second certificate of evidence to complete the certificate solidification and evidence preservation.
[0044] Through the aforementioned technical means, this step achieves standardized format solidification and independent notarization of key business vouchers. This not only enhances the legal compliance and long-term archiving value of electronic vouchers, but also ensures the consistency between the voucher content and its generation basis through a dual hash notarization mechanism, effectively preventing voucher forgery and tampering, and significantly enhancing the non-repudiation capability of business data.
[0045] S4, in response to an audit and verification request for the target business, retrieves the corresponding standardized data object, signature format file, and evidence storage certificate from the storage medium and the blockchain network. Based on preset verification rules, it automatically verifies the data integrity, format file integrity, and the validity of the organization's digital signature, and generates a structured audit report containing the verification results. In response to audit and verification requests targeting specific business operations, this step aims to reconstruct and verify a trusted chain of evidence throughout the entire business lifecycle through automated mechanisms. The process begins by collaboratively retrieving associated standardized data objects, signature template files, and corresponding evidence certificates from distributed storage media and the blockchain network, based on the unique identifier of the target business, forming a complete evidence package to be verified. Subsequently, a pre-defined signature verification rule base is invoked to execute multi-dimensional automated verification logic: at the data integrity level, the hash value of the standardized data object is recalculated and compared with the first hash value stored on the blockchain to confirm that the original business data has not been tampered with since its source. At the template file integrity level, the hash value of the signature template file is recalculated and compared with the second hash value on the chain to ensure the authenticity and consistency of the certificate content. At the institutional digital signature validity level, the signature field within the template file is parsed to verify the mathematical correctness of the signature algorithm, the trust chain status of the signed certificate, and the validity of the signature at the time of signing. Based on the Boolean results of the above verifications, the system automatically aggregates and generates a structured audit report containing a verification summary, itemized details, and a traceability view of the evidence chain.
[0046] Specifically, step S4 includes: S41, retrieve the original first hash value from the blockchain network based on the business transaction number. Retrieve standardized data objects stored in the database and recalculate their hash values. ,like The data integrity verification is then deemed successful. S42, retrieve the stored signature template file and recalculate its hash value. , and the second hash value stored on the blockchain Perform a comparison, if The integrity verification of the layout file is then deemed successful. S43, parse the digital signature field in the signature format file, verify the mathematical validity of the signature, whether the signature certificate is a trusted provident fund center certificate, and whether the signature certificate is valid at the time of signing, and generate the institution's digital signature validity verification result. S44. Based on the Boolean values and detailed verification information of the above verification results, the data receiving log, standardized data record, initial evidence certificate, OFD generation log, secondary evidence certificate and CA visa record are linked in timeline form to form an evidence chain traceability view, and a structured audit report containing a report header, verification summary, detailed verification results and final audit conclusion is automatically generated.
[0047] This step, by establishing a configurable automated signature verification mechanism, transforms the traditionally manual multi-system data comparison and signature verification into a highly efficient system execution process, significantly improving the accuracy and efficiency of auditing and verification. Simultaneously, based on the cross-verification of blockchain-based evidence and local data, an immutable and complete chain of evidence is constructed, effectively solving the technical challenges of scattered evidence and difficulty in tracing it in post-audit processes, and providing strong legal support for business disputes.
[0048] Example 2 like Figure 2 As shown, as a specific implementation method, this invention provides a trusted method for solidifying multi-source heterogeneous shared results in housing provident fund business. The core of this method lies in constructing a trusted chain of "double-layer hash notarization + OFD format solidification + CA electronic signature" and establishing a complete audit, verification, and signature rule base to achieve trusted management of the entire process from the data source to the final voucher.
[0049] The specific structure and steps of this method are as follows: Step S1: Receive and parse multi-source heterogeneous shared data The data access module of this invention communicates with external data sources through various standard interface protocols (including but not limited to HTTP / RESTful API, WebService / SOAP, and message queues such as Kafka / RabbitMQ). These external data sources include at least: loan approval systems of cooperating commercial banks, mortgage registration systems of real estate registration centers, tax information inquiry systems of tax bureaus, and social insurance payment inquiry systems of human resources and social security bureaus.
[0050] These external systems return data in various formats, for example: The banking system may return financial transaction messages that conform to the ISO 8583 standard; The real estate registration system may return XML format data with complex nested structures; Tax and social security systems may return lightweight JSON data.
[0051] The data access module is responsible for adapting to these different protocols and formats, receiving raw data streams, and parsing out the raw message content, data source identifiers (such as "BANK_A" and "TAX_BUREAU"), and a high-precision timestamp (accurate to milliseconds) of the time of reception.
[0052] Step S2: Standardize the raw data Because the data received in step S1 has diverse structures, it is not conducive to subsequent unified processing and evidence preservation; therefore, standardization is necessary. This step is performed by the data standardization module, and the specific operations are as follows: S2.1 Establish and maintain a configurable data mapping model library. This model library defines the mapping relationship between specific fields of each external data source and their corresponding fields in the standardized data model. For example, for Bank A's ISO8583 message, its 4th field (transaction amount) is mapped to the standardized field transactionAmount, and its 7th field (transmission date and time) is mapped to transmissionDateTime; for the XML of the real estate registration system, XPath / Response / Body / PropertyInfo / Address is mapped to the standardized field propertyAddress.
[0053] S2.2 The data transformation engine performs deep analysis and field extraction on the original message data parsed in step S1 based on the matched mapping model, and converts all key business fields into an internal standard format. In this embodiment, JSON (JavaScript Object Notation) is preferred as the standardized data format.
[0054] S2.3 A uniform metadata header is forcibly appended to the top layer of the generated standardized JSON data, with the following structure: json { "metadata": { "sourceSystem": "BANK_A", "receiveTimestamp": "2024-05-20T10:15:30.123+08:00", "businessType": "LOAN_RECEIPT", "businessSerialNo": "LN202405200001" }, "businessData": { / / ... mapped business fields } } Through this step, all data from different channels and in different formats are converted into standardized data objects with complete contextual information and a unified format.
[0055] Step S3: Perform hash calculation on standardized data and initial blockchain notarization. This step is the first layer of evidence preservation in this invention, aiming to fix the "first scene" of the data, that is, the original state of the data after it has been received and standardized. The specific process is as follows: S3.1 The hash evidence storage module extracts the complete standardized JSON string (including metadata header) generated in step S2 as the original text to be hashed.
[0056] S3.2 The SM3 algorithm released by the State Cryptography Administration is used to perform hash calculation on the original text, generating a hash value H1 with a fixed length of 256 bits.
[0057] H1 = SM3 (Standardized JSON string) The S3.3 hash-based evidence storage module calls the smart contract interface of the established blockchain evidence storage network. This blockchain network preferably adopts a consortium blockchain architecture, with the Housing Provident Fund Center, cooperating commercial banks, and local financial regulatory agencies jointly serving as ledger nodes to ensure the multi-party trustworthiness and immutability of the evidence storage data.
[0058] S3.4 Call the "Stereographed Notification" method of the smart contract to package the following information into a transaction and submit it to the blockchain network: dataHash:H1 businessId: Business serial number source: Data source identifier timestamp: Received timestamp dataSize: Original text length After the S3.5 blockchain network reaches consensus and writes the transaction into a new block, it returns a certificate of authenticity, which contains at least the following: blockHeight: The height of the block where the evidence is stored. txHash: The hash value of this notarized transaction. onChainTime: The time of evidence storage recorded on the blockchain. The certificate will be persistently stored in the relational database of the data storage module along with the standardized JSON data from step S2, establishing an association index between business data and on-chain certificate storage.
[0059] Step S4: Solidify and perform secondary evidence storage on key business messages using OFD format files. This step is the second layer of evidence preservation in this invention. Its purpose is to transform key business content into a legally valid document format that conforms to national standards and then preserve it separately. This is executed by the OFD (Off-Demand Filing) module.
[0060] S4.1 Critical Business Message Identification: The system automatically determines whether the standardized data belongs to the critical business message that needs to be fixed based on the value of the businessType field (such as "LOAN_RECEIPT", "APPROVAL_NOTICE", "LOAN_DISBURSEMENT").
[0061] S4.2 OFD Template Matching and Data Population: If a message is identified as critical, the OFD template management unit will match the corresponding OFD template based on the businessType. For example, it will match the "Notification of Acceptance of Housing Provident Fund Loan" template for the "LOAN_RECEIPT" type. The template population unit will then populate the specific field values (such as loan amount, loan term, borrower's name, etc.) of the businessData part in the standardized JSON into the preset placeholders in the OFD template, generating a complete OFD layout file.
[0062] S4.3 Digital Signature of OFD Files: Using the entity's digital certificate stored in the Hardware Encryption Machine (HSM) or server certificate store of the Housing Provident Fund Center, an electronic signature middleware conforming to national cryptographic standards is invoked to digitally sign the generated OFD file. The signature information (including signature value, certificate serial number, signature time, etc.) will be embedded into the signature field of the OFD file according to GB / T 33190-2016 and GM / T 0031-2014 specifications. At this point, the OFD file becomes an immutable format certificate with the organization's digital signature.
[0063] S4.4 OFD file hash calculation and secondary on-chain evidence storage: Calculate the SM3 hash value H2 of the signed OFD file.
[0064] H2 = SM3 (Signed OFD file binary stream) The smart contract of the blockchain evidence storage network is invoked again to write H2 along with information such as the current business serial number and OFD file version into the blockchain ledger, thereby obtaining a second evidence storage certificate.
[0065] The generated OFD format file is stored in a distributed file system or electronic archive system, and its storage path, file ID, and second evidence certificate are associated and stored in the database.
[0066] Steps S3 and S4 complete a two-layered closed-loop evidence storage process: "raw data hashing and on-chain → format document signature generation → format document hashing and on-chain". This mechanism ensures that the authenticity and integrity of both the original business data and the final certificate generated based on it can be independently verified.
[0067] Step S5: Large transactions trigger CA electronic visa process For high-risk or large-value transactions that meet preset conditions, this invention introduces a client-oriented CA electronic visa mechanism to enhance customer identity authentication strength and transaction non-repudiation.
[0068] S5.1 Large Amount Detection: During business approval or contract signing, the CA visa module reads the transactionAmount field from the business data and compares it with a preset threshold (e.g., loan amount exceeding RMB 500,000). If the threshold is exceeded, or the business is marked as "high-risk" by the risk control system, the CA electronic visa process is automatically triggered.
[0069] S5.2 Generate a digest to be signed: The system extracts key elements of the business transaction and forms a deterministic, structured text string. Key elements include, but are not limited to: business transaction number, business type, transaction amount, transaction date, customer name, identification number, and a summary of key contract terms. Then, the SM3 algorithm is used to calculate the hash value of this text string, which serves as the business data digest to be signed.
[0070] S5.3 Push Visa Request and Customer Signing: The system sends a visa request to the customer's terminal via a secure push channel (such as push notifications in a mobile app or WeChat official account messages). The request carries a summary of the business data to be signed and brief business information. After the customer confirms that everything is correct, they authorize the app to access their personal CA digital certificate stored in the phone's security chip or cloud cryptographic device via biometrics (fingerprint, facial recognition) or payment password, and use the certificate's private key to perform a signature operation on the business data summary to generate a digital signature value.
[0071] S5.4 Signature Verification and Storage: The client terminal returns the generated digital signature value, certificate serial number, etc., to the housing provident fund system. The CA visa module calls the CA certification server interface to verify the validity of the signature and the legality of the certificate (including certificate chain verification, validity period check, and CRL / OCSP revocation status query). After successful verification, the system permanently binds and stores the visa results, such as the digital signature value, certificate serial number, and signature timestamp, with business data and OFD format files. Simultaneously, the entire visa operation process (including visa request, customer confirmation, signature verification, etc.) is recorded in detail in the audit log.
[0072] Step S6: Establish and maintain an audit verification and signature rule base. To support efficient and automated auditing, the audit verification module has a built-in configurable audit verification rule base. This rule base is the logical core for post-event verification and includes the following four categories of rules: Data integrity verification rules: Define how to query the corresponding evidence record from the blockchain network based on the business transaction number to obtain the original hash value H1; and retrieve the standardized JSON data stored at that time from the database to recalculate its hash value H1'. If H1 = H1', the data integrity verification is deemed successful, proving that the data has not been tampered with since its receipt.
[0073] OFD document verification rules: Define how to verify OFD format documents, including: Content integrity verification: Obtain the OFD file, recalculate its hash value H2', and compare it with H2 stored on the blockchain to verify whether the OFD file itself has been tampered with.
[0074] Digital signature validity verification: Parse the digital signature field in the OFD file to verify the mathematical validity of the signature, whether the signature certificate is a trusted provident fund center certificate, and whether the signature certificate is valid at the time of signing.
[0075] CA Signature Verification Rules: Define how to verify the legitimacy of a customer's CA signature, including: verifying the signature value using the certificate's public key, verifying the certificate chain up to the trusted root CA, and verifying the certificate's validity and revocation status at the time of signing.
[0076] Evidence chain tracing rules: Define how to connect all key events and data fingerprints from step S1 to step S5 in the form of a timeline based on the business serial number, including: data receiving log, standardized data record, initial evidence certificate, OFD generation log, OFD secondary evidence certificate, CA signature record, etc., to form a complete business evidence chain view.
[0077] Step S7: Respond to the audit verification request, perform automatic signature verification, and generate a report. When auditors enter one or more transaction serial numbers into the audit system and initiate a verification request, the audit signature verification module executes the following automated process: S7.1 Obtain the complete evidence package: Based on the business transaction number, retrieve all relevant data for the business from various storage modules (relational database, blockchain network, file system), including: standardized JSON data, initial evidence certificate, OFD format file, secondary evidence certificate, CA signature record, etc.
[0078] S7.2 Verify each item in the rule base: Iterate through each signature verification rule defined in step S6 and perform a check on each of the obtained evidence packets. Each check will return a boolean result of "pass" or "fail", as well as detailed verification information (such as "hash match", "certificate expired", etc.).
[0079] S7.3 Generate a structured audit report: Based on the verification results of each rule, the report generation unit automatically generates a structured audit verification report. The report content includes: Report header: Report generation time, audit target (business transaction number), auditor, etc.
[0080] Verification Summary: Displays the overall pass / fail status of each verification item (data integrity, OFD integrity, OFD organization signature, CA customer signature) in the form of a "dashboard".
[0081] Detailed verification results: Each verification rule, verification result, verification time, and detailed explanation are listed separately.
[0082] Evidence Chain Traceability View: Displays key nodes of the entire business process and their corresponding hash fingerprints in a timeline format.
[0083] Final conclusion: Clearly state the final audit conclusion as either "all verifications passed" or "verifications failed, business data is questionable".
[0084] Example 3 like Figure 3 As shown, this invention proposes a trusted and reliable data persistence system 10 for multi-source heterogeneous sharing of results in housing provident fund business, comprising: The multi-source data access and parsing module 100 is used to receive raw business data from different external business systems through multiple communication protocols, and parse the raw business data to obtain message content, data source identifier and receiving timestamp; The data standardization and source evidence storage module 200 is used to convert the parsed original business data into a standardized data object containing metadata header based on a preset data mapping model, and to perform an initial hash calculation on the standardized data object to obtain a first hash value. The first hash value and business association information are then stored in the blockchain network to complete the source evidence storage. The format file generation and certificate solidification module 300 is used to identify key business messages according to the business type in the standardized data object, generate a format file that conforms to national standards using a matching format template, perform institutional digital signature processing on the format file to obtain a signed format file, perform secondary hash calculation on the signed format file to obtain a second hash value, and store the second hash value in the blockchain network to complete the certificate solidification and notarization. The audit verification and automatic signature verification module 400 is used to respond to audit verification requests for target business, obtain the corresponding standardized data objects, signature format files and evidence storage certificates from the storage medium and the blockchain network, automatically verify the data integrity, format file integrity and the validity of the organization's digital signature according to preset verification rules, and generate a structured audit report containing the verification results.
[0085] Furthermore, the data standardization and source evidence preservation module 200 is also used for: Call the configurable data mapping model library to dynamically map specific fields in the parsed original business data to internal standard format fields; The data transformation engine is used to uniformly convert all key business fields into a standardized data body in JSON format, and a metadata header containing sourceSystem, receiveTimestamp, businessType and businessSerialNo fields is forcibly attached to the top layer of the standardized data body to generate a complete standardized data object; The SM3 algorithm is used to perform hash calculation on the string content of the complete standardized data object to generate a first hash value; The smart contract interface of the blockchain evidence storage network with consortium blockchain architecture is invoked to package the first hash value, business serial number, data source identifier, receiving timestamp and original length into a transaction and submit it to the blockchain network. After consensus is reached, the evidence storage certificate containing block height, transaction hash value and on-chain time is obtained, and the data source evidence storage is completed.
[0086] The present invention also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the above-mentioned method for reliable solidification of multi-source heterogeneous sharing results for housing provident fund business.
[0087] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of the present invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.
[0088] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this invention, "a plurality of" means at least two, such as two, three, etc., unless otherwise explicitly specified.
Claims
1. A multi-source heterogeneous shared result trusted solidification method for provident fund business, characterized in that, Includes the following steps: S1, receives raw business data from different external business systems through multiple communication protocols, and parses the raw business data to obtain message content, data source identifier and receiving timestamp; S2, based on the preset data mapping model, the parsed original business data is converted into a standardized data object containing metadata header, and the standardized data object is subjected to the first hash calculation to obtain the first hash value. The first hash value and business association information are stored in the blockchain network to complete the data source evidence storage. S3. Identify key business messages based on the business type in the standardized data object, generate a format file using the matching format template, perform institutional digital signature processing on the format file to obtain a signed format file, perform secondary hash calculation on the signed format file to obtain a second hash value, and store the second hash value in the blockchain network to complete the certificate solidification and notarization. S4, in response to an audit and verification request for the target business, obtains the corresponding standardized data object, signature format file and evidence storage certificate from the storage medium and the blockchain network, automatically verifies the data integrity, format file integrity and the validity of the organization's digital signature according to the preset verification rules, and generates a structured audit report containing the verification results.
2. The method of claim 1, wherein, S2 includes: S21, call the configurable data mapping model library to dynamically map specific fields in the parsed original business data to internal standard format fields; S22, use the data transformation engine to uniformly convert all key business fields into a standardized data body in JSON format, and forcibly attach a metadata header containing sourceSystem, receiveTimestamp, businessType and businessSerialNo fields to the top layer of the standardized data body to generate a complete standardized data object; S23, use the SM3 algorithm to perform hash calculation on the string content of the complete standardized data object to generate the first hash value; S24, call the smart contract interface of the blockchain evidence storage network of the consortium blockchain architecture, package the first hash value, business serial number, data source identifier, receiving timestamp and original length into a transaction and submit it to the blockchain network. After consensus is reached, obtain the evidence storage certificate containing block height, transaction hash value and on-chain time, and complete the data source evidence storage.
3. The method of claim 2, wherein, S22 includes: S221, Match the corresponding mapping rule from the data mapping model library according to the data source identifier. For the ISO 8583 message of Bank A, read the preset rule to extract the transaction amount data of the 4th field and assign it to the standardized field transactionAmount, and extract the transmission date and time data of the 7th field and assign it to the standardized field transmissionDateTime. S222. For the XML data of the real estate registration system, perform XPath parsing to locate the / Response / Body / PropertyInfo / Address node, extract the text content under this node and assign it to the standardized field propertyAddress, and obtain the mapped set of key business fields to generate standardized data objects.
4. The method of claim 1, wherein, S3 includes: S31, Read the businessType field value in the standardized data object. When the businessType field value is LOAN_RECEIPT, APPROVAL_NOTICE, or LOAN_DISBURSEMENT, it is determined to be a critical business message. S32, based on the judgment result, match the corresponding template or approval result notification template from the OFD template management unit, fill the loan amount, loan term and borrower name of the businessData part of the standardized data object into the template preset placeholders, and generate an OFD layout file; S33, using the unit's digital certificate stored in the hardware encryption machine or server certificate store, call the electronic signature middleware to digitally sign the OFD format file, embedding the signature value, certificate serial number and signature time into the signature field of the OFD file, to obtain a signed format file with the organization's digital signature; S34, the SM3 algorithm is used to perform hash calculation on the binary stream of the signature version file to obtain a second hash value, and the second hash value, together with the business serial number and OFD file version information, is written into the blockchain ledger to obtain a second certificate of evidence to complete the certificate solidification and evidence preservation.
5. The method of claim 4, wherein, S33 includes: S331, Load the corresponding unit's digital certificate private key and initialize the electronic signature middleware; S332, perform a digest operation on the content of the OFD format file, and use the private key of the unit's digital certificate to perform an encryption operation on the digest value to generate a digital signature value; S333, the digital signature value, certificate serial number, signature time, and certificate chain information are encapsulated in a standardized format and embedded into a dedicated signature field within the OFD format file.
6. The method of claim 1, wherein, The method also includes triggering a CA electronic visa process for large transactions during business approval or contract signing stages, specifically including: Read the value of the transactionAmount field in the standardized data object and compare it with a preset threshold, or read the risk level marked by the risk control system. When the transaction amount exceeds the threshold or the risk level is marked as high risk, the CA electronic visa process is automatically triggered. Extract the business transaction number, business type, transaction amount, transaction date, customer name, ID number, and key contract terms to form a deterministic structured text string. Use the SM3 algorithm to calculate the hash value of the text string as the business data digest to be signed. Send a visa request to the client terminal, and receive a digital signature value generated by the client after authorizing through biometrics or payment password by calling the private key of the personal CA digital certificate to perform a signature operation on the business data digest; The CA authentication server interface is called to verify the validity of the digital signature value and the legality of the certificate. After the verification is successful, the digital signature value, certificate serial number and signature timestamp are permanently bound and stored with the standardized data object and signature template file, and recorded in the audit log.
7. The method of claim 1, wherein, S4 includes: S41, querying the original first hash value from the blockchain network according to the service flow number , obtaining the stored standardized data object from the database and recalculating the hash value thereof , if , determining that the data integrity verification is passed S42, retrieve the stored signature template file and recalculate its hash value. , and the second hash value stored on the blockchain Perform a comparison, if The integrity verification of the layout file is then deemed successful. S43, parse the digital signature field in the signature format file, verify the mathematical validity of the signature, whether the signature certificate is a trusted provident fund center certificate, and whether the signature certificate is valid at the time of signing, and generate the institution's digital signature validity verification result. S44. Based on the Boolean values and detailed verification information of the above verification results, the data receiving log, standardized data record, initial evidence certificate, OFD generation log, secondary evidence certificate and CA visa record are linked in timeline form to form an evidence chain traceability view, and a structured audit report containing a report header, verification summary, detailed verification results and final audit conclusion is automatically generated.
8. A trusted and reliable data persistence system for multi-source heterogeneous sharing of results in housing provident fund business, characterized in that: include: The multi-source data access and parsing module is used to receive raw business data from different external business systems through multiple communication protocols, and parse the raw business data to obtain message content, data source identifier and receiving timestamp; The data standardization and source evidence preservation module is used to convert the parsed original business data into a standardized data object containing metadata header based on a preset data mapping model, and to perform an initial hash calculation on the standardized data object to obtain a first hash value. The first hash value and business association information are then stored in the blockchain network to complete the source evidence preservation of the data. The format file generation and certificate solidification module is used to identify key business messages according to the business type in the standardized data object, generate format files using matching format templates, perform institutional digital signature processing on the format files to obtain signed format files, perform secondary hash calculation on the signed format files to obtain a second hash value, and store the second hash value in the blockchain network to complete the certificate solidification and notarization. The audit verification and automatic signature verification module is used to respond to audit verification requests for target businesses, obtain corresponding standardized data objects, signature format files and evidence storage certificates from the storage medium and the blockchain network, automatically verify the data integrity, format file integrity and the validity of the organization's digital signature according to preset verification rules, and generate a structured audit report containing the verification results.
9. The system as described in claim 8, characterized in that, The data standardization and source evidence preservation module is also used for: Call the configurable data mapping model library to dynamically map specific fields in the parsed original business data to internal standard format fields; The data transformation engine is used to uniformly convert all key business fields into a standardized data body in JSON format, and a metadata header containing sourceSystem, receiveTimestamp, businessType and businessSerialNo fields is forcibly attached to the top layer of the standardized data body to generate a complete standardized data object; The SM3 algorithm is used to perform hash calculation on the string content of the complete standardized data object to generate a first hash value; The smart contract interface of the blockchain evidence storage network with consortium blockchain architecture is invoked to package the first hash value, business serial number, data source identifier, receiving timestamp and original length into a transaction and submit it to the blockchain network. After consensus is reached, the evidence storage certificate containing block height, transaction hash value and on-chain time is obtained, and the data source evidence storage is completed.
10. A computer-readable storage medium storing a computer program that, when executed by a processor, implements the method as claimed in any one of claims 1-7.