Blockchain-based supply chain finance reconciliation data identification method

Abstract

The present application belongs to the technical field of supply chain finance and blockchain application, and discloses a supply chain finance reconciliation data identification method based on a blockchain; the method comprises the following steps: authenticating access request information of a requestor interface in a supply chain by constructing an authentication model, issuing an access token to the requestor interface that passes the authentication and automatically triggering a reconciliation data identification request; determining a set of permission control parameters of the requestor for target reconciliation data based on a three-dimensional permission cube constructed and generating a permission list, and further analyzing and generating a reconciliation authorization set and a visible data view; matching reconciliation data of the requestor with the reconciliation authorization set, triggering a hierarchical response mechanism based on the type of difference data and recording difference processing results; integrating data fields that match successfully and processed difference data, generating a reconciliation data identification report and performing blockchain notarization, thereby providing a safe and reliable data circulation basis for multi-party cooperation in supply chain finance.

Description

Technical Field

[0001] This invention relates to the fields of supply chain finance and blockchain application technology, and more specifically, to a blockchain-based method for verifying supply chain finance reconciliation data. Background Technology

[0002] Supply chain finance involves multiple stakeholders, including core enterprises, upstream and downstream SMEs, and financial institutions. These parties exchange a large amount of transaction data, making the accuracy and authenticity of reconciliation data crucial for the smooth operation of the business. Traditional reconciliation methods rely heavily on manual verification, which is prone to data tampering and lacks credibility in the verification results.

[0003] With the development of blockchain technology, its immutability provides a new solution for verifying the authenticity of supply chain finance reconciliation data. In existing technologies, blockchain platforms are used to automatically capture and synchronize data from multiple parties, eliminating the need for manual data collection. Through unified data processing and matching, the verification of reconciliation data is automatically completed. However, existing blockchain-based reconciliation data processing solutions still have the following shortcomings: For example, when the core enterprise's system connects with the data of upstream and downstream enterprises and financial institutions, it involves sensitive data such as transaction amounts, customer information, and payment bills. Existing mechanisms cannot implement differentiated access control based on business stages and data sensitivity, which may lead to some participants obtaining sensitive information beyond business needs, increasing the risk of data leakage.

[0004] In view of this, the present invention proposes a blockchain-based method for verifying supply chain finance reconciliation data to solve the above problems. Summary of the Invention

[0005] To overcome the aforementioned shortcomings of existing technologies and achieve the above objectives, this invention provides the following technical solution: a blockchain-based method for verifying supply chain finance reconciliation data, comprising:

[0006] S1. By constructing an authentication model, the access request information of the requester interface in the supply chain is authenticated, and an access token is issued to the authenticated requester interface and the reconciliation data verification request is automatically triggered.

[0007] S2. Construct a three-dimensional permission cube, determine the set of permission control parameters for the requester's access to the target reconciliation data based on the three-dimensional permission cube, and generate a permission list. Analyze the target reconciliation data based on the permission list to generate a reconciliation authorization set and a visible data view.

[0008] S3. Match the requester's reconciliation data with the reconciliation authorization set, mark the unmatched data fields as discrepancies, trigger the hierarchical response mechanism based on the type of discrepancies, and record the discrepancy processing results. S4. Integrate the successfully matched data fields and the processed discrepancy data to generate a reconciliation data verification report and store it on the blockchain.

[0009] Furthermore, the methods for issuing access tokens to authenticated requester interfaces and automatically triggering reconciliation data verification requests include:

[0010] Receive access request information from the requester's interface in the supply chain. The access request information includes identity and qualification information, interface behavior data, and device physical environment information.

[0011] An authentication model comprising an identity verification layer, a behavior analysis layer, and an environment awareness layer is constructed to perform multi-layer authentication of access request information. When all layers of authentication pass, an access token is issued to the requester's interface, and a reconciliation data verification request is automatically triggered for the requester holding the access token. If any layer of authentication fails, the requester's interface access is rejected.

[0012] Furthermore, the authentication model employs multi-layered authentication methods for access request information, including:

[0013] The identity verification layer obtains the decentralized identity of the requester based on the blockchain, compares and verifies it with the identity qualification information, and if the verification is consistent, transmits the interface behavior data to the behavior analysis layer.

[0014] The behavior analysis layer performs weighted scoring on the interface behavior data, calculates the trust score and compares it with a preset threshold. If the score exceeds the preset threshold, the device's physical environment information is transmitted to the environment perception layer.

[0015] The environment perception layer verifies the physical environment information of the device by deploying an edge authentication gateway and combining the set trusted execution environment and trusted chip verification mechanism.

[0016] Furthermore, methods for constructing a three-dimensional permission cube include:

[0017] Based on business responsibilities, the participants in the supply chain are divided into different roles and a basic permission set is configured for each role; the overall business process of the supply chain is broken down into several independent business stages and a stage policy set is bound to each business stage; based on preset sensitivity rules, the reconciliation data fields of each participant are divided into sensitivity levels and a sensitivity policy set is configured for each level.

[0018] Using roles, business stages, and sensitivity levels as dimensions, a three-dimensional permission cube containing multiple intersection points is constructed through orthogonal combination.

[0019] Based on the basic permission set, stage policy set, and sensitivity policy set corresponding to each intersection point, a permission control parameter set is generated and stored at the corresponding intersection point to complete the construction of the three-dimensional permission cube.

[0020] Furthermore, methods for generating a permission list include:

[0021] Parse the requester's reconciliation data verification request and access token to obtain the requester's role, business stage, and target reconciliation data. Determine the sensitivity level of each data field in the target reconciliation data through sensitivity rules.

[0022] Based on the requester's role, business stage, and sensitivity level of each field in the target reconciliation data, locate the corresponding intersection point in the three-dimensional permission cube and extract the permission control parameter set stored at the corresponding intersection point;

[0023] Based on the extracted set of permission control parameters, a permission list for the requester to access the target reconciliation data is generated. The permission list includes operation permissions for each field and data access levels.

[0024] Furthermore, methods for generating reconciliation authorization sets and visible data views include:

[0025] Based on the data access levels in the permission list, each data field of the target reconciliation data is processed. The processing includes: retaining the original data for data fields that do not exceed the data access level, and transforming data fields that exceed the data access level according to the preset desensitization rules.

[0026] The processed data fields are appended with the operation permissions specified in the permission list to form a reconciliation authorization set;

[0027] The reconciliation authorization set and permission list are encapsulated and sent to the requesting client. The requesting client dynamically renders the received encapsulated data to generate a visible data view.

[0028] Furthermore, methods for generating access control parameter sets include:

[0029] The basic permission set, stage strategy set, and sensitivity strategy set of each corresponding intersection point are merged and calculated to obtain the initial permission control parameter set;

[0030] The permission conflicts existing in the initial permission control parameter set are adjudicated according to the preset priority principle, and a permission control parameter set containing field operation permissions and data access levels is formed based on the adjudication results.

[0031] Furthermore, methods for matching the requester's reconciliation data with the reconciliation authorization set include:

[0032] Using the reconciliation authorization set as a benchmark, the data to be reconciled submitted by the requester is matched according to the preset reconciliation rules. Data fields that fail to match in the data to be reconciled are marked as discrepancies, and the discrepancies are classified according to their characteristics.

[0033] The corresponding hierarchical response mechanism is automatically triggered based on the type of difference, and the result of the difference processing is recorded.

[0034] Furthermore, methods for generating reconciliation data verification reports include:

[0035] Integrate the successfully matched data fields in the requester's pending reconciliation data with the processed discrepancies to generate a reconciliation data verification report;

[0036] The hash value of the reconciliation data verification report is calculated using a hash algorithm and digitally signed. The hash value and digital signature of the reconciliation data verification report are then written into the blockchain through a consortium blockchain smart contract to generate a reconciliation data verification certificate.

[0037] The technical effects and advantages of the blockchain-based supply chain finance reconciliation data verification method of this invention are as follows:

[0038] 1. This invention achieves comprehensive authentication of requester interfaces in the supply chain by constructing an authentication model that includes identity verification, behavior analysis, and environmental awareness layers. It utilizes blockchain technology for decentralized identity verification, enhancing the system's anti-counterfeiting capabilities and avoiding the risks of identity forgery and data tampering. The authentication model can not only accurately assess the credibility of the requester but also determine in real time whether the requester meets the access requirements through behavior analysis and environmental verification. This effectively prevents unauthorized access and injection of false data, ensuring the legality and reliability of the source of reconciliation data and enhancing the security and stability of the system.

[0039] 2. This invention pre-constructs a three-dimensional permission cube by considering the roles, business processes, and sensitivity of reconciliation data in each supply chain on the blockchain. Then, by combining the requester's role, business stage, and data sensitivity, it obtains a set of permission control parameters from the corresponding intersections in the three-dimensional permission cube and further obtains a permission list. Differentiated access control is implemented for sensitive data of different participants and different business links. Based on the permission list, permission verification and visible data view generation not only meet the requirements of data security but also improve the convenience of user operation and reduce the possibility of operation errors.

[0040] 3. This invention automatically matches the requester's data with the reconciliation authorization set through preset rules, triggers a hierarchical response mechanism for discrepancies based on data type, and achieves standardization and automation of discrepancy identification and processing. This improves the overall efficiency and accuracy of reconciliation data identification. After hashing and digitally signing the reconciliation data identification report, it is written into the blockchain to form an immutable reconciliation voucher, ensuring the credibility of the identification results. At the same time, it supports full-chain traceability and provides reliable evidence for dispute resolution. Attached Figure Description

[0041] Figure 1 This is a schematic diagram of the blockchain-based supply chain finance reconciliation data verification method of the present invention;

[0042] Figure 2 This is a schematic diagram of the authentication model process of the present invention;

[0043] Figure 3 A schematic diagram illustrating the process of constructing a three-dimensional permission cube for this invention. Detailed Implementation

[0044] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. 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 are within the scope of protection of the present invention.

[0045] Example 1

[0046] Please see Figure 1 and Figure 3 As shown in this embodiment, the main design contents of the blockchain-based supply chain finance reconciliation data verification method are as follows:

[0047] Supply chain finance, as an important means to solve the financing difficulties of SMEs, involves multiple participants such as purchasers, suppliers, logistics providers, and financial institutions. In actual business operations, each participant maintains its own business data, including order information, delivery records, payment records, and financing information.

[0048] Existing technologies typically employ fully automated reconciliation methods that integrate interfaces with multiple systems. This approach directly interfaces with the systems of all participants in the supply chain, enabling automatic data capture and synchronization without requiring manual data collection, thus simplifying the operational process. However, it suffers from significant shortcomings in data authenticity verification: firstly, it lacks multi-dimensional security authentication of access entities, making it difficult to ensure the reliability of source data; secondly, it lacks a refined access control mechanism, making it difficult to implement differentiated access to sensitive data (such as financial information and contract content) based on the roles of participants and the stage of business. For example, suppliers can view basic order information during the order confirmation stage, but should not access the buyer's financial statements during the financing approval stage; financial institutions need to obtain transaction data to assess financing risks, but do not need to know the customer information of upstream and downstream companies.

[0049] The lack of dynamic access control in existing systems not only poses a risk of sensitive information leakage, but also makes it difficult to establish a credible basis for the verification process of reconciliation data, thus making it difficult to form legally valid verification results.

[0050] Based on this, a blockchain-based method for verifying supply chain finance reconciliation data is designed, including:

[0051] S1. By constructing an authentication model, the access request information of the requester interface in the supply chain is authenticated, and an access token is issued to the authenticated requester interface and the reconciliation data verification request is automatically triggered.

[0052] The methods for issuing access tokens to authenticated requester interfaces and automatically triggering reconciliation data verification requests include:

[0053] The system receives access request information from requesting parties within the supply chain. This access request information includes identity and qualification information, interface behavior data, and device physical environment information. The requesting party represents a participant (such as a core enterprise, upstream or downstream enterprises, or financial institutions) initiating a reconciliation data verification request within the financial supply chain. The reconciliation data submitted by the requesting party through its interface will serve as the verification basis; therefore, strict authentication is required to ensure the credibility of the data source. The access request information is a set of basic data submitted to the system by the requesting party's interface before initiating reconciliation data verification, used for identity verification and security checks. It is the core basis for subsequent multi-layered authentication.

[0054] Identity and qualification information refers to the legal identity and authorization documents of the requesting party's interface, including the unified social credit code digital certificate of the supply chain participant enterprise (used to verify the legality of the enterprise entity) and the digital signature of the authorized representative (used to confirm the ownership of interface operation permissions); Interface behavior data refers to the historical interaction characteristics and current operation trajectory of the requesting party's interface, including the application programming interface call frequency sequence (used to identify abnormal call patterns), call timestamp sequence (used to detect suspicious operations during non-business periods), and the geographical distribution of the source Internet Protocol address (used to verify the consistency between the access location and the enterprise's registered location); Device physical environment information refers to the hardware and network environment parameters of the terminal where the requesting party's interface is located, including device model, operating system, IP address, and device location.

[0055] An authentication model comprising an identity verification layer, a behavior analysis layer, and an environment awareness layer is constructed to perform multi-layered authentication of access request information. When authentication at each layer passes, an access token is issued to the requesting interface. The access token contains information such as the requester's identity identifier, role type, and token validity period. The generated access token is returned to the requesting interface through an encrypted channel. The requesting interface needs to carry this access token in subsequent operations such as submitting reconciliation data and querying verification results.

[0056] The system automatically triggers a reconciliation data verification request for requesters holding access tokens. If any layer of authentication fails, the requester's interface access is denied. The reconciliation data verification request includes basic information such as the requester's identifier, the scope of reconciliation data, and the reconciliation period. The generated reconciliation data verification request is added to the reconciliation task queue, awaiting execution in subsequent reconciliation processing steps.

[0057] The authentication model employs multi-layered authentication methods for access request information, including:

[0058] The identity verification layer obtains the requester's decentralized identity based on the blockchain and compares it with the identity qualification information. If the verification matches, the interface behavior data is transmitted to the behavior analysis layer. The identity verification layer first connects to the supply chain blockchain network and queries the requester's decentralized identity through a smart contract. It then compares the decentralized identity with the identity qualification information, verifying: whether the enterprise's business license number matches the blockchain record, whether the digital certificate is valid, and whether the public key can verify the requester's digital signature. When all comparisons match, it indicates that the requester is legitimate and qualified to access the interface. The identity verification layer packages the interface behavior data and transmits it to the behavior analysis layer through a secure channel. If any verification fails, the requester's interface access is rejected.

[0059] The behavior analysis layer performs weighted scoring on interface behavior data, calculates a trust score, and compares it with a preset threshold. If the score exceeds the preset threshold, the device's physical environment information is transmitted to the environment perception layer. The behavior analysis layer determines the compliance of the current operation based on historical behavior baselines. It first preprocesses the received interface behavior data, extracting key behavioral features such as average daily access frequency, access time regularity, query data type distribution, and abnormal access percentage. Different weighting coefficients are assigned to each key behavioral feature (e.g., average daily access frequency 30%, access time regularity 25%, query data type distribution 25%, abnormal access percentage 20%). The score range for each key behavioral feature is 0-100. The final trust score is calculated through weighted calculation and compared with a preset threshold (e.g., a threshold of 0.7) to determine whether the requester's behavior conforms to the normal business logic of their role. If the score is below the threshold, access is rejected to avoid interference from abnormal behavior with the assessment data.

[0060] The environment awareness layer verifies the physical environment information of devices by deploying edge authentication gateways and combining them with a set trusted execution environment and trusted chip verification mechanism. The edge authentication gateway verifies the integrity of the trusted execution environment of the requesting device through a remote proof protocol. The trusted chip verification mechanism verifies the hardware integrity of the device by communicating with the trusted chip in the requesting device. The verification process includes: reading the platform configuration register value in the trusted chip, verifying the startup metric log, and checking the key storage status. The edge authentication gateway matches the collected hardware fingerprints with a pre-registered device whitelist. When the trusted execution environment verification passes and the trusted chip verification result is normal, the environment awareness layer determines that the device's physical environment is secure. When both the trusted execution environment and trusted chip verifications pass, a three-layer authentication loop is completed, ensuring the requesting party is trustworthy across all dimensions of "subject-behavior-device," laying a secure foundation for subsequent reconciliation data verification.

[0061] S2. Construct a three-dimensional permission cube. Based on the three-dimensional permission cube, determine the set of permission control parameters for the requester's access to the target reconciliation data and generate a permission list. Analyze the target reconciliation data based on the permission list to generate a reconciliation authorization set and a visible data view.

[0062] Methods for constructing a three-dimensional permission cube include:

[0063] Based on business responsibilities, each participant in the supply chain is divided into different roles, and a basic set of permissions is configured for each role. Role division is the first dimension of the three-dimensional permission cube. It is based on the business division of labor in the supply chain finance reconciliation scenario, clarifying the permission boundaries of different participants in the reconciliation data verification process. By binding roles with reconciliation data types, it ensures that each participant can only access the verification data related to its business. For example, the purchasing role focuses on order-related reconciliation data (order amount, acceptance records), the supplier role focuses on delivery and collection-related reconciliation data (such as delivery quantity, invoice information), the logistics provider role focuses on logistics reconciliation data (such as transportation records, signed receipts), and the financial institution role needs to access financing-related reconciliation data (such as loan amount, repayment records). From the business logic level, unauthorized access to reconciliation data is avoided.

[0064] The basic permission set quantifies the scope of operations a role can perform in reconciliation data verification. It directly serves the generation of subsequent reconciliation authorization sets. Each role's basic permission set includes a list of allowed data table names and basic operation types, including read-only, edit, and approve. For example, the basic permission set for the purchasing role can be configured as follows: "Supplier Order Table" (access allowed), "Payment Application Table" (read-only), "Own Order Table" (edit), and "Acceptance Form" (approval), ensuring that they can only modify order data initiated by themselves and have only viewing and approval rights for payment-related reconciliation data. The basic permission set for the supplier role can be configured as follows: "Order Details Table" (access allowed), "Shipping Record Table" (read-only + edit), and "Receipt Voucher Table" (read-only), enabling them to maintain shipping-related reconciliation data but not to modify the core data of the purchasing party or financial institution.

[0065] The entire supply chain business process is broken down into several independent business stages. This business stage breakdown is the second dimension of the three-dimensional permission cube. Based on the temporal characteristics of supply chain finance reconciliation data and the needs of business scenarios, the entire process is decomposed into independent business stages. The types of reconciliation data and the focus of collaboration among participants differ in different stages. For example, the core reconciliation data in the order creation stage is basic order information, while the financial settlement stage focuses on payment vouchers and invoice data. After this breakdown, differentiated permissions can be configured based on the characteristics of the reconciliation data in each stage, avoiding the risk of sensitive data leakage. Specifically, based on time sequence and business logic, the process is divided into the order creation stage (the stage where the buyer selects a supplier and generates a formal purchase order), the order execution stage (the stage where the supplier receives the order and organizes production), the logistics and distribution stage (the stage where goods are transported from the supplier to the buyer), and the financial settlement stage (the stage where payment and invoicing are made after goods acceptance).

[0066] Each business phase is bound to a phase policy set. The phase policy set dynamically constrains the scope of permissions for each business phase, ensuring that operations at each phase are limited to roles with the corresponding responsibilities, thus avoiding the risk of excessive permission granting. For example, in the order creation phase, the policy set is configured as follows: "Purchaser can edit order content (ensuring initial accuracy of order data), Supplier can only read (only needs to confirm order information, no need to modify permissions)", preventing suppliers from interfering with order data in advance and affecting subsequent verification; In the order execution phase, the policy set is configured as follows: "Supplier can update production progress (must be synchronized to the reconciliation data pool for subsequent verification), Logistics provider can read basic shipping information (prepare for delivery in advance, no editing permissions required)".

[0067] Based on preset sensitivity rules, the reconciliation data fields of each participant are classified into sensitivity levels, and a set of sensitivity policies is configured for each level. Sensitivity rules are usually formulated based on the business value of the data fields and the nature of the data. The data sensitivity level classification is the third dimension of the three-dimensional permission cube. In view of the differences in security risks of different fields in the identification of supply chain finance reconciliation data, a refined data protection mechanism is established. The sensitivity levels can be divided into public, internal, and confidential levels (hierarchical relationship: confidential > internal > public). Different levels directly determine the access scope and processing method of reconciliation data in the identification process.

[0068] For example: Order number (used only for reconciliation data identification, no sensitive information), product name (publicly verifiable transaction information), match public level rules; total price (directly related to the company's transaction scale, profit and other core business information), match internal level rules; recipient's phone number (belonging to personal privacy information) and supplier's bank account (related to key information for fund security), match confidential level rules.

[0069] A sensitivity policy set refers to a set of rules configured for each sensitivity level to guide data access and processing. It defines the default access permissions for different levels of data. For example, the public policy set allows access to all participants; the internal policy set restricts access to internal roles only; and the confidential policy set restricts access to high-privilege roles only.

[0070] Using roles, business stages, and sensitivity levels as dimensions, a three-dimensional permission cube with multiple intersections is constructed through orthogonal combinations. The role dimension is used as the X-axis, the business stage dimension as the Y-axis, and the sensitivity level dimension as the Z-axis. All combinations generated by the Cartesian product of the three dimensions represent an intersection, and the total number of intersections equals the product of the number of roles, business stages, and sensitivity levels.

[0071] In the three-dimensional permission cube, each intersection represents a specific role's permission configuration scenario for data of a specific sensitivity level at a specific business stage. For example, the intersection (purchaser role, order execution stage, confidential level) represents the purchaser's permission configuration for confidential data at the order execution stage.

[0072] Based on the basic permission set, stage policy set, and sensitivity policy set corresponding to each intersection point, a permission control parameter set is generated and stored in the corresponding intersection point, thus completing the construction of the three-dimensional permission cube. The three-dimensional permission cube is a data structure that contains permission configuration information for all combinations of roles, business stages, and sensitivity levels. The permission control parameter set is a structured dataset, which is stored in the storage location corresponding to the intersection point in the three-dimensional permission cube. The storage location is usually a database table or a memory cache, and its index is the three-dimensional coordinates of the intersection point.

[0073] Methods for generating a permission list include:

[0074] The system parses the requester's reconciliation data verification request and access token to obtain the requester's role, business stage, and target reconciliation data. Sensitivity rules are then used to determine the sensitivity level of each data field in the target reconciliation data. Upon receiving a reconciliation data verification request, the system first parses the access token provided by the requester. This parsing process obtains the requester's identity information and maps it to a preset role. From the reconciliation data verification request, the system identifies the current business stage of the requester and the target reconciliation data the requester seeks to access. For each field in the target reconciliation data, based on preset sensitivity rules, the sensitivity level corresponding to each data field can be determined (e.g., order number corresponds to public level, order amount corresponds to confidential level, and supplier bank account field corresponds to confidential level).

[0075] Based on the requester's role, business stage, and the sensitivity level of each field in the target reconciliation data, the corresponding intersection points are located in the three-dimensional permission cube. The permission control parameter sets stored at the corresponding intersection points are extracted, and the sensitivity level of the target reconciliation data is obtained. A three-dimensional coordinate index is established using the requester's role as the X-coordinate, the current business stage as the Y-coordinate, and the sensitivity level as the Z-coordinate. The corresponding intersection points are found in the cube. For example, the intersection points corresponding to the target reconciliation data include (supplier role, order execution stage, public level) and (supplier role, order execution stage, confidential level). Using the three-dimensional coordinates of the intersection points as indexes, the corresponding permission control parameter sets are read from the cube's storage structure. Each permission control parameter set contains permission configuration information under a specific combination of role, business stage, and sensitivity level.

[0076] Based on the extracted set of permission control parameters, a permission list for the requesting party regarding the target reconciliation data is generated. This permission list includes operation permissions and data access levels for each field. The permission list transforms the abstract set of permission control parameters into operational rules that can be directly applied to specific reconciliation data fields. It maps the general rules in the permission control parameter set to each specific field of the target reconciliation data, ultimately forming a refined "field-level" permission list. This ensures that every operation during the reconciliation data verification process has a clear permission basis.

[0077] Methods for generating reconciliation authorization sets and visible data views include:

[0078] Based on the data access levels in the permission list, each data field of the target reconciliation data is processed. This processing includes: retaining the original data for data fields within the specified access levels, and transforming data fields exceeding the specified access levels according to preset anonymization rules. The data access level indicates the maximum sensitivity level of data that the requesting party can access. If a data field in the target reconciliation data has a public sensitivity level, but its corresponding data access level in the permission list is internal, then since the "public" level does not exceed the "internal" level, access is permitted. The integrity and authenticity of this data field are maintained, and no form of modification or masking is performed.

[0079] If a data field in the target reconciliation data has a sensitivity level of confidential, but its corresponding data access level in the permission list is internal, it means that the sensitivity level of the data field exceeds the corresponding data access level. The desensitization rules should be applied to the data field that exceeds the data access level.

[0080] It should be explained that the de-identification rules are formulated based on the type of data field. For identification fields (ID number, account number) in the target reconciliation data, partial masking is used (e.g., the ID number field retains the first 4 and last 4 digits, and fills the middle with asterisks). For numeric fields (amount, quantity), numeric perturbation rules are used (e.g., inventory quantity 1234 is replaced with 1200±50). For text fields (age, address), generalization rules are used (e.g., 35 years old is replaced with 30-40 years old).

[0081] The processed data fields are then appended with the operation permissions specified in the permission list to form a reconciliation authorization set. The reconciliation authorization set is a data collection processed by access control, organized in a structured manner. Each record contains multiple fields, and each field is a composite object. The reconciliation authorization set includes all processed field data and their corresponding operation permissions.

[0082] The reconciliation authorization set and permission list are encapsulated and sent to the requesting client. The requesting client dynamically renders the received encapsulated data to generate a visible data view. The purpose of encapsulation is to combine the reconciliation authorization set and permission list into a complete, self-contained data packet, ensuring that the requesting client receives all the necessary information. The data packet uses a standard data exchange format to ensure that the requesting client can parse it correctly. The encapsulated data packet contains two main parts: the reconciliation authorization set provides the actual data content, and the permission list provides the data access and operation rules. The encapsulated data packet is sent to the front end through a streaming transmission strategy.

[0083] Dynamic rendering refers to the process by which the requesting client generates a user interface in real time based on the received data and permission information. It is dynamically constructed according to the actual permissions. The rendering engine first parses the encapsulated data packet, extracts the reconciliation authorization set and permission list, and then controls the display of interface elements according to the operation permission configuration in the permission list. For example, if the operation permission for a data field includes "view", then the data value of that field will be displayed on the interface; if the operation permission includes "export", then the export button will be displayed; if the operation permission includes "modify", then the field will be rendered as editable. For fields that have been de-identified, the requesting client will add visual cues when displaying them, such as using different font colors or adding icons, to remind the user that the data has been securely processed. The generated visible data view provides the requesting client with a secure and controlled data viewing and operation interface. The interface only displays data that the user has permission to view and only provides operation options that the user has permission to execute, ensuring the compliance and security of data access.

[0084] Methods for generating access control parameter sets include:

[0085] The basic permission set, stage policy set, and sensitivity policy set of each corresponding intersection point are merged and calculated to obtain the preliminary permission control parameter set. Unified computing is the process of merging three independent sets into a unified permission configuration. First, it extracts core elements related to reconciliation data operations from these three sets: a basic permission set provides the inherent operational scope of a role (e.g., suppliers can view orders); a stage policy set supplements business timing constraints (e.g., access to delivery addresses is only allowed during the logistics stage); and a sensitivity policy set adds data security rules, ensuring coverage of constraints across all dimensions of "role-stage-data". Initial integration is achieved using the formula "basic permissions + stage-specific permissions - stage-disabled permissions," for example, "the buyer's basic permissions include order editing rights + order creation stage-specific permissions allow price modification - order execution stage disables price modification." This addition and subtraction clearly defines effective permissions in specific scenarios, directly serving the dynamic management needs of reconciliation data at different stages. Next, it focuses on capturing operational conflicts related to reconciliation data identification (e.g., basic permissions allow editing but sensitivity policies prohibit editing the receiving phone number) and level conflicts (e.g., the supplier role's permission level is lower than the access requirements for confidential payment data). These conflicts are recorded together, forming an intermediate result that includes all permission items but may contain conflicts.

[0086] The system adjudicates permission conflicts existing in the initial permission control parameter set according to a preset priority principle. The priority principle is based on the core logic of prioritizing the security of supply chain finance reconciliation data and secondarily on business compliance. The priority order of permission rules is clearly defined as: sensitivity policy set > stage policy set > role basic permission set. That is, when multiple sets of rules conflict, the security attributes of reconciliation data are guaranteed first (sensitivity policy), then the time sequence compliance of the reconciliation process is ensured (stage policy), and finally the general permissions of the role are matched (basic permissions). This avoids the loss of control of permissions due to rule confusion, and accurately adapts to the security and compliance requirements identified for reconciliation data.

[0087] For example, the purchaser's basic permission set allows "modifying order quantity", but the phased policy set stipulates that "modification of core fields is prohibited during the order execution phase". Since the phased policy has higher priority than the basic permission, the final decision is "modification of order quantity is prohibited", which ensures the time sequence compliance of the reconciliation process and prevents subsequent data tampering from affecting the determination result.

[0088] Based on the ruling, a set of access control parameters is generated, including field operation permissions and data access levels. Field operation permissions map and record the allowed operation types for each field, while the data access level represents the highest sensitivity level at which raw data can be viewed. The generated access control parameter set is stored at the corresponding intersections of a three-dimensional access cube, serving as access configuration for specific scenarios. When a request needs to access data in that scenario, the system locates the corresponding intersection, extracts the access control parameter set, and generates a specific access list based on the parameter set to guide subsequent data access and processing. In this way, the system achieves flexible and secure access management, adapting to the needs of different business scenarios while ensuring the compliance and security of data access.

[0089] S3. Match the requester's reconciliation data with the reconciliation authorization set, mark the unmatched data fields as discrepancies, trigger the hierarchical response mechanism based on the type of discrepancies, and record the discrepancy processing results.

[0090] Methods for matching the requester's reconciliation data with the reconciliation authorization set include:

[0091] Using the reconciliation authorization set as a benchmark, the system matches the reconciliation data submitted by the requester according to preset reconciliation rules. Using the reconciliation authorization set as a benchmark ensures that the matching results align with the actual needs of supply chain finance reconciliation scenarios. The reconciliation rules are dynamically adjusted based on the data processing method in the reconciliation authorization set. For example, if the "transaction amount" field in the reconciliation authorization set is processed as a range value (e.g., 100±5 yuan), the corresponding matching rule will use "numerical range matching." If the field is processed as a partial mask (e.g., bank account number: 6228****1234), then plaintext partial matching is used, comparing only the unmasked first and last key characters, thus avoiding the exposure of sensitive information while ensuring the uniqueness of the data.

[0092] The matching process compares each data record in the reconciliation authorization set with the reconciliation data submitted by the requester. Based on key identification fields (such as order number and transaction serial number), it ensures that two corresponding records can be uniquely linked. After the key identification fields match successfully, sensitive fields subject to access control are then compared, and reconciliation rules adapted to the reconciliation authorization set are applied.

[0093] For example, the reconciliation authorization set: record A, containing order number: ORD-001 (plaintext) and transaction amount: 100±5 yuan (range value); requester data: record A1, containing order number: ORD-001 (plaintext) and transaction amount: 102 yuan; matching process: first, the order number is compared, and ORD-001 is found to be a successful match. The system knows that the "transaction amount" in the authorization set is a range value, that is, the numerical range matching rule is adopted. Since 102 yuan is within the range of [95,105], the match is determined to be successful.

[0094] For example, the reconciliation authorization set: record A, containing order number: ORD-001 (plaintext) and transaction amount: 100 yuan (plaintext); requester data: record A2, containing order number: ORD-001 (plaintext) and transaction amount: 102 yuan; matching process: first, the order number is compared, and it is found that ORD-001 matches successfully. The system knows that the "transaction amount" in the authorization set is an accurate value. Since it is 102 yuan, the matching is determined to be unsuccessful.

[0095] Unmatched data fields in the reconciliation data are marked as discrepancies, and these discrepancies are categorized based on their characteristics. During the field-by-field comparison, if a record in the reconciliation data fails to match any record in the reconciliation authorization set, that record is marked as a missing record discrepancy. If a record matches successfully, but its field value does not conform to the adapted reconciliation rules (e.g., the amount of 108 yuan submitted by the requester exceeds the range of 100±5 yuan), that field is marked as a field value discrepancy. Based on preset discrepancy characteristics, such as numerical discrepancies (values ​​exceeding the anonymization range or tolerance range), missing discrepancies (one party has data, the other party is missing data), and format discrepancies (data format does not conform to the expected pattern), all marked discrepancies are categorized.

[0096] The system automatically triggers a tiered response mechanism based on the type of discrepancy and records the results of the discrepancy processing. The tiered response mechanism has three levels: Level 1 (urgent handling), Level 2 (priority attention), and Level 3 (routine handling). When the discrepancy type of a field is obtained, the system determines its severity based on the discrepancy type, automatically triggers the tiered response, and records the results of the discrepancy processing. The results are stored in a structured record format, with each discrepancy record having a unique identifier linked to the original reconciliation task and related business data. The status of the processing result includes pending, processing, resolved, and ignored, reflecting the current progress of the discrepancy processing.

[0097] S4. Integrate the successfully matched data fields and the processed discrepancy data to generate a reconciliation data verification report and store it on the blockchain.

[0098] Methods for generating reconciliation data verification reports include:

[0099] The system integrates successfully matched data fields from the requester's pending reconciliation data with processed discrepancies to generate a reconciliation data verification report. During the matching process, two types of results are generated (successfully matched data fields and data fields marked as discrepancies). First, successfully matched data fields are recorded according to "Field Name - Authorization Set Value - Requester Value - Matching Status," while processed discrepancies are recorded according to "Field Name - Difference Type - Handling Measures - Handling Result - Time." This completes the entire process of discrepancy identification and resolution. Then, a reconciliation report template containing four modules—transaction entity, reconciliation cycle, core field summary, and discrepancy processing summary—is used to summarize the above, forming a reconciliation data verification report. This report clarifies the verification conclusion for each data item, laying the foundation for the subsequent generation of credible vouchers.

[0100] The hash value of the reconciliation data verification report is calculated using a hash algorithm and digitally signed. The hash value and digital signature are then written into the blockchain via a consortium blockchain smart contract, generating a reconciliation data verification certificate. The reconciliation data verification report is calculated using the SHA-256 hash algorithm to generate a unique hash value; even minor modifications to any character in the report will result in a different hash value. The hash value is digitally signed using the private key of the party generating the reconciliation data verification report (e.g., a supply chain finance platform), confirming that the report was generated by the platform and has not been tampered with by a third party, providing a reliable basis for subsequent financing approvals. Finally, a pre-set smart contract on the consortium blockchain is invoked to write the hash value and digital signature of the reconciliation data verification report into the blockchain for storage, generating a reconciliation data verification certificate and further ensuring the integrity and immutability of the data.

[0101] In this embodiment, by constructing an authentication model that includes identity verification, behavior analysis, and environmental awareness layers, comprehensive authentication of requester interfaces in the supply chain is achieved. Decentralized identity verification using blockchain technology enhances the system's anti-counterfeiting capabilities and avoids the risks of identity forgery and data tampering. The authentication model can not only accurately assess the credibility of the requester, but also determine in real time whether the requester meets the access requirements through behavior analysis and environmental verification, effectively preventing illegal access and injection of false data, ensuring the legality and reliability of the source of reconciliation data, and enhancing the security and stability of the system.

[0102] By pre-constructing a three-dimensional permission cube based on the roles, business processes, and sensitivity of reconciliation data in each supply chain on the blockchain, and then combining the requester's role, business stage, and data sensitivity, permission control parameter sets are obtained from the corresponding intersections in the three-dimensional permission cube, and a permission list is further obtained. Differentiated access control is implemented for sensitive data of different participants and different business links. Based on the permission list, permission verification and visible data view generation not only meet the requirements of data security, but also improve the convenience of user operation and reduce the possibility of operation errors.

[0103] By automatically matching the requester's data with the reconciliation authorization set through preset rules, a hierarchical response mechanism is triggered for discrepancies based on data type, achieving standardization and automation of discrepancy identification and processing, improving the overall efficiency and accuracy of reconciliation data identification, and writing the reconciliation data identification report into the blockchain after hash calculation and digital signature processing to form an immutable reconciliation voucher, ensuring the credibility of the identification results, while supporting full-chain traceability, providing reliable evidence for dispute resolution.

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

[0105] In the several embodiments provided by this invention, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only one method, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0106] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in the present invention should be included within the scope of protection of the present invention.

[0107] In conclusion, the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A blockchain-based method for verifying supply chain finance reconciliation data, characterized in that: The blockchain-based supply chain finance reconciliation data verification method includes: S1. By constructing an authentication model, the access request information of the requester interface in the supply chain is authenticated, and an access token is issued to the authenticated requester interface and the reconciliation data verification request is automatically triggered. S2. Construct a three-dimensional permission cube, determine the set of permission control parameters for the requester's access to the target reconciliation data based on the three-dimensional permission cube, and generate a permission list. Analyze the target reconciliation data based on the permission list to generate a reconciliation authorization set and a visible data view. Methods for constructing a three-dimensional permission cube include: Based on business responsibilities, the participants in the supply chain are divided into different roles and a basic permission set is configured for each role; the overall business process of the supply chain is broken down into several independent business stages and a stage policy set is bound to each business stage; based on preset sensitivity rules, the reconciliation data fields of each participant are divided into sensitivity levels and a sensitivity policy set is configured for each level. Using roles, business stages, and sensitivity levels as dimensions, a three-dimensional permission cube containing multiple intersection points is constructed through orthogonal combination. Based on the basic permission set, stage strategy set, and sensitivity strategy set corresponding to each intersection point, a permission control parameter set is generated and stored at the corresponding intersection point to complete the construction of the three-dimensional permission cube. Methods for generating a permission list include: Parse the requester's reconciliation data verification request and access token to obtain the requester's role, business stage, and target reconciliation data. Determine the sensitivity level of each data field in the target reconciliation data through sensitivity rules. Based on the requester's role, business stage, and sensitivity level of each field in the target reconciliation data, locate the corresponding intersection point in the three-dimensional permission cube and extract the permission control parameter set stored at the corresponding intersection point; Based on the extracted permission control parameter set, a permission list for the requester to access the target reconciliation data is generated, which includes operation permissions for each field and data access levels. S3. Match the requester's reconciliation data with the reconciliation authorization set, mark the unmatched data fields as discrepancies, trigger the hierarchical response mechanism based on the type of discrepancies, and record the discrepancy processing results. S4. Integrate the successfully matched data fields and the processed discrepancy data to generate a reconciliation data verification report and store it on the blockchain.

2. The blockchain-based supply chain finance reconciliation data verification method according to claim 1, characterized in that, The method for issuing access tokens to the authenticated requester interface and automatically triggering a reconciliation data verification request includes: Receive access request information from the requester's interface in the supply chain, wherein the access request information includes identity and qualification information, interface behavior data, and device physical environment information; An authentication model comprising an identity verification layer, a behavior analysis layer, and an environment awareness layer is constructed to perform multi-layer authentication of access request information. When all layers of authentication pass, an access token is issued to the requester's interface, and a reconciliation data verification request is automatically triggered for the requester holding the access token. If any layer of authentication fails, the requester's interface access is rejected.

3. The blockchain-based supply chain finance reconciliation data verification method according to claim 2, characterized in that, The authentication model employs a multi-layer authentication method for access request information, including: The identity verification layer obtains the decentralized identity of the requester based on the blockchain, compares and verifies it with the identity qualification information, and if the verification is consistent, transmits the interface behavior data to the behavior analysis layer. The behavior analysis layer performs weighted scoring on the interface behavior data, calculates the trust score and compares it with a preset threshold. If the score exceeds the preset threshold, the device's physical environment information is transmitted to the environment perception layer. The environment perception layer verifies the physical environment information of the device by deploying an edge authentication gateway and combining the set trusted execution environment and trusted chip verification mechanism.

4. The blockchain-based supply chain finance reconciliation data verification method according to claim 1, characterized in that, The method for generating the reconciliation authorization set and the visible data view includes: Based on the data access level in the permission list, the corresponding data fields of the target reconciliation data are processed. The processing includes: retaining the original data for data fields that do not exceed the data access level, and transforming data fields that exceed the data access level according to the preset desensitization rules. The processed data fields are appended with the operation permissions specified in the permission list to form a reconciliation authorization set; The reconciliation authorization set and permission list are encapsulated and sent to the requesting client. The requesting client dynamically renders the received encapsulated data to generate a visible data view.

5. The blockchain-based supply chain finance reconciliation data verification method according to claim 1, characterized in that, The method for generating the access control parameter set includes: The basic permission set, stage strategy set, and sensitivity strategy set of each corresponding intersection point are merged and calculated to obtain the initial permission control parameter set; The permission conflicts existing in the initial permission control parameter set are adjudicated according to the preset priority principle, and a permission control parameter set containing field operation permissions and data access levels is formed based on the adjudication results.

6. The blockchain-based supply chain finance reconciliation data verification method according to claim 1, characterized in that, The method for matching the requester's reconciliation data with the reconciliation authorization set includes: Using the reconciliation authorization set as a benchmark, the data to be reconciled submitted by the requester is matched according to the preset reconciliation rules. Data fields that fail to match in the data to be reconciled are marked as discrepancies, and the discrepancies are classified according to their characteristics. The corresponding hierarchical response mechanism is automatically triggered based on the type of difference, and the result of the difference processing is recorded.

7. The blockchain-based supply chain finance reconciliation data verification method according to claim 1, characterized in that, The method for generating the reconciliation data verification report includes: Integrate the successfully matched data fields in the requester's pending reconciliation data with the processed discrepancies to generate a reconciliation data verification report; The hash value of the reconciliation data verification report is calculated using a hash algorithm and digitally signed. The hash value and digital signature of the reconciliation data verification report are then written into the blockchain through a consortium blockchain smart contract to generate a reconciliation data verification certificate.

Images