A cross-institutional financial service gateway adaptation method and system

Abstract

This application provides a method and system for cross-institutional financial service gateway adaptation, relating to the fields of fintech and blockchain technology. It solves the technical problems in existing technologies, such as difficulties in interfacing heterogeneous systems, low adaptation efficiency, poor scalability, and static, fixed routing decisions, and reliance on manual coordination for network governance, caused by inconsistent data standards among institutions. The method includes: a first gateway and a second gateway generating a temporary data conversion mapping through a graph matching algorithm to complete format conversion; querying the behavior proof consortium blockchain before a transaction to obtain historical behavior scores and dynamically selecting a routing path; updating the score by uploading a behavior summary to the blockchain after a transaction; and smart contracts deployed on the consortium blockchain supporting automatic upgrades through weighted voting. This application is used for gateway adaptive adaptation and trusted routing decisions in the process of cross-institutional financial business collaboration.

Description

Technical Field

[0001] This invention belongs to the field of blockchain technology, specifically a method and system for adapting cross-institutional financial service gateways. Background Technology

[0002] With the deepening of online financial services and cross-institutional cooperation, different financial institutions need to conduct more and more real-time data interaction and business collaboration. However, the core business systems of different institutions are often built at different times, and their data models, message formats, field definitions, and constraint rules vary significantly, leading to serious heterogeneous data interoperability problems when institutions conduct business connections. Traditional solutions mainly adopt two approaches: one is to rely on industry-wide unified standards to define a global message format, with each institution modifying its system and adapting interfaces according to the standard; the other is to use a centralized gateway or mapping service platform, pre-configuring a conversion rule library between the data formats of each institution, with the central node completing message translation and routing forwarding. These methods have solved the data format incompatibility problem during point-to-point connections to a certain extent.

[0003] However, the existing solutions still have some problems in practical applications. First, the development and revision cycle of unified standards is long, making it difficult to quickly respond to business innovation needs. Furthermore, different institutions have varying degrees of localization in their understanding and implementation of the standards, leading to compatibility issues and high costs and long implementation cycles. Centralized mapping solutions face scalability bottlenecks, such as the huge workload of maintaining the conversion rule base and the need to configure mapping relationships one by one when adding new institutions or changing business. At the same time, the central node is prone to becoming a performance bottleneck and a single point of failure. Second, the routing selection for cross-institutional transactions in existing solutions is mostly statically configured, lacking an effective evaluation and dynamic feedback mechanism for the real-time service quality of gateway nodes. When a gateway in an institution experiences performance degradation or anomalies, upstream institutions cannot detect and switch paths in a timely manner, leading to an increased transaction failure rate.

[0004] Furthermore, the aforementioned solutions all rely to varying degrees on pre-defined standardized specifications or centralized rule management. Once the standards are adjusted or the business scenarios expand, each participant needs to repeatedly modify the system and update the rules. The system maintenance and communication costs increase exponentially with the number of participants. Therefore, there is an urgent need for a solution that can achieve adaptive data transfer, dynamic trusted routing, and automated evolution of governance rules between cross-organizational gateways without relying on pre-defined unified standards and centralized mapping. Summary of the Invention

[0005] This application provides a cross-institutional financial service gateway adaptation method and system, which solves the technical problems in the prior art, such as difficulty in connecting heterogeneous systems due to inconsistent data standards among institutions, and low adaptation efficiency and poor scalability caused by reliance on centralized mapping tables or preset message standards.

[0006] To achieve the above objectives, this application adopts the following technical solution: Firstly, a method for adapting cross-institutional financial service gateways is provided, including: The first gateway and the second gateway each generate a temporary data conversion mapping for the current session based on their locally maintained domain ontology and data structure semantic fingerprints, and complete the format conversion of business data through graph matching algorithms. Before the transaction is executed, the first gateway queries the behavior proof consortium blockchain for the historical behavior score of the second gateway, and selects the execution path based on the score and the preset routing strategy; After the transaction is completed, both parties will digitally sign the behavior digest containing communication quality, negotiation efficiency and eventual consistency results and submit it to the behavior proof consortium blockchain storage to update the behavior score of the second gateway and complete the gateway adaptation; The behavior proof consortium blockchain is equipped with smart contracts that allow nodes to submit correction proposals and drive automatic contract upgrades through weighted voting based on behavior scores, dynamically adjusting the weight parameters of the scores and the negotiation timeout threshold.

[0007] Based on the above technical solutions, the cross-institutional financial service gateway adaptation method provided in this application achieves real-time mutual conversion of heterogeneous data formats by having the first gateway and the second gateway conduct point-to-point dynamic semantic negotiation based on local domain ontology and semantic fingerprints, without relying on any preset unified message standard or centralized mapping table. This fundamentally solves the compatibility bottleneck caused by standard differences in traditional adaptation methods. A closed-loop feedback mechanism is implemented, which queries historical behavior scores on the pre-transaction behavior proof consortium blockchain and dynamically selects routing paths based on the scores, and updates the scores by uploading behavior summaries to the blockchain after transactions. This achieves dynamic quantitative evaluation of gateway service quality and reliable routing decisions. Furthermore, smart contracts deployed on the behavior proof consortium blockchain support nodes to submit amendment proposals and automatically upgrade through weighted voting, enabling the network's scoring weight parameters and negotiation timeout thresholds to adaptively evolve with business development, allowing for dynamic adjustment of governance rules without manual coordination or hard forks. The synergistic effect of these methods significantly improves the flexibility, reliability, and evolvability of cross-institutional gateway adaptation.

[0008] Furthermore, the domain ontology uses RDF triples to describe the organization's internal data model, including entity type, entity attributes, and constraints between attributes. Each entity node pre-stores a standard semantic label calculated based on its own data structure. The semantic fingerprint of the data structure is a hash value calculated by concatenating the field names, types, lengths, and constraints of the data structure in sequence.

[0009] Furthermore, the graph matching algorithm is a subgraph isomorphic matching algorithm based on locality-sensitive hash pre-screening, enabling the first gateway and the second gateway to perform point-to-point semantic negotiation through broadcast semantic fingerprint and locality-sensitive hash collision to complete the generation of the temporary data transformation mapping. The specific workflow includes: Step 1: The first gateway extracts the field types, field lengths, and constraint relationships of the data structure to be sent, generates a semantic fingerprint sequence representing the data structure to be sent through hash operation, and broadcasts the semantic fingerprint sequence to the second gateway along with the service request; Step 2: The second gateway uses the received semantic fingerprint sequence as a query vector and performs local sensitive hash mapping with the standard semantic tags of each entity node in the domain ontology. The semantic fingerprint sequence and each standard semantic tag are mapped to binary hash buckets of the same length, and entity nodes with the same bucket number are selected to form a candidate matching node set. Step 3: Select a node from the candidate matching node set as the current matching starting point. Starting from the root node of the data structure subgraph corresponding to the current matching node, use a depth-first search strategy to traverse all field nodes of the requested data structure. During the traversal, use node type and edge relationship as the first matching constraint and attribute value range and constraint conditions as the second matching constraint. Check layer by layer whether the field node currently traversed can find the corresponding node in the subgraph. Step 4: If the current node and all its child nodes satisfy all matching constraints, record the one-to-one correspondence between the current candidate node and each field in the request data structure to form a field mapping table. Based on the correspondence, generate a forward conversion mapping from the data structure to be sent by the first gateway to the internal data structure of the second gateway, and a reverse conversion mapping from the response data structure of the second gateway to the recognition format of the first gateway. Combine the forward conversion mapping and the reverse conversion mapping into the temporary data conversion mapping, and terminate the matching process. Step 5: If any field of the current candidate node does not meet the matching constraint during the traversal, then abandon the current candidate node and select the next node from the set of candidate matching nodes to repeat step 3. Step 6: If none of the nodes in the candidate matching node set can satisfy all matching constraints, then the semantic negotiation is deemed to have failed.

[0010] Furthermore, the specific generation process of the temporary data transformation mapping includes: Extract the field correspondence in the field mapping table. For each field in the data structure to be sent in the first gateway, find the target field in the internal data structure of the second gateway and generate an assignment code sequence from the source field to the target field. For source and target fields with inconsistent data types, a preset type conversion function is inserted into the assignment code sequence; For fields that exist in the request data structure but not in the second gateway domain ontology, default value filling logic is inserted into the assignment code sequence according to the default value filling rules of the corresponding entity node in the second gateway domain ontology. The assignment code sequence is compiled into executable machine code using the LLVM just-in-time compilation framework, and used as the forward transformation mapping; The reverse transformation mapping is generated in reverse order as described above. The forward transformation map and the reverse transformation map are encapsulated into a bidirectional transformation function object, which is stored in memory as the temporary data transformation map.

[0011] Furthermore, the Proof-of-Behavior consortium blockchain is a permissioned blockchain based on the PBFT (Practical Byzantine Fault Tolerance) consensus protocol, and the nodes of the Proof-of-Behavior consortium blockchain are the gateways of each participating financial structure; the data stored on the Proof-of-Behavior consortium blockchain is the behavioral summary of each gateway and the aggregated statistical values, and the Proof-of-Behavior consortium blockchain does not store transaction details or customer privacy information.

[0012] Furthermore, the step of selecting the execution path based on the score and the preset routing strategy specifically includes: The first gateway sets a priority preference for reliability or cooperation based on the business type and amount level of the current transaction; After querying the historical behavior score of the second gateway, if the historical behavior score is higher than the set threshold, the direct connection execution path is selected to send the transaction request directly. If the historical behavior score is lower than the set threshold, a path through a third-party gateway is selected, or a pre-verification process is triggered; the pre-verification process includes sending a test message to the second gateway to verify the response capability.

[0013] Furthermore, the process of obtaining the behavioral summary specifically includes: After the transaction is completed, both parties record the metadata of this interaction; the metadata includes the total communication time, negotiation success flag, conversion time field, cache hit flag, timeout or exception flag, and eventual consistency achievement flag, among which, The total communication time is obtained by the difference between the timestamps of the transaction initiation time and the transaction completion time; The successful negotiation flag is obtained by recording whether the graph matching algorithm successfully formed the field mapping table; if yes, it is marked as 1; if no, it is marked as 0. The conversion time field is obtained by recording the time interval between the second gateway receiving the semantic fingerprint sequence and generating a temporary data conversion mapping. The cache hit flag is obtained by recording whether the current communication directly hits the cache through a temporary data conversion mapping. If the cache is hit, it is marked as 1; otherwise, it is marked as 0. The timeout or exception flag is obtained by recording whether a preset timeout threshold is triggered or an exception is thrown during the graph matching algorithm or transaction execution. If a timeout or exception is triggered, it is marked as 1; otherwise, it is marked as 0. Both parties assemble all their recorded metadata into a structured digest database, and the private key of this gateway digitally signs the structured digest data to generate the behavior digest.

[0014] Furthermore, the historical behavior score includes a reliability score and a cooperativeness score; The reliability score is calculated based on the consistency achievement rate and timeout rate in the historical behavior summary of the second gateway, and the cooperation score is calculated based on the semantic negotiation success rate and the average efficiency of the transformation function; the semantic negotiation success rate is the proportion of the number of times the second gateway successfully negotiated in historical interactions to the total number of negotiations, which is obtained by statistically analyzing the negotiation success flags in the behavior summary stored on the blockchain. The average efficiency of the conversion function is the arithmetic mean of the time required for each temporary data conversion mapping generated in the history of the second gateway from matching to generation, which is calculated by extracting the conversion time field in the behavior summary; The score is calculated by weighted summation of weight coefficients encoded in the smart contract and is updated in real time with each new behavior summary uploaded to the blockchain.

[0015] Furthermore, the smart contract also encodes core network rules, specifically including: The smart contract includes fixed encoding of node admission conditions, the weight coefficients corresponding to the reliability score and the cooperation score, the negotiation timeout threshold of the graph matching algorithm, the preset proportion threshold required for weighted voting to pass, and the judgment conditions and execution logic for triggering punishment measures when a node's behavior score threshold is continuously lower than the minimum threshold. The node admission criteria include the minimum hardware configuration requirements, minimum network bandwidth requirements, and initial behavior score assignment rules that new gateway nodes must meet when registering. The penalty measures include: when the smart contract detects that the behavior score of any node is lower than the minimum threshold in a preset number of consecutive interactions, it automatically performs a demotion operation, reducing the priority of the node in routing selection to the lowest level, or suspending the node's eligibility to participate in semantic negotiation.

[0016] Furthermore, the proposed amendment includes rule parameters to be modified or new logic code segments, and the acquisition process includes: When any gateway node detects that the current network operation index deviates from the preset range, it determines the type and adjustment range of the rule parameter to be adjusted based on the difference between the network operation index and the preset target value, and encapsulates the type, adjustment range and current value of the rule parameter to be adjusted as a key-value pair format correction proposal and submits it to the behavior proof consortium chain. When any gateway node writes new functional logic based on business development needs or security upgrade needs, the new functional logic is compiled into smart contract bytecode, and encapsulated as a new logic code segment as a correction proposal and submitted to the behavior proof consortium chain. The network operation metrics include the average latency of transactions across the entire network, the average time for semantic negotiation, the variance of node behavior score distribution, and the consensus confirmation latency.

[0017] Furthermore, the supporting nodes submit amendment proposals and drive automatic contract upgrades through weighted voting based on behavior scores, specifically including: Any gateway node submits a modification proposal to the proof-of-behavior consortium blockchain; The proposed amendments have entered a public comment period, during which nodes can express their opinions through the on-chain review function. After the public announcement period ends, the voting period begins, and the voting weight of each node is the normalized value of the current behavior score; When the total weight of the affirmative votes reaches a preset proportion, the smart contract is upgraded and the revised proposal is written into the contract storage space.

[0018] Furthermore, the submission of the behavior summary to the behavior proof consortium blockchain adopts an asynchronous batch on-chain mechanism: The gateway node caches multiple behavior summaries locally within a preset number or preset time window, aggregates the multiple behavior summaries to generate a Merkle root hash, and submits the Merkle root hash and the aggregated statistical value as a transaction to the blockchain. After the consensus node of the behavior proof consortium chain verifies the signature, it stores the aggregated statistical value into a block and saves the behavior digest in the off-chain index storage for verification during querying.

[0019] Furthermore, if the graph matching algorithm fails to find a complete field mapping relationship within a preset timeout period, the second gateway returns a semantic negotiation failure response, along with a representation of the unmatched fields; After receiving the failure response, the first gateway initiates a fallback mechanism, converts the data to be sent into a general self-describing format and resends it, and simultaneously uploads a summary of the failed negotiation behavior to the blockchain to update the cooperation score of the second gateway.

[0020] Secondly, this application provides a cross-institutional financial service gateway adaptation system, including: a semantic negotiation module, a routing decision module, and a behavior management module; wherein, The semantic negotiation module is configured in the first gateway and the second gateway, and is used to enable the first gateway and the second gateway to generate a temporary data conversion mapping for the current session based on the domain ontology and data structure semantic fingerprint maintained locally, and to complete the format conversion of business data. The routing decision module is configured in the first gateway and is used to query the historical behavior score of the second gateway in the forward behavior proof consortium chain before transaction execution, and select the execution path according to the score and the preset routing strategy. The behavior management module is configured in the first gateway and the second gateway. After the transaction is completed, it submits the behavior digest containing communication quality, negotiation efficiency and eventual consistency result to the behavior proof consortium chain storage after digital signature, updates the behavior score of the second gateway, and completes the gateway adaptation. The behavior proof consortium blockchain is equipped with smart contracts that allow nodes to submit correction proposals and drive automatic contract upgrades through weighted voting based on behavior scores, dynamically adjusting the weight parameters of the scores and the negotiation timeout threshold.

[0021] Compared with the prior art, the beneficial effects of this application are: This application utilizes a point-to-point dynamic semantic negotiation between a first gateway and a second gateway based on local domain ontology and data structure semantic fingerprints. It employs a graph matching algorithm combining locality-sensitive hashing pre-screening and subgraph isomorphic matching, enabling automatic identification and conversion mapping of heterogeneous data formats without relying on any pre-defined unified message standard or centralized mapping table. This method reduces the adaptation costs caused by standard discrepancies when interfacing with gateways across institutions. Furthermore, by using field-level constraint matching and just-in-time compilation to generate bidirectional conversion functions and caching for reuse, it significantly improves the accuracy and efficiency of data conversion between heterogeneous systems.

[0022] This application constructs a behavior proof consortium blockchain based on the PBFT consensus protocol. It stores the behavioral digest of each interaction on the blockchain after digital signing, and combines reliability and cooperation scores to form a dynamic historical behavior score. This allows for quantitative evaluation and reliable traceability of the gateway's service quality. Before a transaction, priority preferences are set based on business type and amount level, and direct or detour routing paths are dynamically selected based on the score. This effectively achieves reliable routing decisions and load balancing for cross-institutional transactions. Simultaneously, by updating the score with metadata of negotiation failures or transaction anomalies on the blockchain, a closed-loop feedback mechanism is formed, continuously optimizing the accuracy of subsequent routing selections and significantly improving the transaction success rate and system robustness of the entire gateway network.

[0023] Furthermore, this application encodes core network rules such as node admission criteria, scoring weight coefficients, negotiation timeout thresholds, and penalty measures into smart contracts on a behavior proof consortium blockchain, enabling the codification and automated execution of network governance rules. Nodes can dynamically generate amendment proposals based on network performance indicators, and automatically upgrade contracts after public announcement and weighted voting based on behavior scores. This achieves distributed adaptive adjustment of key parameters such as scoring weights and negotiation thresholds, allowing for smooth evolution without manual coordination or hard forks. The synergistic effect of these mechanisms provides a complete technical solution for cross-institutional financial service gateways, combining high compatibility, high reliability, and strong self-evolution capabilities. Attached Figure Description

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

[0025] Figure 1 A system architecture diagram of a cross-institutional financial services gateway adaptation system provided in this application embodiment; Figure 2 A flowchart illustrating a cross-institutional financial services gateway adaptation method provided in this application embodiment; Figure 3 A flowchart illustrating another cross-institutional financial services gateway adaptation method provided in this application embodiment; Figure 4 A flowchart illustrating another cross-institutional financial services gateway adaptation method provided in this application embodiment; Figure 5 This is a flowchart illustrating another cross-institutional financial services gateway adaptation method provided in an embodiment of this application. Detailed Implementation

[0026] In the description of this application, unless otherwise stated, " / " means "or," for example, A / B can mean A or B. The "and / or" in this document is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, and B alone. Furthermore, "at least one" means one or more, and "multiple" means two or more. The terms "first," "second," etc., do not limit the quantity or order of execution, and "first," "second," etc., do not necessarily imply differences.

[0027] It should be noted that, in this application, the terms "exemplary" or "for example" are used to indicate that something is being described as an example, illustration, or illustration. Any embodiment or design described as "exemplary" or "for example" in this application should not be construed as being more preferred or advantageous than other embodiments or design solutions. Specifically, the use of terms such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner.

[0028] The cross-institutional financial service gateway adaptation method provided in this application embodiment can be applied to, for example... Figure 1 In a cross-institutional financial services gateway adaptation system, as shown, Figure 1 As shown, the system includes: a semantic negotiation module, a routing decision module, and a behavior management module; among which, The semantic negotiation module, configured in the first gateway and the second gateway, is used to enable the first gateway and the second gateway to generate a temporary data conversion mapping for the current session based on the domain ontology and data structure semantic fingerprint maintained locally, and to complete the format conversion of business data. The routing decision module, configured in the first gateway, is used to query the historical behavior score of the second gateway before transaction execution by the behavior proof consortium chain, and select the execution path based on the score and the preset routing strategy. The behavior management module, configured in the first and second gateways, is used to submit a behavior digest containing communication quality, negotiation efficiency, and eventual consistency results to the behavior proof consortium blockchain after a transaction is completed, after digital signature, to update the behavior score of the second gateway and complete gateway adaptation. The behavior proof consortium blockchain is equipped with smart contracts that support nodes to submit correction proposals and drive automatic contract upgrades through weighted voting based on behavior scores, dynamically adjusting the weight parameters of the scores and the negotiation timeout threshold.

[0029] To address the technical challenges in existing cross-institutional financial transaction scenarios, such as inconsistent data formats among heterogeneous systems, lack of trusted behavior assessment and dynamic routing mechanisms for gateway nodes, and the rigidity of gateway adaptation rules that makes them difficult to adapt to evolving business environments, this application provides a cross-institutional financial service gateway adaptation method and system. The method includes: The first gateway and the second gateway each generate a temporary data conversion mapping for the current session based on their locally maintained domain ontology and data structure semantic fingerprints, and complete the format conversion of business data through graph matching algorithms. Before the transaction is executed, the first gateway queries the behavior proof consortium chain for the historical behavior score of the second gateway, and selects the execution path based on the score and the preset routing strategy; After the transaction is completed, both parties will digitally sign the behavior summary containing communication quality, negotiation efficiency and eventual consistency results and submit it to the behavior proof consortium blockchain for storage, update the behavior score of the second gateway and complete the gateway adaptation; smart contracts are deployed on the behavior proof consortium blockchain, which supports nodes to submit correction proposals and drive the contract to automatically upgrade through weighted voting based on behavior scores, dynamically adjusting the weight parameters of the scores and the negotiation timeout threshold.

[0030] Based on this, this application achieves semantic consistency at the data conversion level, credibility at the routing decision level, and adaptability at the rule evolution level for cross-institutional financial gateways by sinking semantic understanding capabilities to the gateway local, introducing blockchain trusted behavior assessment and dynamic routing, and establishing a contract self-evolution mechanism based on behavior proof. This effectively reduces the semantic friction cost of heterogeneous system docking and improves the overall efficiency and security of cross-institutional transactions.

[0031] like Figure 2 As shown in the figure, an embodiment of this application provides a cross-institutional financial services gateway adaptation method, including: S1, the first gateway and the second gateway each generate a temporary data conversion mapping for the current session based on their locally maintained domain ontology and data structure semantic fingerprints, and complete the format conversion of business data.

[0032] Domain ontology is a formalized description of concepts, entities, and their relationships within a specific business domain, used to characterize the semantic structure of data models within various financial institutions. In cross-institutional financial gateway scenarios, domain ontology defines standardized descriptions of all core concepts and their relationships within that financial service domain, such as the definitions of concepts like "transaction account," "order type," "settlement currency," and "transaction status," as well as the hierarchical relationships, associations, and constraint rules between these concepts. Domain ontology provides a unified semantic reference framework for heterogeneous data, enabling different institutions to achieve a consistent semantic understanding even with different data structures.

[0033] Semantic fingerprinting of data structures is a compressed representation and semantic summary of a data structure. Specifically, a semantic fingerprint transforms the complete description of a data structure into a fixed-length binary vector or numerical sequence using a specific hashing or feature extraction algorithm. This fingerprint uniquely identifies the semantic features of the data structure. On the one hand, semantic fingerprinting reduces the computational complexity of data structure matching, transforming complex structure comparisons into efficient fingerprint similarity calculations. On the other hand, it allows gateways to complete matching without exposing complete data structure details, thus protecting the privacy of internal data models within various organizations.

[0034] Graph matching algorithms are used to find the correspondence between nodes and edges between different graph structures. In gateway data transformation scenarios, the first and second gateways represent their respective data structure descriptions as graph structures—where nodes represent data fields or data entities, and edges represent relationships or constraints between fields. By calculating the semantic similarity of nodes and the degree of structural isomorphism between two graph structures, graph matching algorithms can automatically discover semantically corresponding field mapping relationships between two data structures, eliminating the need for manual configuration of field correspondences and reducing the configuration cost of cross-institutional data integration.

[0035] In some implementations, the domain ontology can be formally described using a web ontology language, and each gateway periodically performs consistency checks and redundancy elimination on its local domain ontology through an ontology inference engine. The generation of semantic fingerprints for data structures can be achieved as follows: first, extract metadata information from the data structure, including field names, data types, value ranges, and constraints; then, perform standardized preprocessing on this metadata information; finally, use a locality-sensitive hashing algorithm or a fingerprint extraction algorithm based on latent semantic analysis to generate a fixed-length semantic fingerprint vector.

[0036] It should be noted that the temporary data transformation mappings generated by each gateway are only valid within the current session's lifecycle and become invalid after the session ends. This design ensures flexibility for each data transformation while avoiding the security risks that permanent mapping rules might pose.

[0037] For example, suppose the institution hosting the first gateway uses the "Customer Number" field to identify transaction customers, while the institution hosting the second gateway uses the "User ID" field to identify the same concept. In traditional gateway adaptation schemes, this field correspondence needs to be predefined manually in a configuration file. However, in this application, the first gateway constructs its own data structure as graph G1, and the second gateway constructs its own data structure as graph G2. The graph matching algorithm automatically identifies that the "Customer Number" node in G1 and the "User ID" node in G2 semantically point to the same concept, and establishes a temporary conversion mapping of "Customer Number → User ID" in the current session, thereby realizing automatic format conversion of business data.

[0038] S2. Before the transaction is executed, the first gateway queries the behavior proof consortium chain for the historical behavior score of the second gateway, and selects the execution path based on the score and the preset routing strategy.

[0039] Among them, the Proof-of-Behavior Consortium Blockchain is a consortium blockchain network based on the Proof-of-Behavior consensus mechanism. Proof-of-Behavior is a blockchain consensus model that assigns a hierarchical utility score to each action and updates the influence weight of each node in real time based on its recent behavior. In the Proof-of-Behavior Consortium Blockchain, each participating institution acts as a consortium blockchain node, and its historical behavior records (including communication quality, negotiation efficiency, transaction success rate, and eventual consensus achievement) are immutably recorded on the chain. The Proof-of-Behavior Consortium Blockchain constructs a decentralized, immutable, and traceable gateway behavior trust assessment infrastructure. Compared with public blockchains, the consortium blockchain's access mechanism ensures the traceability of the true identities of participating institutions, making it more suitable for the compliance requirements of financial scenarios.

[0040] Cross-institutional financial transactions typically involve multiple possible relay or direct paths, with significant differences in communication quality, latency, success rate, and security among these paths. The historical performance of the second gateway, acting as the target or intermediary gateway, directly determines the successful completion of the transaction. By querying the historical performance score of the second gateway, the first gateway can assess the reliability of the target gateway before transaction execution, thereby selecting the optimal execution path and improving the overall success rate of cross-institutional financial transactions.

[0041] In some implementations, the historical behavior score on a proof-of-behavior consortium blockchain can include sub-scores across multiple dimensions, such as communication quality score, negotiation efficiency score, eventual consistency score, and security score. When the first gateway queries the historical behavior score of the second gateway, it can assign different weights to the sub-scores of different dimensions based on the specific type of the current transaction and business requirements, thereby calculating a comprehensive score for routing decisions. Preset routing strategies can take various forms: for example, a threshold strategy—selecting only gateway nodes with a comprehensive score higher than a preset threshold; a ranking strategy—selecting several nodes with the highest comprehensive scores and performing load balancing; or a differentiation strategy—selecting the node with the highest score for high-value transactions, while considering load distribution while meeting basic score requirements for ordinary transactions.

[0042] It should be noted that the historical behavior scores on the behavior proof consortium blockchain are dynamically updated. After each transaction, the behavior summaries submitted by both parties are used to update the scores of the relevant gateways. Therefore, the score queried by the first gateway before the transaction is executed reflects the latest behavior of the second gateway up to the time of the query, possessing real-time performance and reliability.

[0043] For example, suppose a first gateway needs to initiate an inter-institutional transfer transaction to a second gateway. Before the transaction is executed, the first gateway sends a query request to the behavioral proof consortium blockchain to obtain the second gateway's historical behavioral score. The query results show that the second gateway's communication quality score is 0.95, negotiation efficiency score is 0.88, eventual consistency score is 0.92, and overall score is 0.91 in the past 1000 transactions. Based on a preset routing strategy, the first gateway determines that the overall score of 0.91 is higher than the minimum threshold of 0.80, therefore selecting the second gateway as the transaction target and continuing to execute the transaction. If the second gateway's overall score is lower than the threshold, the first gateway will either select another available alternative gateway or abort the transaction.

[0044] S3. After the transaction is completed, both parties will submit a behavior summary containing communication quality, negotiation efficiency and eventual consistency results to the behavior proof consortium blockchain storage after digital signature, update the behavior score of the second gateway, and complete the gateway adaptation.

[0045] Gateway adaptation refers to the process by which the first and second gateways adjust and optimize their subsequent gateway interaction strategies based on the actual situation of a cross-institutional transaction after completion. Specifically, gateway adaptation includes the following levels: The first level is the adaptation of data transformation mappings—the execution effect of temporary data transformation mappings generated in this transaction (e.g., whether the transformation is correct, whether any fields are missing, etc.) is recorded. If a deviation in the mapping is found, the parameters of the graph matching algorithm are adjusted or manual feedback is introduced for correction in the next transaction with that gateway. The second level is the adaptation of routing strategies—the communication quality, negotiation efficiency, and eventual consistency results of this transaction are incorporated into the second gateway's historical behavior score, thus affecting the routing selection of subsequent transactions. The third level is the adaptation of contract parameters—the smart contract on the behavior proof consortium blockchain dynamically adjusts the weight parameters of the score and the negotiation timeout threshold based on accumulated behavior summary data. Through these three levels of adaptation, the gateway can continuously optimize its behavior strategy as transaction experience accumulates, achieving smart gateway adaptation.

[0046] Behavioral scoring-based weighted voting-driven contract upgrades refer to a decentralized governance mechanism supported by smart contracts on a behavior-based consortium blockchain. In this mechanism, any consortium blockchain node can submit proposals to modify contract upgrades, such as adjusting the weight coefficients of various dimensions in the scoring algorithm, modifying the default value of the negotiation timeout threshold, or optimizing the data structure of the behavior summary. After a proposal is submitted, all consortium blockchain nodes receive corresponding voting weights based on their historical behavioral scores. Once the vote passes, the smart contract automatically executes the upgrade without manual intervention or downtime maintenance.

[0047] In some implementations, the data structure of the behavior digest can be designed to include the following fields: transaction identifier, first gateway identifier, second gateway identifier, transaction timestamp, communication quality metrics (such as round-trip latency, packet loss rate, throughput, etc.), negotiation efficiency metrics (such as negotiation rounds, negotiation time, etc.), eventual consistency result (such as whether the transaction was successful, whether the data is consistent, etc.), and digital signatures of both participating parties. After the behavior digest is submitted to the behavior proof consortium blockchain, it is confirmed to be on-chain through the consortium blockchain's consensus mechanism, and once on-chain, it cannot be tampered with.

[0048] It's important to note that the submission of behavioral summaries is bidirectional—each party involved in the transaction independently generates and submits a behavioral summary, rather than having one party submit it on their behalf. If there are significant differences between the summaries submitted by one party and those submitted by the other, the consensus nodes of the consortium blockchain can identify potential disputes or malicious behavior by comparing the summaries from both parties.

[0049] For example, suppose that after the first gateway and the second gateway complete an inter-institutional payment transaction, the first gateway records the communication quality of this transaction as a latency of 120 milliseconds and no packet loss, the negotiation efficiency as two rounds of negotiation and a time of 80 milliseconds, and the final consistency result as a successful transaction and consistent accounts. The first gateway encapsulates this information into a behavior digest, digitally signs it using its own private key, and submits it to the behavior proof consortium blockchain. The second gateway also generates and submits its own behavior digest. After the consensus nodes of the consortium blockchain verify the digital signatures and content consistency of the two digests, they package the digests and upload them to the blockchain. The smart contract updates the historical behavior score of the second gateway based on a preset scoring algorithm and the behavior digest of this transaction. At the same time, the smart contract detects that the occurrence rate of negotiation timeout events in the 1000 recently submitted behavior digests has increased by 15% compared to the previous period, and automatically initiates a correction proposal, suggesting that the negotiation timeout threshold be adjusted from 30 seconds to 35 seconds. Each node obtains voting weight based on its own behavior score and votes. After the proposal is passed, the smart contract automatically completes the parameter upgrade.

[0050] Based on the above technical solutions, this application provides a cross-institutional financial service gateway adaptation method. By combining domain ontology with data structure semantic fingerprints and using graph matching algorithms to achieve session-level temporary data conversion mapping, it effectively solves the semantic consistency problem of automatic data format conversion between heterogeneous financial systems. By introducing a behavior proof consortium blockchain to store the historical behavior scores of each gateway and making routing decisions accordingly, a decentralized and tamper-proof gateway trust evaluation system is constructed, reducing the risk of transaction failure. After a transaction is completed, bidirectional submission of behavior summaries and the use of a weighted voting mechanism based on behavior scores to drive automatic upgrades of smart contracts enable the continuous evolution and optimization of gateway adaptation rules. The entire solution covers multiple dimensions such as data conversion, routing decisions, behavior evaluation, and contract evolution, forming a complete closed loop for cross-institutional financial service gateway adaptation, providing efficient, reliable, and adaptive technical support for cross-institutional interconnection in the financial industry.

[0051] In one possible implementation of the embodiments of this application, combined with Figure 2 ,like Figure 3 As shown, the above S1 can be implemented through the following S101, S102 and S103, which are explained in detail below: S101. The first gateway extracts the structural features of the data structure to be sent, generates a semantic fingerprint of the data structure, and broadcasts the semantic fingerprint to the second gateway along with the business request.

[0052] When initiating a cross-organizational business request, the first gateway first obtains the business data to be sent and extracts its structural features, including field names, data types, lengths, whether a field is required, and value range constraints. The first gateway combines these structural features into a string according to a preset concatenation order, and then performs a hash operation on this string to obtain a fixed-length hash value. This hash value is the data structure semantic fingerprint. The data structure semantic fingerprint uniquely represents the pattern characteristics of the data structure to be sent, essentially acting as an "identity identifier" for the data structure.

[0053] In some implementations, to reduce redundant computation overhead, the first gateway can pre-cache the semantic fingerprints of various local business data structures. When a certain type of business data needs to be sent, the first gateway first looks up the corresponding semantic fingerprint in the local cache according to the data structure type; if the cache hits, it is directly extracted and used; if not, the above hash operation is performed to generate a new semantic fingerprint and stored in the cache.

[0054] For example, suppose the first gateway needs to send a transfer transaction request. This request data structure contains the following fields: "fromAccount" (20-character string), "toAccount" (20-character string), "amount" (2-decimal decimal place), "currency" (3-character string), and "memo" (100-character string, optional). The first gateway concatenates these fields in a preset order, specifying their names, types, lengths, and constraints, into the string "fromAccountString200true;toAccountString200true;amountDecimal102true;currencyString30true;memoString1000false". Then, it calculates a 256-bit hash value using a secure hash algorithm on this string to obtain the semantic fingerprint of the transfer request data structure. The first gateway then broadcasts this semantic fingerprint, along with the transfer request message, to the second gateway via a peer-to-peer semantic negotiation subnet based on a distributed hash table.

[0055] S102. After receiving the semantic fingerprint, the second gateway uses a graph matching algorithm that combines local sensitive hash pre-screening and subgraph isomorphic matching to match the data structure represented by the semantic fingerprint with the entity nodes in the domain ontology, based on the local domain ontology, and generates a field mapping table.

[0056] Upon receiving the semantic fingerprint and business request from the first gateway, the second gateway initiates the graph matching process. The second gateway locally maintains a domain ontology, which uses a resource description framework triple to describe the organization's internal data model. This ontology includes entity types, entity attributes, and constraints between attributes. Each entity node pre-stores standard semantic tags calculated based on its own data structure.

[0057] The process of obtaining standard semantic tags includes: The second gateway pre-standardizes the data structure corresponding to each entity node in its domain ontology. Specifically, for any entity node in the domain ontology, the second gateway extracts the structural features of all fields in the data structure corresponding to that entity node, including field name, field data type, field length, and constraints. Following a preset concatenation order, the second gateway concatenates the structural features of all fields in the entity node into a single string, then performs a hash operation on this string to obtain a fixed-length hash value corresponding to that entity node. The second gateway uses the calculated hash value as the standard semantic tag for that entity node and associates this standard semantic tag with the entity node, storing it in the domain ontology.

[0058] The second gateway first uses the received semantic fingerprint as a query vector and performs Local Sensitive Hash (LSH) mapping on it and the standard semantic labels of each entity node in the domain ontology. This involves mapping the semantic fingerprint and each standard semantic label to binary hash buckets of the same length, and selecting entity nodes with the same bucket number to form a candidate matching node set. This pre-screening step can quickly narrow down the matching range in a large-scale domain ontology, avoiding the need to compare all nodes one by one.

[0059] In some implementations, the second gateway can pre-calculate the locality-sensitive hash value of the standard semantic tags of each entity node in the domain ontology and build an index. When a query semantic fingerprint is received, it only needs to calculate the locality-sensitive hash value of the fingerprint, and then quickly obtain the candidate matching node set by searching for entity nodes with the same bucket number through the index.

[0060] It should be noted that the Local Sensitive Hash Collision (LSHC) selects entity nodes with the same bucket number as the candidate set. This may introduce a small number of irrelevant candidate nodes due to hash collisions, but these nodes will be excluded in the subsequent subgraph isomorphic matching stage and will not affect the accuracy of the final matching result.

[0061] After obtaining the candidate matching node set, the second gateway selects a node from the candidate set as the current matching starting point. Starting from the root node of the data structure subgraph corresponding to this node, it traverses all field nodes of the requested data structure using a depth-first search strategy. During the traversal, the second gateway uses node type and edge relationships as the first matching constraint, and attribute value range and constraint conditions as the second matching constraint, checking layer by layer whether the currently traversed field node can find a corresponding node in the subgraph of the current candidate node. Specifically, the second gateway first checks whether the field name and data type are consistent, and then checks whether the field length and constraint conditions meet the requirements. If the current node and all its child nodes satisfy all matching constraints, the one-to-one correspondence between the current candidate node and each field in the requested data structure is recorded, forming a field mapping table, and the matching process is terminated. If any field of the current candidate node does not satisfy the matching constraint during the traversal, the candidate node is abandoned, and the next node is selected from the candidate matching node set to repeat the above matching process. If all nodes in the candidate matching node set fail to satisfy all matching constraints, the semantic negotiation is deemed to have failed.

[0062] In some implementations, the methods for constructing the data structure subgraph corresponding to the gateway node include: For each entity node in the domain ontology, the second gateway constructs a data structure subgraph corresponding to that entity node, using the entity node itself as the root node, all attribute fields contained in the entity node as child nodes, and attribute relationships as edges connecting the root node and child nodes. Specifically, the second gateway traverses all resource description framework triples in the domain ontology with the current entity node as the subject. Each triple consists of a subject, a predicate, and an object, where the subject is the current entity node, the predicate represents the attribute type, and the object represents the attribute value or associated field node. For triples where the predicate represents a data type attribute, the second gateway adds the field node corresponding to the object as a direct child node of the current entity node to the subgraph; for triples where the predicate represents an object attribute, the second gateway adds the associated entity node corresponding to the object as an associated child node of the current entity node to the subgraph, and recursively processes the substructures contained in the associated entity node until all reachable attribute relationships have been traversed. The second gateway combines all entity nodes, field nodes, and attribute relationship edges involved in the above process into a data structure subgraph corresponding to the current entity node.

[0063] It should be noted that node type and edge relationships as the first matching constraint means that the field nodes in the requested data structure must find corresponding nodes of the same type in the subgraph of the candidate nodes, and the hierarchical relationship (i.e., edge relationship) between fields must be consistent with the edge relationship in the subgraph. Attribute value range and constraints as the second matching constraint means that, in addition to satisfying the first constraint, it is also necessary to check whether specific constraints such as the field's length range, numerical precision, and whether it is required are matched.

[0064] In some implementations, the second gateway can pre-build and cache the data structure subgraphs corresponding to all entity nodes during system initialization or when the domain ontology is updated. When an entity node is added or modified, the second gateway only rebuilds the subgraphs of the affected entity nodes, while other unaffected subgraphs remain unchanged. Simultaneously, the second gateway can store a summary of the subgraph's information at the root node, including the total number of nodes, maximum depth, and data type distribution of each field node, to facilitate rapid filtering before matching and skip obviously mismatched subgraphs.

[0065] In some implementations, when the gateway checks whether the current field node meets the matching constraints during traversal, the constraints may include data type matching, length range matching, numerical precision matching, whether it is required, and value enumeration matching. Specifically, for any field node in the requested data structure... Let its node to be matched in the candidate subgraph be... Data type matching requirements Types and The type belongs to the set of compatible types, that is, the two types are the same or there are predefined implicit conversion rules; Length range matching requirements Length value satisfy ,in for Maximum allowed length; Numerical precision matching requirements when and When all are numeric types, decimal precision No more than accuracy ,Right now ; Required field matching requirements when When the required attribute is true, The required attribute must be true when When the required attribute is false, The required attribute can be either true or false; Value enumeration matching requirements when The range of values ​​is a finite enumeration set. hour, The range of values ​​must be 0. A subset of.

[0066] If all the above constraints are met, the field node is considered to have matched successfully; if any constraint is not met, the field node is considered to have failed to match.

[0067] S103. The second gateway generates bidirectional conversion functions based on the field mapping table using just-in-time compilation technology, and stores them in memory as temporary data conversion mappings.

[0068] After obtaining the field mapping table, the second gateway needs to generate executable data conversion logic based on the table. Specifically, the second gateway extracts the correspondence between fields in the field mapping table. For each field in the data structure to be sent by the first gateway, it finds the corresponding target field in the internal data structure of the second gateway and generates an assignment code sequence from the source field to the target field. For source and target fields with inconsistent data types, the second gateway inserts a preset type conversion function into the assignment code sequence, such as converting a string value to a decimal value or a date string to a date object. For fields that exist in the request data structure but not in the domain ontology of the second gateway, the second gateway inserts default value filling logic into the assignment code sequence according to the default value filling rules of the corresponding entity node in the domain ontology, such as assigning a default value like an empty string, zero, or the current system time to the missing field.

[0069] In some implementations, the second gateway can have a pre-built type conversion function library covering common data type conversion scenarios, such as conversion between strings and numbers, conversion between different date formats, and conversion between different encodings. When generating the assignment code sequence, the second gateway automatically selects the appropriate conversion function from the function library based on the data types of the source and target fields and inserts it into the code sequence.

[0070] It's important to note that the generation of the field mapping table is based on semantic matching, while the generation of the transformation function is the technical implementation that transforms the semantic mapping into an executable function. The two complement each other: the field mapping table answers the question of "which fields correspond to which fields," while the transformation function solves the problem of "how to transform source data into target data."

[0071] The second gateway compiles the aforementioned assignment code sequence into executable machine code using a just-in-time (JIT) compilation framework, serving as a forward conversion mapping from the data structure to be sent by the first gateway to the internal data structure of the second gateway. Subsequently, the second gateway generates a reverse conversion mapping from the response data structure of the second gateway to the format recognized by the first gateway in the same manner. Finally, the second gateway encapsulates the forward and reverse conversion mappings into a bidirectional conversion function object, storing it in memory as a temporary data conversion mapping.

[0072] For example, the field mapping table shows "fromAccount" corresponding to "FromAccount", "toAccount" corresponding to "ToAccount", "amount" corresponding to "Amount", "currency" corresponding to "Currency", and "memo" corresponding to "Memo". The second gateway generates an assignment code sequence: assigning the value of the "fromAccount" field of the source data to the "FromAccount" field of the target data, assigning the value of the "toAccount" field of the source data to the "ToAccount" field of the target data, converting the value of the "amount" field of the source data to decimal and assigning it to the "Amount" field of the target data, and so on. The second gateway compiles the above assignment code sequence into machine code using a just-in-time compilation framework to obtain the forward conversion mapping. At the same time, the second gateway generates a reverse conversion mapping in the same way as above, which is used to convert the response data of the second gateway into a format that the first gateway can recognize. The second gateway encapsulates the forward and reverse conversion mappings into a bidirectional conversion function object, which is stored in memory as a temporary data conversion mapping for this session, and can be directly called during subsequent data conversions.

[0073] Based on the above technical solutions, in the cross-institutional financial service gateway adaptation method provided in this application embodiment, the first gateway and the second gateway achieve point-to-point dynamic semantic negotiation without relying on any preset unified message standard or centralized mapping table through semantic fingerprint generation and broadcasting, graph matching algorithm based on locality-sensitive hash pre-screening and subgraph isomorphic matching, and just-in-time compilation to generate bidirectional conversion functions. In the above process, locality-sensitive hash pre-screening significantly narrows the matching range and improves matching efficiency; subgraph isomorphic matching uses node type, edge relationship, attribute value range, and constraint conditions as multiple constraints to ensure the accuracy of field mapping; and just-in-time compilation technology directly converts the mapping relationship into executable machine code, avoiding runtime parsing overhead. The synergistic effect of these mechanisms enables adaptive and efficient data format conversion between heterogeneous systems.

[0074] In one possible implementation of the embodiments of this application, combined with Figure 2 ,like Figure 4 As shown, the above S2 can be implemented through the following S201, S202 and S203, which are explained in detail below: S201. The first gateway obtains the business type and amount level of the current transaction, sets the priority preference for reliability or collaboration, and initiates a query request to the behavior proof consortium chain to obtain the historical behavior score of the second gateway.

[0075] Before formally sending a transaction request, the first gateway needs to determine the business attributes of the transaction after completing dynamic semantic negotiation with the second gateway and obtaining a temporary data transformation mapping. Different business types and amount levels have different requirements for gateway service quality: for example, large-amount fund transfers have extremely high requirements for the certainty and correctness of the transaction results, allowing no errors, so the reliability of the gateway should be given priority; while small-amount, high-frequency query transactions are more sensitive to response speed, and the reliability requirements can be appropriately relaxed, prioritizing the gateway's collaborative efficiency. Based on this, the first gateway sets a priority preference for reliability or collaboration according to the business type and amount level of the current transaction. Specifically, the first gateway can pre-configure a mapping table between business types and priority preferences, for example, mapping business types such as "large-amount transfers" and "cross-border payments" to reliability priority, and mapping business types such as "balance inquiry" and "transaction details retrieval" to collaboration priority; for amount levels, an amount threshold can be set, and when the transaction amount exceeds the threshold, the reliability priority is automatically increased.

[0076] In some implementations, the first gateway can maintain a dynamic business classification strategy library, which continuously optimizes classification rules based on historical transaction success rates and business feedback. For example, if a certain type of business has had a high failure rate over a period of time, the system automatically increases the reliability priority of that type of business. Furthermore, the first gateway can also allow users or administrators to manually adjust the priority preferences for specific business types or counterparties through a configuration interface, flexibly adapting to different business scenarios and compliance requirements.

[0077] It's important to note that prioritizing reliability and prioritizing collaboration are not mutually exclusive binary choices, but rather a weighted allocation of preferences across two dimensions. The first gateway can set a preference coefficient, ranging from 0 to 1, to represent the degree of importance placed on reliability, while the degree of importance placed on collaboration is 1 minus this coefficient. A preference coefficient greater than 0.5 indicates a preference for reliability, while a coefficient less than 0.5 indicates a preference for collaboration. The specific value of the preference coefficient can be determined through table lookup or interpolation based on a combination of business type and monetary level.

[0078] After determining the priority preferences, the first gateway initiates a query request to the Proof-of-Behavior Consortium Chain (PoCLC) to obtain the historical behavior scores of the second gateway. The PoCLC is a permissioned blockchain based on a practical Byzantine fault-tolerant consensus protocol, and its nodes are the gateways of participating financial institutions. The data stored on the PoCLC consists of behavioral summaries of each gateway and aggregated statistical values; the PoCLC does not store transaction details or customer privacy information. The query request from the first gateway must include at least the gateway identifier of the second gateway, used to locate and retrieve the historical behavior score data corresponding to that identifier on the consortium blockchain.

[0079] In some implementations, multiple participating financial institutions jointly initiate the formation of a consortium blockchain network as alliance members, specifically including: Each participating institution deploys a gateway node, with each gateway node serving as a consensus node in the consortium blockchain. The consortium blockchain employs a practical Byzantine fault-tolerant consensus protocol as its consensus mechanism, with all consensus nodes jointly participating in the verification and confirmation of blocks. During the initialization phase of the consortium blockchain, participating institutions determine the configuration of the genesis block through multi-party consultation, including the initial node list of the consortium blockchain, the initial public key certificate of each node, the default value of the initial behavior score, the view cycle parameter of the consensus protocol, and the block generation time interval parameter. Each node writes the genesis block configuration to its local database, completing the initialization of the consortium blockchain. When a new financial institution applies to join the consortium blockchain, the institution deploys its gateway node and generates a public-private key pair, submitting its registration application information and public key certificate to the consortium blockchain. The registration application information includes the institution identifier, gateway hardware configuration information, and network bandwidth information. The smart contract deployed on the consortium blockchain automatically reviews registration applications based on node admission criteria. Once approved, the new gateway node is added to the node list and the node change information is broadcast to the entire network. At the same time, an initial behavior score is assigned to the new gateway node.

[0080] S202. The first gateway determines the execution path based on the obtained historical behavior scores, combined with the preset routing policy and priority preferences.

[0081] After obtaining the historical behavior score of the second gateway, the first gateway needs to select a specific execution path based on the score and the preset routing strategy. The historical behavior score includes two dimensions: reliability score and cooperation score. The reliability score is calculated based on the consistency achievement rate and timeout rate in the historical behavior summary of the second gateway, reflecting the second gateway's ability to reliably complete transactions in historical transactions. The cooperation score is calculated based on the semantic negotiation success rate and the average efficiency of the transformation function, reflecting the efficiency of the second gateway in semantic negotiation and data transformation.

[0082] In some implementations, the score can be obtained by weighted summation of weighted coefficients encoded in the smart contract. Let the reliability score be R, the cooperation score be C, the reliability weight coefficient be α, and the cooperation weight coefficient be β. Then the comprehensive score S can be expressed as: S = α × R + β × C, where α + β = 1, and the values ​​of α and β are dynamically determined by the network core rules encoded in the smart contract. The initial values ​​of α and β can be set by the governance rules at network startup, for example, both set to 0.5, indicating that reliability and cooperation are equally important. As the network operates, α and β can be dynamically adjusted through node-submitted modification proposals and weighted voting to adapt to the overall optimization goals of the network at different stages.

[0083] In some implementations, the reliability score is calculated using the following formula: Where R represents the reliability score, Indicates the eventual consensus rate. This indicates the timeout rate.

[0084] Eventual consensus rate The number of historical behavior summaries of the second gateway within the statistical period is determined as follows: Let N be the total number of summaries, of which the number of summaries with the eventual consistency flag set to 1 is... ,but ; Timeout rate The number of historical behavior summaries of the second gateway within the statistical period is determined as follows: Let N be the total number of summaries, of which the number of summaries with a timeout or anomaly flag of 0 is... (i.e., interactions that complete normally without timeout or exceptions) .

[0085] The formula for calculating the collaboration score is: Where C represents the collaboration score, Indicates the success rate of semantic negotiation. This represents the average efficiency of the transformation function. This indicates the maximum allowed conversion time.

[0086] Semantic negotiation success rate The number of semantic negotiations performed by the second gateway within the statistical period is determined as follows: Let M be the total number of negotiations performed by the second gateway within the statistical period, and let M be the number of times the negotiation success flag is 1. ,but ; Average efficiency of transformation function The time consumption field for each transformation is determined as follows: Let K be the number of times the second gateway needs to perform graph matching if it misses the cache within the statistical period, and let K be the corresponding time consumption field for each transformation. ,but When K=0 (i.e., all interactions hit the cache), = 0. This is the preset maximum allowable conversion time, and the specific value is pre-configured by the network core rules encoded in the smart contract.

[0087] After obtaining the reliability score R, cooperation score C, and comprehensive score S of the second gateway, the first gateway makes routing decisions based on the priority preference determined in S201. Specifically, if the priority preference is reliability first, the first gateway focuses on whether the reliability score R is higher than a preset reliability threshold; if R is higher than the threshold, the second gateway is determined to meet the reliability requirements, and a direct connection execution path is selected to send the transaction request directly; if R is lower than the threshold, the second gateway is determined to have insufficient reliability, and a detour path via a third-party gateway is selected, or a pre-verification process is triggered to further verify the current service capabilities of the second gateway. If the priority preference is cooperation first, the first gateway focuses on whether the cooperation score C is higher than a preset cooperation threshold; if C is higher than the threshold, a direct connection execution path is selected; if C is lower than the threshold, a detour path is selected or a pre-verification process is triggered.

[0088] In some implementations, the pre-verification process specifically includes: the first gateway sending a lightweight test message to the second gateway. This test message simulates the format of a real transaction but does not involve actual fund transfers, and is used to verify the second gateway's response capability and processing latency. The first gateway comprehensively judges whether the second gateway is currently in a normal service state based on the second gateway's response time to the test message, the correctness of the response content, and whether it returns any error information. If the test message receives a correct response within a specified time, the first gateway can re-evaluate whether to choose the direct connection path; if the test message times out or returns an error, the first gateway confirms whether to choose a detour path or temporarily abandon the transaction.

[0089] S203. The first gateway sends a transaction request to the second gateway according to the determined execution path and starts timeout monitoring.

[0090] In step S202, after determining the execution path, the first gateway sends a transaction request to the second gateway according to that path. If a direct execution path is selected, the first gateway directly sends the transaction request, after temporary data transformation and mapping, to the second gateway. If a detour path via a third-party gateway is selected, the first gateway first sends the transaction request to the transit gateway, which then forwards it to the second gateway. Simultaneously with sending the transaction request, the first gateway starts a timeout monitoring timer to monitor the total time elapsed from sending the transaction request to receiving a response or an exception return.

[0091] In some implementations, the first gateway can set different timeout thresholds based on different execution paths: the timeout threshold for direct paths can be relatively short because it only involves direct communication between the two gateways; the timeout threshold for detour paths needs to be appropriately extended to cover the forwarding delay of the transit gateway.

[0092] It should be noted that the timeout monitoring starts at the moment the first gateway sends the transaction request and ends at the moment the first gateway receives the response or exception information returned by the second gateway (or relay gateway). The total communication time is the difference between the timestamp of the timeout end and the timeout start. This time will be used as one of the important fields in the behavior summary for subsequent updates to the behavior score of the second gateway.

[0093] Based on the above technical solutions, in the cross-institutional financial service gateway adaptation method provided in this application embodiment, the first gateway dynamically sets reliability or cooperation priority preferences according to the transaction business type and amount level, realizing differentiated routing decisions, so that different needs for gateway service quality under different business scenarios can be met in a targeted manner; by querying the historical behavior score of the second gateway from the behavior proof consortium blockchain, the reliability and cooperation shown by the second gateway in historical interactions are quantified into comparable scores, providing an objective and reliable basis for routing decisions; by comparing the comprehensive score with a preset threshold, and selecting a direct connection path, a detour path, or triggering a pre-verification process according to the comparison result, dynamic adaptive selection of routing paths is realized, effectively avoiding sending transaction requests to gateways with poor service quality and reducing the transaction failure rate. The above mechanisms work together to significantly improve the intelligence and reliability of cross-institutional transaction routing.

[0094] In one possible implementation of the embodiments of this application, combined with Figure 2 ,like Figure 5 As shown, the above S3 can be implemented through the following S301, S302 and S303, which are explained in detail below: S301. After the transaction is completed, both parties record the metadata of this interaction, generate a behavioral digest containing communication quality, negotiation efficiency and eventual consistency results, and digitally sign it using the private key of this gateway.

[0095] Transaction completion refers to the first gateway receiving a transaction response from the second gateway, or the transaction being terminated due to timeout, anomaly, or other reasons. Regardless of the final outcome of the transaction, both parties (i.e., the first and second gateways) need to record complete metadata for this interaction to generate a behavior summary. Metadata is the foundational data source for subsequent behavior scoring calculations, and its completeness and accuracy directly affect the credibility of the behavior score. Specifically, metadata includes total communication time, negotiation success flags, conversion time field, cache hit flags, timeout or anomaly flags, and eventual consistency achievement flags. These metadata elements characterize the communication quality, negotiation efficiency, and eventual consistency result of this interaction from different dimensions.

[0096] Regarding the total communication time: The first gateway takes the time of sending the transaction request as the starting point and the time of receiving the transaction response or abnormal information as the ending point. The difference between the timestamps of the ending point and the starting point is calculated to obtain the total communication time.

[0097] Regarding the negotiation success flag: If the second gateway successfully forms a field mapping table and generates a temporary data conversion mapping during the graph matching process in S1, the negotiation success flag will be marked as 1; if the graph matching algorithm fails to find a complete field mapping relationship within the preset timeout period, resulting in semantic negotiation failure, the negotiation success flag will be marked as 0.

[0098] Regarding the transformation time field: The second gateway starts timing from the moment it receives the semantic fingerprint sequence sent by the first gateway until the moment it generates the temporary data transformation map and stores it in memory. The time interval between these two moments is calculated to obtain the transformation time field. The transformation time field reflects the efficiency of the second gateway in executing the graph matching algorithm and generating the transformation function through just-in-time compilation, and is a core indicator for measuring the efficiency of gateway collaboration. When the current communication directly hits the cached temporary data transformation map, the transformation time field is recorded as 0, indicating that there is no need to re-execute the graph matching and just-in-time compilation processes.

[0099] Regarding the cache hit flag: After receiving the semantic fingerprint sequence, the second gateway first checks its local cache for a temporary data transformation mapping with the combination of both gateway identifiers and the semantic fingerprint as the cache key. If it exists, the cache hit flag is set to 1, and the cached transformation mapping is used directly, skipping the graph matching and just-in-time compilation processes. If it does not exist, the cache hit flag is set to 0, and the complete graph matching process is executed. The cache hit flag reflects the historical interaction frequency of the second gateway and the effectiveness of its caching strategy.

[0100] Regarding timeout or exception flags: The first gateway starts a timeout monitoring timer in S203. If no response is received from the second gateway within the preset timeout threshold, a timeout event is triggered, and the timeout or exception flag is marked as 1. If an exception is thrown during the graph matching algorithm or transaction execution (such as data format verification failure, field mapping conflict, etc.), the timeout or exception flag is also marked as 1. If the transaction is completed normally within the preset timeout threshold and no exception occurs, the timeout or exception flag is marked as 0.

[0101] Regarding the eventual consensus flag: After a transaction is completed, both parties execute their internal accounting operations. Within a preset reconciliation period, the first gateway and the second gateway submit their respective transaction execution results (including transaction status, amount changes, account balances, and other summary information, excluding customer identity and details) to the Behavioral Proof Consortium Chain for comparison and confirmation. If the results submitted by both parties are consistent, the eventual consensus flag is marked as 1 and consensus is recorded; if the results submitted by both parties are inconsistent, the eventual consensus flag is marked as 0 and a consensus conflict is recorded.

[0102] In some implementations, after both parties record metadata, they can assemble all their recorded metadata into structured digest data. The structured digest data can be organized using a lightweight data exchange format, such as representing each field using key-value pairs. Subsequently, both parties use the private key of their respective gateway to digitally sign the structured digest data, generating a behavioral digest. The digital signature can be implemented using an elliptic curve digital signature algorithm or the Chinese national cryptographic algorithm SM2.

[0103] It should be noted that the behavioral summary does not contain customer identity information or transaction amount details, but only metadata information from the gateway interaction process. This design ensures that customer privacy and commercially sensitive information are not leaked due to on-chain data, meeting the compliance requirements of the financial industry. Furthermore, the reconciliation process for the eventual consensus marker only compares the summary hash value of the transaction results, rather than the complete transaction details, further protecting transaction privacy.

[0104] S302. Both parties submit the digitally signed behavior digest to the behavior proof consortium blockchain storage, and the behavior proof consortium blockchain updates the historical behavior score of the second gateway.

[0105] In this process, both participating parties submit the behavioral digests generated in S301 to the Behavioral Proof Consortium Chain. Upon receiving the behavioral digest, the consensus nodes of the Behavioral Proof Consortium Chain first verify the validity of the digital signature attached to the digest to confirm its source and integrity. After successful verification, the behavioral digest is stored in a block of the consortium chain. During storage, the Behavioral Proof Consortium Chain does not store transaction details or customer privacy information; it only stores behavioral metadata related to gateway interactions, including fields such as total communication time, negotiation success flag, conversion time, cache hit flag, timeout or exception flag, and eventual consensus achievement flag.

[0106] In some implementations, the submission of behavior digests to the behavior proof consortium blockchain employs an asynchronous batch on-chain mechanism to balance real-time performance with on-chain storage overhead. Specifically, gateway nodes cache multiple behavior digests locally within a preset number (e.g., 100) or a preset time window (e.g., 30 seconds). When the number of cached behavior digests reaches the preset threshold or the caching time reaches the preset time window threshold, the gateway node performs aggregation processing on the batch of multiple behavior digests: organizing the multiple behavior digests into a Merkle tree data structure, calculating the root hash value of the Merkle tree, and simultaneously calculating the aggregated statistics of the batch of behavior digests (e.g., the total number of transactions, the number of successful transactions, the average time taken, etc.).

[0107] The gateway node then submits the Merkle root hash and aggregated statistics as a transaction to the blockchain. The consensus nodes of the behavior proof consortium blockchain verify the signature and store the Merkle root hash and aggregated statistics in a block. The original details of each behavior digest are stored in off-chain index storage for verification during queries. When it is necessary to verify the existence of a specific behavior digest, it can be quickly verified using the Merkle root hash of the batch containing the digest and the path proof of the digest in the Merkle tree. This eliminates the need to upload all detailed data to the blockchain, ensuring data verifiability while significantly reducing on-chain storage space usage.

[0108] It should be noted that in the asynchronous batch on-chain mechanism, the specific values ​​of the preset quantity and preset time window can be dynamically configured according to the actual transaction frequency and storage capacity of the network. As an example rather than a limitation, for network environments with high transaction frequency, the preset quantity can be configured to a value between 100 and 500, and the preset time window can be configured to a value between 10 and 30 seconds, in order to reduce the on-chain frequency and on-chain storage overhead; for network environments with low transaction frequency, the preset quantity can be configured to a value between 20 and 50, and the preset time window can be configured to a value between 60 and 120 seconds, in order to avoid the behavior summary being cached locally for a long time and delaying the on-chain, thus affecting the real-time performance of the scoring.

[0109] After the behavior summary is stored on the blockchain, the behavior proof consortium blockchain triggers a score update process to update the historical behavior score of the second gateway.

[0110] In some implementations, digests with an eventual consistency flag of 0 are not included in the denominator of the semantic negotiation success rate to exclude the interference of invalid interactions caused by consistency conflicts on the negotiation success rate statistics. Meanwhile, interactions with a cache hit flag of 1 are not included in the calculation of the average efficiency of the transformation function because a cache hit does not require graph matching and just-in-time compilation, and the corresponding transformation time is 0. Including them in the average efficiency would introduce bias and fail to accurately reflect the actual performance of the second gateway in graph matching and just-in-time compilation.

[0111] It should be noted that reliability and cooperation scores can be calculated using a sliding time window, which only considers behavioral summaries within a recent period, such as the last 30 days or the last 1000 transactions. The sliding time window allows the scoring to more sensitively reflect recent changes in the gateway's service quality. When new behavioral summaries are added to the blockchain, older summaries outside the time window are automatically excluded from the statistics.

[0112] S303. Smart contracts deployed on the behavior proof consortium blockchain automatically execute network governance rules based on updated behavior scores, including dynamically adjusting score weight parameters and negotiation timeout thresholds, and upgrading contracts in response to modification proposals submitted by nodes.

[0113] The behavior proof consortium blockchain deploys a smart contract that encodes the network's core governance rules. After the score update is completed in S302, the smart contract automatically checks if any governance rules need to be triggered.

[0114] Specifically, the smart contract encodes the weighting coefficients α and β corresponding to the reliability score and the cooperation score, the negotiation timeout threshold for the graph matching algorithm, the preset proportion threshold required for weighted voting to pass, and the judgment conditions and execution logic for triggering penalty measures when a node's behavior score is continuously below the minimum threshold. When the behavior score of the second gateway is updated, if the score is lower than the preset minimum threshold, the smart contract automatically executes the penalty measures: reducing the priority of the second gateway in routing selection to the lowest level, or suspending the second gateway's eligibility to participate in semantic negotiation until its behavior score returns to a normal level.

[0115] In some implementations, the core network rules supported by smart contracts also include node admission criteria. When a new gateway node joins the network, it needs to submit a registration application to the Proof-of-Behavior Consortium Chain. The smart contract automatically reviews the application based on the node admission criteria, which include the minimum hardware configuration requirements, minimum network bandwidth requirements, and the rules for assigning initial behavior scores to new gateway node registrations. After approval, the new gateway node obtains the access information for the lightweight client and semantic negotiation subnet of the Proof-of-Behavior Consortium Chain, initializes its local domain ontology, and begins participating in network interactions with its initial behavior score.

[0116] Furthermore, smart contracts support nodes submitting correction proposals and driving automatic contract upgrades through weighted voting based on behavioral scores. When any gateway node detects that the current network operating metrics deviate from a preset range, it can determine the type and magnitude of the rule parameters to be adjusted based on the difference between the network operating metrics and the preset target value. It then encapsulates the type of rule parameters to be adjusted, the adjustment magnitude, and the current value into a key-value pair format correction proposal and submits it to the behavioral proof consortium blockchain. When any gateway node writes new functional logic based on business development needs or security upgrade requirements, it compiles the new functional logic into smart contract bytecode, encapsulates it as a new logic code segment into a correction proposal, and submits it to the behavioral proof consortium blockchain. Network operating metrics include the average latency of all network transactions, the average time for semantic negotiation, the variance of node behavioral score distribution, and the consensus confirmation latency.

[0117] In some implementations, after a proposed amendment is submitted, it enters a public comment period, during which nodes can express their opinions through on-chain commenting. After the public comment period ends, a voting period begins. Each node's voting weight is the normalized value of its current behavior score, i.e., the proportion of that node's behavior score to the sum of the behavior scores of all nodes in the network. When the total weight of the affirmative votes reaches a preset threshold, the smart contract automatically executes an upgrade, writing the rule parameters to be modified into the contract's configuration storage area or writing the new logic code segment into the contract's method storage area, and the new rule takes effect immediately.

[0118] It should be noted that the severity of the penalty can be positively correlated with the degree to which the behavior score deviates from the minimum threshold: the greater the deviation, the greater the reduction in priority or the longer the suspension period. Simultaneously, to give poorly performing gateways a chance to recover, the smart contract can set a recovery mechanism: when the behavior score of a penalized node continuously improves in subsequent interactions and stabilizes above the minimum threshold, the penalty is automatically lifted and its routing priority is gradually restored. Furthermore, the duration of the public consultation period and voting period can be tiered according to the importance of the proposal, with more important proposals having longer public consultation periods to allow for sufficient discussion.

[0119] For example, the smart contract detects that the updated comprehensive score of the second gateway is 0.9109, which is higher than the minimum threshold of 0.60, so no penalty measures are required. At this time, another gateway node detects that the average transaction latency across the entire network is 1.8 seconds, exceeding the preset target value of 1.2 seconds. Through analysis, it is found that the increase in latency is related to the negotiation timeout threshold being set too short. Based on the difference between the current latency and the target latency, this node determines that the negotiation timeout threshold needs to be adjusted from the current 5 seconds to 8 seconds, and encapsulates the adjustment plan as a key-value pair format modification proposal and submits it to the behavior proof consortium blockchain. The modification proposal enters a public comment period of 3 days, during which each node can express its opinions through the on-chain comment function. After the public comment period ends, a voting period begins, which lasts for 5 days. The voting weight of each node is the normalized value of its behavior score. Ultimately, the total weight of the affirmative votes across the entire network reaches 75%, exceeding the preset passing threshold of 70%. The smart contract automatically executes the upgrade, updating the negotiation timeout threshold from 5 seconds to 8 seconds. The new rule takes effect immediately, and the average transaction latency across the entire network gradually decreases to the target range in subsequent operation.

[0120] Based on the above technical solutions, in the cross-institutional financial service gateway adaptation method provided in this application embodiment, the participating parties assemble multi-dimensional metadata such as total communication time, negotiation success flag, conversion time field, cache hit flag, timeout or exception flag, and eventual consensus achievement flag into a behavior summary and store it on the chain. This achieves a comprehensive and traceable quantitative evaluation of the gateway service quality, providing an objective data foundation for subsequent routing decisions. By adopting an asynchronous batch on-chain mechanism and Merkle tree aggregation storage, the on-chain storage overhead is significantly reduced while ensuring data verifiability, thus improving the system's scalability. By encoding the core network governance rules through smart contracts and automatically executing score updates, penalty measures, and node admission audits, the governance rules are codified and automatically executed, avoiding the inefficiency and subjectivity caused by manual intervention. By supporting nodes to dynamically generate modification proposals based on network operation indicators and automatically complete contract upgrades after public announcement and weighted voting based on behavior scores, the distributed adaptive adjustment of network governance rules is achieved, enabling key configurations such as score weight parameters and negotiation timeout thresholds to evolve smoothly with business development and network status changes. The above mechanisms work together to build a complete closed-loop feedback system: behavior drives scoring, scoring drives routing, routing affects behavior, behavior updates scoring on the blockchain, and smart contracts continuously optimize network governance parameters based on this, driving the entire gateway network to evolve in a more efficient and trustworthy direction.

[0121] Although this application has been described herein in conjunction with various embodiments, those skilled in the art, by reviewing the accompanying drawings, disclosure, and appended claims, will understand and implement other variations of the disclosed embodiments in carrying out the claimed application. In the claims, the word "comprising" does not exclude other components or steps, and "a" or "an" does not exclude multiple instances. A single processor or other unit can implement several functions listed in the claims. While different dependent claims may recite certain measures, this does not mean that these measures cannot be combined to produce good results.

[0122] Although this application has been described in conjunction with specific features and embodiments, it is obvious that various modifications and combinations can be made thereto without departing from the spirit and scope of this application. Accordingly, this specification and drawings are merely illustrative descriptions of the application as defined by the appended claims, and are considered to cover any and all modifications, variations, combinations, or equivalents within the scope of this application. Clearly, those skilled in the art can make various alterations and modifications to this application without departing from the spirit and scope of this application. Thus, if such modifications and variations of this application fall within the scope of the claims of this application and their equivalents, this application is also intended to include such modifications and variations.

Claims

1. A method for adapting a cross-institutional financial service gateway, characterized in that, include: The first gateway and the second gateway each generate a temporary data conversion mapping for the current session based on their locally maintained domain ontology and data structure semantic fingerprints, and complete the format conversion of business data through graph matching algorithms. Before the transaction is executed, the first gateway queries the behavior proof consortium blockchain for the historical behavior score of the second gateway, and selects the execution path based on the score and the preset routing strategy; After the transaction is completed, both parties will digitally sign the behavior digest containing communication quality, negotiation efficiency and eventual consistency results and submit it to the behavior proof consortium blockchain storage to update the behavior score of the second gateway and complete the gateway adaptation; The behavior proof consortium blockchain is equipped with smart contracts that allow nodes to submit correction proposals and drive automatic contract upgrades through weighted voting based on behavior scores, dynamically adjusting the weight parameters of the scores and the negotiation timeout threshold.

2. The cross-institutional financial service gateway adaptation method according to claim 1, characterized in that, The domain ontology uses RDF triples to describe the organization's internal data model, including entity type, entity attributes, and constraints between attributes. Each entity node has a pre-stored standard semantic label calculated based on its own data structure. The semantic fingerprint of the data structure is a hash value calculated by concatenating the field names, types, lengths, and constraints of the data structure in sequence.

3. The cross-institutional financial service gateway adaptation method according to claim 1, characterized in that, The graph matching algorithm is a subgraph isomorphic matching algorithm based on locality-sensitive hash pre-screening. It enables the first gateway and the second gateway to perform point-to-point semantic negotiation through broadcast semantic fingerprint and locality-sensitive hash collision, thereby generating the temporary data transformation mapping. The specific workflow includes: Step 1: The first gateway extracts the field types, field lengths, and constraint relationships of the data structure to be sent, generates a semantic fingerprint sequence representing the data structure to be sent through hash operation, and broadcasts the semantic fingerprint sequence to the second gateway along with the service request; Step 2: The second gateway uses the received semantic fingerprint sequence as a query vector and performs local sensitive hash mapping with the standard semantic tags of each entity node in the domain ontology. The semantic fingerprint sequence and each standard semantic tag are mapped to binary hash buckets of the same length, and entity nodes with the same bucket number are selected to form a candidate matching node set. Step 3: Select a node from the candidate matching node set as the current matching starting point. Starting from the root node of the data structure subgraph corresponding to the current matching node, use a depth-first search strategy to traverse all field nodes of the request data structure. During the traversal, use node type and edge relationship as the first matching constraint and attribute value range and constraint conditions as the second matching constraint. Check layer by layer whether the field node currently traversed can find the corresponding node in the subgraph. Step 4: If the current node and all its child nodes satisfy all matching constraints, record the one-to-one correspondence between the current candidate node and each field in the request data structure to form a field mapping table. Based on the correspondence, generate a forward conversion mapping from the data structure to be sent by the first gateway to the internal data structure of the second gateway, and a reverse conversion mapping from the response data structure of the second gateway to the recognition format of the first gateway. Combine the forward conversion mapping and the reverse conversion mapping into the temporary data conversion mapping, and terminate the matching process. Step 5: If any field of the current candidate node does not meet the matching constraint during the traversal, then abandon the current candidate node and select the next node from the set of candidate matching nodes to repeat step 3. Step 6: If none of the nodes in the candidate matching node set can satisfy all matching constraints, then the semantic negotiation is deemed to have failed.

4. The cross-institutional financial service gateway adaptation method according to claim 3, characterized in that, The specific generation process of the temporary data transformation mapping includes: Extract the field correspondence in the field mapping table. For each field in the data structure to be sent in the first gateway, find the target field in the internal data structure of the second gateway and generate an assignment code sequence from the source field to the target field. For source and target fields with inconsistent data types, a preset type conversion function is inserted into the assignment code sequence; For fields that exist in the request data structure but not in the second gateway domain ontology, default value filling logic is inserted into the assignment code sequence according to the default value filling rules of the corresponding entity node in the second gateway domain ontology. The assignment code sequence is compiled into executable machine code using a just-in-time (JIT) compilation framework, and used as the forward conversion mapping; For each field in the second gateway response data structure, find its corresponding target field in the first gateway identification format, and generate an assignment code sequence from the source field of the second gateway response data structure to the target field of the first gateway identification format; For source and target fields with inconsistent data types, a preset type conversion function is inserted into the assignment code sequence; For fields that exist in the second gateway response data structure but not in the first gateway identification format, default value filling logic is inserted into the assignment code sequence according to the default value filling rule or the field is ignored. The assignment code sequence is compiled into executable machine code using a just-in-time (JIT) compilation framework, and used as the reverse conversion mapping. The forward transformation map and the reverse transformation map are encapsulated into a bidirectional transformation function object, which is stored in memory as the temporary data transformation map.

5. The cross-institutional financial service gateway adaptation method according to claim 1, characterized in that, The Proof-of-Behavior consortium blockchain is a permissioned blockchain based on a practical Byzantine fault-tolerant consensus protocol. The nodes of the Proof-of-Behavior consortium blockchain are gateways participating in the financial structure. The data stored on the Proof-of-Behavior consortium blockchain consists of behavioral summaries of each gateway and aggregated statistical values.

6. The cross-institutional financial service gateway adaptation method according to claim 1, characterized in that, The step of selecting the execution path based on the score and the preset routing strategy specifically includes: The first gateway sets a priority preference for reliability or cooperation based on the business type and amount level of the current transaction; After querying the historical behavior score of the second gateway, if the historical behavior score is higher than the set threshold, the direct connection execution path is selected to send the transaction request directly. If the historical behavior score is lower than the set threshold, a path through a third-party gateway is selected, or a pre-verification process is triggered; the pre-verification process includes sending a test message to the second gateway to verify the response capability.

7. The cross-institutional financial service gateway adaptation method according to claim 3, characterized in that, The process of obtaining the behavioral summary specifically includes: After the transaction is completed, both parties record the metadata of this interaction; the metadata includes the total communication time, negotiation success flag, conversion time field, cache hit flag, timeout or exception flag, and eventual consistency achievement flag, among which, The total communication time is obtained by the difference between the timestamps of the transaction initiation time and the transaction completion time; The successful negotiation flag is obtained by recording whether the graph matching algorithm successfully formed the field mapping table; if yes, it is marked as 1; if no, it is marked as 0. The conversion time field is obtained by recording the time interval between the second gateway receiving the semantic fingerprint sequence and generating a temporary data conversion mapping. The cache hit flag is obtained by recording whether the current communication directly hits the cache through a temporary data conversion mapping. If the cache is hit, it is marked as 1; otherwise, it is marked as 0. The timeout or exception flag is obtained by recording whether a preset timeout threshold is triggered or an exception is thrown during the graph matching algorithm or transaction execution. If a timeout or exception is triggered, it is marked as 1; otherwise, it is marked as 0. Both parties assemble all their recorded metadata into a structured digest database, and the private key of this gateway digitally signs the structured digest data to generate the behavior digest.

8. The cross-institutional financial service gateway adaptation method according to claim 7, characterized in that, The historical behavior score includes a reliability score and a cooperative score; The reliability score is calculated based on the consistency achievement rate and timeout rate in the historical behavior summary of the second gateway, and the cooperation score is calculated based on the semantic negotiation success rate and the average efficiency of the transformation function; the semantic negotiation success rate is the proportion of the number of times the second gateway successfully negotiated in historical interactions to the total number of negotiations, which is obtained by statistically analyzing the negotiation success flags in the behavior summary stored on the blockchain. The average efficiency of the conversion function is the arithmetic mean of the time required for each temporary data conversion mapping generated in the history of the second gateway from matching to generation, which is calculated by extracting the conversion time field in the behavior summary; The score is calculated by weighted summation of weight coefficients encoded in the smart contract and is updated in real time with each new behavior summary uploaded to the blockchain.

9. The cross-institutional financial service gateway adaptation method according to claim 1, characterized in that, The proposed amendments contain rule parameters to be modified or new logic code segments. The acquisition process includes: When any gateway node detects that the current network operation index deviates from the preset range, it determines the type and adjustment range of the rule parameter to be adjusted based on the difference between the network operation index and the preset target value, and encapsulates the type, adjustment range and current value of the rule parameter to be adjusted as a key-value pair format correction proposal and submits it to the behavior proof consortium chain. When any gateway node writes new functional logic based on business development needs or security upgrade needs, the new functional logic is compiled into smart contract bytecode, and encapsulated as a new logic code segment as a correction proposal and submitted to the behavior proof consortium chain. The network operation metrics include the average latency of transactions across the entire network, the average time for semantic negotiation, the variance of node behavior score distribution, and the consensus confirmation latency.

10. A cross-institutional financial service gateway adaptation system, characterized in that, include: The module consists of a semantic negotiation module, a routing decision module, and a behavior management module; among which, The semantic negotiation module is configured in the first gateway and the second gateway, and is used to enable the first gateway and the second gateway to generate a temporary data conversion mapping for the current session based on the domain ontology and data structure semantic fingerprint maintained locally, and to complete the format conversion of business data. The routing decision module is configured in the first gateway and is used to query the historical behavior score of the second gateway in the forward behavior proof consortium chain before transaction execution, and select the execution path according to the score and the preset routing strategy. The behavior management module is configured in the first gateway and the second gateway. After the transaction is completed, it submits the behavior digest containing communication quality, negotiation efficiency and eventual consistency result to the behavior proof consortium chain storage after digital signature, updates the behavior score of the second gateway, and completes the gateway adaptation. The behavior proof consortium blockchain is equipped with smart contracts that allow nodes to submit correction proposals and drive automatic contract upgrades through weighted voting based on behavior scores, dynamically adjusting the weight parameters of the scores and the negotiation timeout threshold.

Images