Foreign exchange transaction risk data processing method and system

Abstract

The application provides a foreign exchange transaction risk data processing method and system. The method splits the risk assessment result corresponding to the foreign exchange transaction data into at least two of the privacy risk information, the audit key information and the statistical public information, generates a commitment value for the privacy risk information and the audit key information respectively to obtain a privacy commitment value and an audit commitment value, then generates an anonymous transaction index based on the foreign exchange transaction data and constructs an on-chain risk evidence record, writes the on-chain risk evidence record into a blockchain ledger, and stores the privacy risk information, the audit key information, a random factor and a plaintext risk record corresponding to an off-chain storage pointer in an off-chain risk database, so that the on-chain record can provide sufficient and verifiable risk evidence for authorized audit subjects, and the visibility of the risk status of specific customers and single transactions between nodes is minimized.

Description

Technical Field

[0001] This application relates to data processing technology, and more particularly to a method and system for processing foreign exchange transaction risk data. Background Technology

[0002] Existing foreign exchange trading risk management systems typically rely on centralized databases to collect, process, and store trading data. Through preset statistical analysis rules, quantitative models, and risk control strategies, they conduct risk assessments on individual transactions and trading portfolios, and output results such as comprehensive risk assessment values, risk levels, and risk types.

[0003] In some improved solutions, such as in the invention application with publication number CN121169569A, in order to solve the problem of ensuring the authenticity and integrity of risk data, foreign exchange transactions and their risk assessment results are recorded in a consortium blockchain or private blockchain. Through consensus mechanisms and on-chain evidence storage, the risk assessment process and results are recorded for subsequent auditing and accountability.

[0004] However, in the above schemes, the on-chain data structure is often stored in plaintext or simple anonymized form as transaction identifiers, customer identifiers (or account identifiers that can be used to infer customers), timestamps, and risk assessment results. When synchronizing the ledger, participating institutional nodes can usually directly access or easily restore the risk status of specific customers. Summary of the Invention

[0005] This application provides a method and system for processing foreign exchange transaction risk data, which enables on-chain records to provide authorized audit entities with sufficient and verifiable risk evidence while minimizing the visibility between nodes to the risk status of specific clients and individual transactions.

[0006] Firstly, this application provides a method for processing foreign exchange transaction risk data, including: The risk assessment results corresponding to foreign exchange transaction data are broken down into at least two of the following: privacy risk information, key audit information, and publicly available statistical information. A commitment value is generated for the privacy risk information and the audit key information respectively, resulting in a privacy commitment value and an audit commitment value; An anonymous trading index is generated based on the aforementioned foreign exchange trading data and a preset random factor. Construct an on-chain risk evidence record, which includes at least the anonymous transaction index, the statistical public information, the privacy commitment value, the audit commitment value, and the off-chain storage pointer; The on-chain risk evidence record is written into the blockchain ledger to provide tamper-proof evidence of the risk assessment results of the foreign exchange transaction. The privacy risk information, the key audit information, the random factor, and the plaintext risk record corresponding to the off-chain storage pointer are stored in the off-chain risk database.

[0007] Secondly, this application provides a foreign exchange transaction risk data processing system, comprising: The splitting module is used to split the risk assessment results corresponding to foreign exchange transaction data into at least two of the following: privacy risk information, key audit information, and publicly available statistical information. The generation module is used to generate commitment values ​​for the privacy risk information and the audit key information respectively, so as to obtain the privacy commitment value and the audit commitment value; The index module is used to generate an anonymous transaction index based on the foreign exchange transaction data and a preset random factor; The construction module is used to construct on-chain risk evidence storage records, which include at least the anonymous transaction index, the statistical public information, the privacy commitment value, the audit commitment value, and the off-chain storage pointer; The evidence storage module is used to write the on-chain risk evidence storage records into the blockchain ledger to provide tamper-proof evidence of the risk assessment results of the foreign exchange transaction. The storage module is used to store the privacy risk information, the audit key information, the random factor, and the plaintext risk record corresponding to the off-chain storage pointer in the off-chain risk database.

[0008] Thirdly, this application provides an electronic device, comprising: Processor; and, Memory for storing the executable instructions of the processor; The processor is configured to perform any of the possible methods described in the first aspect by executing the executable instructions.

[0009] Fourthly, this application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement any of the possible methods described in the first aspect.

[0010] The foreign exchange transaction risk data processing method and system provided in this application splits the risk assessment results corresponding to foreign exchange transaction data into at least two of the following: privacy risk information, audit key information, and statistical public information. It then generates commitment values ​​for the privacy risk information and audit key information, resulting in privacy commitment values ​​and audit commitment values. Next, based on the foreign exchange transaction data and a preset random factor, it generates an anonymous transaction index and constructs an on-chain risk evidence record. This on-chain risk evidence record is then written into the blockchain ledger to provide immutable evidence of the foreign exchange transaction risk assessment results. Furthermore, it stores the privacy risk information, audit key information, random factor, and plaintext risk records corresponding to off-chain storage pointers in an off-chain risk database. This allows the on-chain records to provide authorized audit entities with sufficient and verifiable risk evidence while minimizing the visibility between nodes to the risk status of specific clients and individual transactions, thus achieving a controllable technical balance between privacy protection and audit verifiability. Attached Figure Description

[0011] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0012] Figure 1 This is a flowchart illustrating a foreign exchange transaction risk data processing method according to an example embodiment of this application; Figure 2 This is a flowchart illustrating a specific implementation of S150 according to an example embodiment of this application; Figure 3 This is a flowchart illustrating a specific implementation of S150 according to another example embodiment of this application; Figure 4 This is a flowchart illustrating a specific implementation of S150 according to another example embodiment of this application; Figure 5 This is a flowchart illustrating a foreign exchange transaction risk data processing method according to another example embodiment of this application; Figure 6 This is a flowchart illustrating a foreign exchange transaction risk data processing method according to yet another example embodiment of this application; Figure 7 This is a flowchart illustrating a foreign exchange transaction risk data processing method according to yet another example embodiment of this application; Figure 8 This is a flowchart illustrating a foreign exchange transaction risk data processing system according to an example embodiment of this application; Figure 9 This is a schematic diagram of the structure of an electronic device according to an example embodiment of this application.

[0013] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0014] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0015] First, in a consortium blockchain architecture, participating institutional nodes typically hold complete or most of the synchronized ledger. Once records containing transaction identifiers, customer identifiers, and plaintext risk results are directly uploaded to the blockchain, the exposure of sensitive information will be amplified across multiple institutions and nodes. Compared to traditional single-institution databases, the attack surface and potential sources of leakage will increase significantly.

[0016] Secondly, the immutability and long-term storage characteristics of blockchain mean that once a risk label with poor early design is written onto the chain, even if the strategy or access control is adjusted later, the historical data can still be traced back and analyzed, creating a long-term privacy burden.

[0017] Furthermore, while existing simple hash-based evidence storage schemes can verify whether a specific record has been tampered with, auditors often struggle to independently verify risk outcomes without complete access to the off-chain plaintext, hindering collaborative auditing by multiple institutions and comprehensive oversight. Conversely, granting audit nodes broad database access or decryption privileges for audit convenience undermines the principle of least privilege, raising new compliance and security issues.

[0018] Furthermore, in practical applications, transaction identifiers or customer identifiers are often associated with internal mapping tables, logs, access records, etc. Even if the identifiers are formally anonymized, they can still be easily restored or real customers can be re-identified through association analysis if reinforcement measures such as multi-party random factors and one-way hashing are lacking.

[0019] These underlying technological constraints collectively mean that solutions relying solely on plaintext on-chain data, simple encryption, or hash-based evidence storage are insufficient to simultaneously meet the complex requirements of privacy protection, immutability, and auditability in a multi-institutional environment.

[0020] In response, Figure 1 This is a flowchart illustrating a foreign exchange transaction risk data processing method according to an example embodiment of this application. Figure 1As shown, the method provided in this embodiment includes: S110. Obtain foreign exchange trading data and the corresponding customer identifier, account identifier, and time-series market data.

[0021] Specifically, the foreign exchange trading front-end access module can collect original trading messages from the trading front-end system, trading matching system, or trading terminal, perform protocol parsing on the original trading messages, and extract one or more of the following: transaction time, trading direction, trading currency pair, transaction price, transaction quantity, trading channel identifier, and transaction serial number, in order to generate foreign exchange trading data.

[0022] Then, based on the customer number field and account number field in the original transaction message, the pre-configured customer account mapping table is queried to obtain the customer identifier and account identifier corresponding to the foreign exchange transaction data.

[0023] Then, based on the transaction time, currency pair, and transaction channel identifier in the foreign exchange transaction data, a market data subscription or market query request is sent to the market data service module to obtain multi-point historical market data covering a preset time window before and after the target transaction time from the preset market data source.

[0024] Next, time alignment and missing value filling are performed on the multi-point historical market data. The processed historical market data is then constructed into time series market data, and the time series market data information is associated with the corresponding forex trading data, customer identifiers, and account identifiers.

[0025] S120. Input the foreign exchange trading data and time series market data into the risk assessment module to obtain the risk assessment results for the target foreign exchange trading.

[0026] Specifically, this can involve extracting features from foreign exchange trading data to obtain a basic risk feature vector that includes at least one or more of the following: transaction price deviation, transaction time volatility, leverage ratio, position concentration, and trading frequency.

[0027] Based on time-series market data, determine one or more of the following within a preset time window before and after the target forex transaction: price fluctuation range, extreme point return, annualized volatility of the range, and short-term trend slope, and generate a market risk feature vector.

[0028] The basic risk feature vector is then concatenated with the market risk feature vector to obtain the joint risk feature input data for the target forex trade. This joint risk feature input data is then fed into a pre-trained risk assessment model to obtain the corresponding comprehensive risk assessment value. Finally, based on the comprehensive risk assessment value and preset risk segmentation rules, the target forex trade is classified into the corresponding risk level range to determine its risk level.

[0029] Finally, based on the risk characteristics in the basic risk feature vector and the market risk feature vector that contribute more than a preset threshold to the comprehensive risk assessment value, the target forex transaction is classified into at least one risk type to determine the risk type, thereby constituting the risk assessment result. The risk assessment result includes at least the comprehensive risk assessment value, risk level, and risk type.

[0030] It is worth noting that the risk assessment model mentioned above can be any risk assessment model in the prior art. In this embodiment, there is no need to specifically limit its type, as long as it can output the corresponding risk assessment results.

[0031] S130. The risk assessment results shall be broken down into at least two of the following: privacy risk information, audit key information, and publicly available statistical information.

[0032] Specifically, fields containing customer identifiers, account identifiers, specific risk types, and specific risk scores can be categorized as privacy risk information. Model version identifiers, risk score ranges, partial anonymization factors, and assessment timestamps used to verify the correctness of the risk assessment process can be categorized as key audit information. Risk levels or discretized risk level ranges used for public display on the blockchain can be categorized as publicly available statistical information.

[0033] S140. Generate commitment values ​​for privacy risk information and audit key information respectively, and obtain privacy commitment value and audit commitment value.

[0034] In this step, the privacy risk information can be serialized to obtain a first byte sequence. An irreversible hash operation is then performed on the first byte sequence based on a first random parameter to obtain a privacy commitment value. Similarly, the audit key information can be serialized to obtain a second byte sequence. An irreversible hash operation is then performed on the second byte sequence based on a second random parameter to obtain an audit commitment value. The first and second random parameters, along with the privacy risk information and the audit key information, are stored together in an off-chain risk database.

[0035] Optionally, the method for determining the privacy commitment value can be as follows: First, the customer identifier, account identifier, specific risk type, and specific risk score in the privacy risk information are standardized according to a preset field order. The standardization process includes at least uniform character encoding for character fields and decimal alignment and zero padding for numeric fields. The standardized fields are then concatenated according to the preset field order to obtain a first structured data object. This first structured data object is then encoded using a preset encoding rule to generate a first byte sequence. Next, a first random parameter generated by a secure random number generator is generated or obtained. This first random parameter is then concatenated or combined with the first byte sequence to obtain first commitment input data. Finally, a preset one-way hash algorithm is applied to the first commitment input data to generate the privacy commitment value. This one-way hash algorithm includes one or more of the SHA-256, SHA-3, or BLAKE2 algorithms.

[0036] Optionally, the method for determining the audit commitment value can be as follows: First, the model version identifier, risk scoring range, some anonymization factors, and assessment timestamps in the key audit information are standardized according to a preset audit field order. The standardization process includes at least converting the time field to a uniform time format and aligning and padding the identifier fields. The standardized audit fields are then concatenated according to the preset audit field order to obtain a second structured data object. This second structured data object is encoded using the same or compatible encoding rules as the privacy risk information to generate a second byte sequence. Then, a second random parameter generated by a secure random number generator is generated or obtained. This second random parameter is concatenated or combined with the second byte sequence to obtain the second commitment input data. The second commitment input data is then processed using a one-way hash algorithm that is the same as or different from the privacy commitment value to generate the audit commitment value.

[0037] Finally, a unique risk record identifier is assigned to each foreign exchange transaction risk assessment record, and the privacy risk information, key audit information, first random parameter, and second random parameter associated with the risk record identifier are stored in the corresponding data table in the off-chain risk database.

[0038] When verification of the commitment value is required, the corresponding privacy risk information, audit key information, and first and second random parameters are read from the off-chain risk database based on the risk record identifier. The first and second commitment input data are reconstructed, and the privacy commitment value and audit commitment value are recalculated for comparison with the privacy commitment value and audit commitment value in the blockchain ledger.

[0039] It is worth noting that in practical applications, because key audit information, such as risk scoring ranges, risk levels, model versions, and assessment timestamps, is packaged together to generate a single commitment value or summary, when subsequent regulatory agencies or internal auditors wish to selectively verify only certain fields—for example, only checking the consistency between the model version and the risk level—without disclosing the entire scoring range or all audit details, it is impossible to achieve fine-grained field-level verification without exposing the complete audit plaintext. This results in either excessive disclosure of information, increasing the risk of sensitive information exposure, or the ability to perform coarse-grained verification of overall pass or overall fail. This easily leads to insufficient audit flexibility and privacy protection capabilities.

[0040] To address this, this step can further break down the key audit information into multiple audit fields. These audit fields should include at least one or more of the following: a risk scoring range field, a risk level field, a model version field, and an evaluation timestamp field. Then, commitment calculations are performed on each audit field to obtain a corresponding multi-dimensional commitment vector. Finally, each commitment field in the multi-dimensional commitment vector is written into the on-chain risk notarization record. During the audit, only a subset of the commitment fields in the multi-dimensional commitment vector can be verified based on the audit scope specified in the audit request.

[0041] In the above further scheme, firstly, the key audit information is split according to the preset audit field granularity. One or more of the risk scoring range field, risk level field, model version field, and assessment timestamp field are taken as independent audit fields. Each audit field is serialized and combined with its respective random parameters or agreed salt values ​​to form corresponding commitment input data.

[0042] Then, an irreversible one-way hash operation is performed on each commitment input data to generate multiple independent field-level commitment values, forming a multi-dimensional commitment vector. Each commitment field in the multi-dimensional commitment vector is then written into the blockchain ledger along with the off-chain storage pointer.

[0043] During the audit phase, the target commitment field in the multidimensional commitment vector is selected based on the audit request. The commitment input data is reconstructed by combining the plaintext value of the corresponding field in the off-chain risk database with random parameters, and the hash operation is performed again. By comparing whether the recalculation result is consistent with the corresponding commitment field on the chain, the correctness of the selected audit field is verified. Other commitment fields that are not selected and their plaintext remain hidden. Thus, with the synergy of the cryptographic commitment mechanism and the immutable ledger of the blockchain, a technical solution for verifiable and controlled disclosure of audit key information by field and by scope is completed.

[0044] This allows for fine-grained, on-demand verification of risk scoring range fields, risk level fields, model version fields, and assessment timestamp fields, while ensuring the immutability of on-chain evidence. This improves the flexibility and targeting of audit operations and reduces the exposure of unnecessary fields during the audit process, effectively solving the problem of selective field-level auditing that cannot be performed in the above solutions.

[0045] S150: Generates an anonymous trading index based on foreign exchange trading data and preset random factors.

[0046] In the first possible implementation, Figure 2 This is a flowchart illustrating a specific implementation of S150 according to an example embodiment of this application. For example... Figure 2 As shown, the above-mentioned S150 includes: S1511. Obtain transaction identifiers from foreign exchange transaction data.

[0047] In this step, at least one of the following can be extracted from the transaction instruction records of the foreign exchange trading system: a transaction serial number, a message number, or an order number, to uniquely identify the target foreign exchange transaction. This transaction identifier corresponds one-to-one with the internal primary key or unique index of the target foreign exchange transaction in the trading system.

[0048] S1512. Based on the first random factor generated internally by the institution, the transaction identifier is concatenated with the first random factor to obtain the transaction index input data.

[0049] The first random factor can be generated by the security module inside the organization according to a preset random number generation strategy. The preset random number generation strategy includes at least one of a true random number generator or a cryptographically secure pseudo-random number generator.

[0050] The transaction identifier is converted into a first string with a preset encoding format, the first random factor is converted into a second string with a preset encoding format, and the first string and the second string are concatenated according to a preset concatenation order to obtain the transaction index input data.

[0051] S1513. Perform a one-way hash operation on the transaction index input data to obtain the anonymous transaction index.

[0052] In this step, a preset one-way hash algorithm can be selected to perform a hash operation on the transaction index input data. The one-way hash algorithm can be SHA-256, SM3, or a combination thereof. The hash result obtained from the hash operation is used as the anonymous transaction index, where the anonymous transaction index is a fixed-length binary sequence or its corresponding hexadecimal string representation.

[0053] S1514. Store the mapping relationship between the transaction identifier, the first random factor, and the anonymous transaction index in an internal mapping table that is only visible to the generating institution.

[0054] An internal mapping table is pre-created within the organization's controlled network environment and stored in a secure database accessible only to authorized accounts within the organization.

[0055] After generating the anonymous transaction index, a mapping record is written to the internal mapping table. This mapping record includes at least the transaction identifier, the first random factor, and the anonymous transaction index. Access control and audit logging are implemented for read and write operations to the internal mapping table to prevent unauthorized entities from obtaining the mapping between transaction identifiers and the anonymous transaction index.

[0056] In the above scheme, a unique transaction identifier for the target foreign exchange transaction is first obtained from the foreign exchange transaction data. Then, the transaction identifier is concatenated with the first random factor generated internally by the institution to form the transaction index input data. Subsequently, a one-way hash operation is performed on the transaction index input data to obtain the anonymous transaction index. The mapping relationship between the transaction identifier, the first random factor, and the anonymous transaction index is stored only in an internal mapping table visible to the generating institution. This ensures that the publicly or semi-publicly available information in the on-chain evidence record is only the anonymous transaction index, and does not contain the original transaction identifier that can be directly identified by other institutions or external entities.

[0057] This solution allows the generating institution to quickly reconstruct the specific transaction identifier using an internal mapping table based on the anonymous transaction index when auditing, dispute resolution, or risk tracing is required. This ensures the accurate location and traceability of the risk assessment results for a single foreign exchange transaction.

[0058] On the other hand, since the anonymous transaction index is obtained by concatenating a high-entropy random factor with the transaction identifier and then performing a one-way hash operation, other nodes in the consortium blockchain cannot deduce the real transaction identifier or the customer and account information bound to it from the anonymous transaction index without knowing the first random factor and the internal mapping table. This can reduce the exposure of sensitive business information to on-chain risk evidence records, thereby effectively solving the problems of privacy leakage caused by directly uploading transaction identifiers to the blockchain in the background technology and the reverse identification of order institutions that share ledgers among multiple institutions. This achieves a technical balance between verifiable evidence storage and privacy protection in foreign exchange transaction risk assessment results.

[0059] It's worth noting that in practical applications, if a transaction identifier is hashed only once or combined with a fixed random factor before hashing, multiple transactions from the same customer within the same time interval will exhibit observable stable patterns in their on-chain index distribution, making them easily extractable by time series analysis algorithms. Furthermore, since a customer's transactions across multiple time segments often exhibit clusterable trajectories in the on-chain index space, attackers can construct a dictionary using a small number of externally known transaction samples (such as a subset of plaintext transaction records held by an organization) to perform collision tests on the on-chain index, gradually reconstructing the correspondence between the index and the real customer.

[0060] In other words, because the index of the same transaction is stable across different time segments, the distribution of transaction behavior over time is correlated, and a single random factor is usually controlled by a single institution, attackers can use time series analysis, frequency analysis, dictionary attacks on known samples, and other methods to infer the relationship between anonymous on-chain indexes and real customer identities and specific transaction behaviors. This poses a significant risk of transaction behavior re-identification and customer privacy leakage in consortium blockchain scenarios where multiple parties share information.

[0061] In response, in the second possible implementation, Figure 3 This is a flowchart illustrating a specific implementation of S150 according to another example embodiment of this application. For example... Figure 3 As shown, the above-mentioned S150 includes: S1521. Generate a pseudo-identity for the customer based on the customer identifier and a long-term random factor.

[0062] In this step, the customer identifier can be standardized to obtain a standardized customer identifier field. Then, a long-term random factor is obtained from an internal secure random source, and the standardized customer identifier field is concatenated with the long-term random factor according to a preset concatenation rule to obtain the customer pseudo-identity input data. The long-term random factor is stored securely within the organization and, along with the customer pseudo-identity identifier, is stored in an off-chain risk database for verification and restoration of the pseudo-identity when needed. Finally, a one-way hash operation is performed on the customer pseudo-identity input data to obtain the customer pseudo-identity identifier.

[0063] S1522. Divide the time axis into multiple time segments and determine the target time segment identifier based on the occurrence time of the target foreign exchange transaction.

[0064] The time granularity can be determined based on business needs, dividing the natural timeline into multiple continuous and non-overlapping time segments according to a preset time length. Each time segment is assigned a unique time segment number, which serves as the time segment identifier. When conducting risk assessments on target forex transactions, the corresponding time segment number is retrieved based on the transaction's occurrence time and used as the target time segment identifier.

[0065] S1523. Generate combined index input data based on the client pseudo-identity identifier, the target time segment identifier, and the sequence number of the target forex transaction within the target time segment.

[0066] Within the target time segment, all forex transactions are sorted according to the transaction occurrence time and a preset sorting rule, and a serial number is assigned to each forex transaction to obtain the serial number corresponding to the target forex transaction.

[0067] The customer pseudo-identity identifier, target time segment identifier, and sequence number are concatenated according to a preset field order and encoding method to obtain the composite index input data. This composite index input data is used to uniquely identify the target forex transaction within the target time segment.

[0068] S1524. Perform a one-way hash operation on the composite index input data to generate an anonymous transaction index.

[0069] Specifically, a preset one-way hash algorithm can be selected to perform irreversible hashing on the combined index input data, resulting in a fixed-length hash output as the anonymous transaction index. The mapping relationship between the anonymous transaction index and the corresponding customer pseudo-identity identifier, target time segment identifier, and sequence number is stored in an off-chain risk database. Without obtaining the long-term random factor and mapping relationship, no external entity can infer the real customer identifier or real transaction information from the anonymous transaction index.

[0070] The above scheme generates a pseudo-identity identifier for customers by concatenating the customer identifier with a long-term random factor and inputting it into a one-way hash algorithm. In a cryptographic sense, it hides the real customer identifier in a high-entropy hash space, and the long-term random factor is only securely stored within the organization, making it difficult for external nodes to reverse-engineer the real customer identifier even if they have mastered the hash algorithm.

[0071] Secondly, the continuous time axis is divided into multiple non-overlapping time segments, and a unique time segment identifier is assigned to each time segment. This allows for the explicit introduction of discrete labels of the time dimension in the subsequent index construction, artificially increasing the difference in index input between different time segments.

[0072] Furthermore, within each time segment, target forex transactions are sorted by occurrence time and assigned a sequence number. Index input data is constructed by combining customer pseudo-identity, time segment identifier, and sequence number, so that the index inputs for different transactions of the same customer within the same time segment are also different from each other.

[0073] Finally, the combined index input data is fed into a preset one-way hash algorithm (such as the SHA series) to generate a fixed-length anonymous transaction index. By utilizing the irreversibility and collision resistance of one-way hashing, it is ensured that without knowing the long-term random factors and internal mapping relationships, external entities will find it difficult to restore the false identity or real customer identifier of the customer from the on-chain anonymous transaction index, and it will also be difficult to construct an effective dictionary attack path.

[0074] This approach maintains a unique identifier for each transaction while decoupling the on-chain presentation of multiple transactions from the same customer. It enhances customer privacy protection during the evidence storage process for foreign exchange transaction risk assessments in a consortium blockchain environment and resolves the risks of privacy leaks and re-identification caused by the possibility of correlation analysis of the index structure in practical applications.

[0075] It is worth noting that when multiple banks or financial institutions jointly build a consortium blockchain ledger, each institution usually generates and uploads its own transaction index on the blockchain. For example, they may directly perform one-way hashing on the transaction identifier of their own institution, or introduce a fixed random salt value within their own institution before hashing, and use the hash result as an on-chain index for the association and retrieval of risk assessment results.

[0076] The aforementioned scheme relies solely on random factors or fixed rules within a single institution to generate the index. On one hand, it is difficult for other participating institutions in the consortium blockchain to effectively verify the fairness and consistency of the index generation process without exposing the real transaction identifiers. On the other hand, once an institution's internal random factors are leaked or abused by insiders, that institution can unilaterally achieve a reverse correlation from the anonymous on-chain index to the real transaction identifier off-chain. This leads to significant privacy risks and excessive concentration of power in scenarios where multiple institutions share a ledger, making it difficult to meet the needs of consortium blockchain applications that require multi-party collaboration and mutual distrust.

[0077] In response, when the blockchain ledger is a consortium blockchain built by multiple institutions, in the third possible implementation, Figure 4 This is a flowchart illustrating a specific implementation of S150 according to another example embodiment of this application. For example... Figure 4 As shown, the above-mentioned S150 includes: S1531, Each participating institution in the consortium blockchain generates its own random factor.

[0078] Each organization's random factor is a high-entropy random number generated by the corresponding participating organization's secure random number generation module within a preset time period. The secure random number generation module runs in a server environment equipped with a hardware security module, and each organization's random factor is securely stored only within its own organization with access control policies set to prevent unauthorized entities from obtaining or tampering with the organization's random factor.

[0079] S1532. Combine the random factors of each institution according to the preset combination rules to obtain the joint random factor.

[0080] In this step, each participating institution encrypts and encapsulates its own random factor to obtain an encrypted random factor. This encrypted random factor is then broadcast to other participating institutions via the consortium blockchain consensus network. Homomorphic operations or key-based collaborative operations are performed on each encrypted random factor according to preset combination rules to obtain a joint random factor.

[0081] Among them, the preset combination rules include at least one or more of bitwise XOR, modular addition, and homomorphic addition, so as to ensure that any participating institution cannot derive the original random factor of its own institution corresponding to the joint random factor without knowing the random factors of other institutions.

[0082] S1533. Generate index input data based on transaction identifiers and joint random factors, and perform one-way hash operation on the index input data to obtain the anonymous transaction index.

[0083] Specifically, the transaction identifier and the joint random factor can be concatenated according to a preset field order to obtain the original index input byte sequence. The original index input byte sequence is then encoded and normalized to obtain the index input data. This encoding and normalization process includes padding the transaction identifier and formatting the joint random factor with a fixed byte order to ensure the deterministic consistency of the index input data generated for the same foreign exchange transaction across different participating institutions.

[0084] Then, the index input data is fed into a preset one-way hash algorithm for hashing to obtain the hash output value. Based on the index field length requirements of the consortium blockchain system, a hash fragment of a predetermined length is extracted from the hash output value as an anonymous transaction index. The preset one-way hash algorithm is one of the SHA series algorithms, the SM3 algorithm, or other one-way hash algorithms with collision resistance and irreversibility. This preset algorithm is identified and recorded in the consortium blockchain system configuration so that the same algorithm can be used for recalculation during subsequent auditing or verification processes.

[0085] After receiving the anonymous transaction index, the consortium blockchain node stores and retrieves it only as an index field in the on-chain risk evidence record. Each participating institution maintains the mapping relationship between the transaction identifier and its own random factor internally, without exposing the mapping relationship in the consortium blockchain ledger. When off-chain auditing or correlation queries are required for a specific anonymous transaction index, at least two participating institutions participate in reconstructing the joint random factor using their respective institutional random factors. The candidate transaction identifier and the joint random factor are then combined in a secure multi-party computation environment, and the hash value is recalculated to compare its consistency with the anonymous transaction index. This ensures that no single institution, possessing only its own random factor, can deduce the transaction identifier from the anonymous transaction index through reverse computation or offline exhaustive search. In other words, no single institution can independently reconstruct the transaction identifier without obtaining the random factors of other institutions.

[0086] In the above implementation, firstly, each participating institution independently generates a high-entropy random factor within its controlled environment and securely stores it off-chain, thereby ensuring that each random factor is only visible to the corresponding institution in the initial stage.

[0087] Secondly, through preset combination rules, such as bitwise XOR, modular addition, homomorphic addition, or key cooperative operation, mathematical operations are performed on the random factors of each institution to obtain a joint random factor. This joint random factor is cryptographically equivalent to a function of multiple random sources, ensuring that it is difficult to reverse-engineer other input values ​​in the event that any single input is missing.

[0088] Subsequently, the real transaction identifier and the joint random factor are concatenated and encoded in a preset field order to obtain the index input data. Then, a one-way hash algorithm with collision resistance and irreversibility, such as the SHA series algorithm or the national cryptographic SM3 algorithm, is used to perform a hash operation on the index input data. By utilizing the irreversibility and pseudo-randomness of the hash output value, it is difficult to recover the original transaction identifier and the complete joint random factor within a feasible time, even if the anonymous transaction index and some random factors are obtained.

[0089] Meanwhile, the generation process of the joint random factor and the index calculation process can be recorded in the on-chain or off-chain audit log through the consortium blockchain consensus module, so that when needed, multiple parties can re-enact the calculation process based on the same combination rules and hash algorithm to verify whether a specific anonymous transaction index is generated by the agreed input.

[0090] S160, Construct on-chain risk evidence storage records.

[0091] Optionally, on-chain risk evidence records should include at least an anonymous transaction index, publicly available statistical information, privacy commitment value, audit commitment value, and off-chain storage pointers.

[0092] Specifically, this can be achieved by setting a first visible field, a second visible field, and a third visible field in the on-chain risk evidence storage record. Statistical public information is set as the first visible field and written to the blockchain ledger in plaintext. The anonymized risk type category information is set as the second visible field, which is then encrypted using a role key and written to the blockchain ledger. The privacy commitment value and audit commitment value are set as the third visible field and stored in association with an off-chain storage pointer. Different role nodes have different access permissions to the first, second, and third visible fields.

[0093] Furthermore, the nodes with different roles include at least ordinary business nodes, internal audit nodes, and regulatory nodes. Among them, ordinary business nodes are only authorized to access the first visible field, internal audit nodes are authorized to access both the first and second visible fields and can participate in the verification of commitment values ​​in the audit process, and regulatory nodes are authorized to access both the first and second visible fields with valid authorization and can obtain some off-chain plaintext for sampling verification through the audit interface.

[0094] S170. Write the on-chain risk evidence record into the blockchain ledger.

[0095] Upon receiving an on-chain risk evidence record to be written, the on-chain risk evidence record is encapsulated into a blockchain transaction message. The payload of the blockchain transaction message carries an anonymous transaction index, statistical public information, privacy commitment value, audit commitment value, and off-chain storage pointer.

[0096] The relevant institutional node signs the blockchain transaction message to obtain the institutional signature, and then attaches the institutional signature to the transaction header of the blockchain transaction message to represent the source institution and integrity of the on-chain risk evidence record.

[0097] The blockchain transaction message carrying the institution's signature is broadcast to the consensus network corresponding to the blockchain ledger. The accounting nodes participating in the consensus verify the legality of the blockchain transaction message. The legality verification includes at least verifying the validity of the institution's signature and verifying the compliance of the blockchain transaction message format.

[0098] When a blockchain transaction message is selected and packaged into a new block through a consensus algorithm, the on-chain risk evidence record is written into the transaction list of the new block, and the block header digest of the new block is calculated according to a preset hash algorithm, thus connecting the new blockchain to the end of the blockchain ledger.

[0099] Through the consensus algorithm and the one-way hashing characteristic of the block header digest, any subsequent tampering with the on-chain risk evidence record already written into the blockchain ledger will result in inconsistencies in the digests of the corresponding block and its subsequent blocks, thereby achieving tamper-proof evidence storage of the risk assessment results of foreign exchange transactions.

[0100] S180. Store privacy risk information, key audit information, random factors, and plaintext risk records corresponding to off-chain storage pointers in the off-chain risk database.

[0101] Specifically, a risk record master table and a random factor association table are pre-configured for the off-chain risk database. The risk record master table is used to store plaintext risk records and their structured field information, while the random factor association table is used to store the random factors and commitment generation parameters corresponding to the plaintext risk records.

[0102] After obtaining the privacy risk information, key audit information, random factors, and plaintext risk records corresponding to the target foreign exchange transaction, a target risk record identifier is generated based on the anonymous transaction index and / or transaction identifier, and a new record is inserted into the risk record master table using the target risk record identifier as the primary key.

[0103] In the main risk record table, fields belonging to privacy risk information are written into the privacy field area, fields belonging to audit key information are written into the audit field area, and plaintext risk records corresponding to off-chain storage pointers are stored in a structured form in the plaintext field area.

[0104] In the random factor association table, the target risk record identifier is used as a foreign key to store the first random parameter used to generate the privacy commitment value and the second random parameter used to generate the audit commitment value, and / or to store the preset random factor and joint random factor used to generate the anonymous transaction index.

[0105] Set field-level access control policies for the privacy risk information field and random factor field stored in the off-chain risk database, restricting access or query to only internal audit nodes and regulatory agency nodes with corresponding permissions within the legally authorized scope, in order to reduce the risk of leakage of privacy risk information and random factors.

[0106] In this embodiment, the risk assessment results corresponding to foreign exchange transaction data are split into at least two items: privacy risk information, audit key information, and statistical public information. Commitment values ​​are generated for the privacy risk information and audit key information respectively, resulting in privacy commitment values ​​and audit commitment values. Then, an anonymous transaction index is generated based on the foreign exchange transaction data and a preset random factor, and an on-chain risk evidence record is constructed. The on-chain risk evidence record is written into the blockchain ledger to provide tamper-proof evidence of the risk assessment results of foreign exchange transactions. The privacy risk information, audit key information, random factor, and plaintext risk records corresponding to off-chain storage pointers are stored in the off-chain risk database. This allows the on-chain records to provide sufficient and verifiable risk evidence for authorized audit entities while minimizing the visibility between nodes to the risk status of specific customers and individual transactions. This achieves a controllable technical balance between privacy protection and audit verifiability.

[0107] Building upon the above embodiments, since the blockchain ledger and the off-chain risk database are two independent storage and maintenance systems, their data write paths, transaction control mechanisms, and access permission systems are not entirely unified. Blockchain nodes only perform consensus and immutability protection on on-chain evidence records, while the addition, deletion, modification, and querying of the off-chain risk database are typically completed independently by application services, database administrators, or operation and maintenance scripts. In the absence of a computable correlation, the blockchain ledger only records static commitment values, making it impossible to actively correlate and verify whether the plaintext records and random parameters off-chain have been arbitrarily modified or lost. In other words, based on the above embodiments, it is necessary to further construct an on-chain and off-chain consistency verification mechanism that is automatically triggered within a preset reconciliation period. This would enable the system to promptly and reliably detect whether newly added or updated risk assessment records in the off-chain risk database are consistent with the corresponding commitment values ​​in the blockchain ledger, thereby achieving continuous verification of the integrity and tamper-proof nature of off-chain risk records without disclosing plaintext content.

[0108] In response, Figure 5 This is a flowchart illustrating a foreign exchange transaction risk data processing method according to another example embodiment of this application. Figure 5 As shown, this embodiment may further include: S210. When the preset reconciliation period arrives, trigger the consistency verification operation between the off-chain risk database and the blockchain ledger.

[0109] In this step, the start and end times of the target reconciliation period can be determined based on the reconciliation period parameters configured in the system.

[0110] When the current system time reaches the end time of the target reconciliation cycle, a reconciliation task identifier is generated and written to the reconciliation task queue. The pre-defined reconciliation task scheduling module retrieves the reconciliation task identifier from the queue, triggering a consistency verification operation between the off-chain risk database and the blockchain ledger. During the execution of the reconciliation task, the task status is updated to "in progress." After completion, the task status is updated to "completed" or "abnormal," and the corresponding reconciliation result summary is recorded.

[0111] S220. In the consistency verification operation, retrieve the risk assessment records that have been added or updated within the target reconciliation period from the off-chain risk database.

[0112] In the off-chain risk database, each risk assessment record is assigned a record generation time field and a record update time field. Based on the start and end times of the target reconciliation period, risk assessment records whose record generation time or record update time falls within the target reconciliation period are retrieved from the off-chain risk database, resulting in the target risk assessment record set.

[0113] During the retrieval process, risk assessment records that are still in an unconfirmed state are filtered out based on the on-chain status flag corresponding to each risk assessment record, and only risk assessment records with the on-chain status flag of confirmed state are retained to participate in the consistency verification.

[0114] The target risk assessment record set is sorted by transaction identifier, version number, or block timestamp to facilitate the sequential execution of subsequent commitment value recalculation and comparison operations.

[0115] S230. For each risk assessment record, recalculate the commitment value based on off-chain plaintext data and corresponding random parameters, and compare it with the corresponding commitment value in the blockchain ledger.

[0116] For each risk assessment record in the target risk assessment record set, read the privacy risk information, key audit information, first random parameter, and second random parameter corresponding to that risk assessment record from the off-chain risk database.

[0117] The privacy risk information is serialized to obtain the first byte sequence. The first byte sequence is then subjected to an irreversible hash operation based on the first random parameter, and the off-chain privacy commitment value is recalculated.

[0118] The key audit information is serialized to obtain the second byte sequence. The second byte sequence is then subjected to an irreversible hash operation based on the second random parameter, and the off-chain audit commitment value is recalculated.

[0119] Based on the off-chain storage pointer stored in the risk assessment record, query the on-chain risk evidence record corresponding to the risk assessment record in the blockchain ledger, and obtain the privacy commitment value and audit commitment value stored in the on-chain risk evidence record.

[0120] The off-chain privacy commitment value is compared with the privacy commitment value in the on-chain risk evidence record, and the off-chain audit commitment value is compared with the audit commitment value in the on-chain risk evidence record to determine whether there are any inconsistencies in the commitment values.

[0121] S240. If an inconsistency is detected between the off-chain commitment value and the on-chain commitment value of any record, an abnormal alarm message is generated and written to the audit log.

[0122] During the comparison of commitment values, if an inconsistency is detected between the off-chain privacy commitment value and the corresponding on-chain privacy commitment value, or between the off-chain audit commitment value and the corresponding on-chain audit commitment value, the risk assessment record will be marked as an abnormal record.

[0123] For each abnormal record, generate an abnormal alarm message that includes the transaction identifier or anonymous transaction index, risk assessment record version number, block height or block timestamp, off-chain commitment value, on-chain commitment value, and inconsistency type.

[0124] The abnormal alarm information is sent to the preset alarm processing module. The alarm processing module pushes the abnormal alarm information to the operation and maintenance personnel, compliance personnel or internal auditors according to the abnormality level, and can trigger subsequent manual verification or automated handling processes according to preset policies.

[0125] While generating abnormal alarm information, in order to avoid interrupting the normal reconciliation process, the reconciliation task is continued to be completed, and the number of abnormal records and their identification information are recorded in the reconciliation task results.

[0126] Then, a dedicated audit log module is configured for the consistency verification operation. This module records key events during the execution of the reconciliation task. For each generated exception alarm, an audit log record is constructed that includes the reconciliation task identifier, the exception alarm content, the alarm generation time, the alarm level, and the processing status.

[0127] Audit log records are written to the audit log storage medium in chronological order, and a one-way hash digest is generated for each audit log. Adjacent audit log digests are chained together to form a local reconciliation audit chain.

[0128] Within a preset time interval, the root digest of the local reconciliation audit chain is obtained and written into the blockchain ledger. This allows for verification of whether the local reconciliation audit chain has been tampered with during subsequent audits, based on the root digest stored in the blockchain ledger. This further verifies the reliability and integrity of the consistency check operation and anomaly alarm records.

[0129] In the above embodiments, by triggering a consistency verification operation between the off-chain risk database and the blockchain ledger when the preset reconciliation period arrives, the system can automatically filter out the risk assessment records that are added or updated in the target reconciliation period from the off-chain risk database in each reconciliation period, and recalculate the privacy commitment value and audit commitment value based on the off-chain plaintext data and corresponding random parameters, and compare them one by one with the corresponding commitment values ​​in the blockchain ledger.

[0130] Once an inconsistency is detected between the off-chain and on-chain commitment values ​​of any record, an anomaly alert is immediately generated and written to the audit log. This technical solution allows the system to continuously monitor the off-chain risk database for tampering, missing data, or abnormal updates without exposing plaintext risk records. Furthermore, it enables precise location of anomalous data at the smallest granularity (record level), thus resolving the long-term inconsistency between on- and off-chain records that is difficult to detect in a timely manner. This improves the integrity, reliability, and auditability of the foreign exchange transaction risk data storage system.

[0131] In the summary of the on-chain process in the above embodiments, if a unified status identifier and version management mechanism is not set between off-chain records and on-chain evidence, and records that have been uploaded to the chain are only roughly distinguished by timestamps or simple markers, then due to the lack of rigorous status control and version control strategies, when business personnel perform supplementary, modified, or revoked operations on the generated risk records, problems such as inconsistencies between off-chain data and on-chain evidence, overwriting of old data, or even subsequent tampering are easy to occur and difficult to detect. This weakens the institutional constraint of the immutability of the blockchain and makes it difficult to form a reliable chain of evidence in compliance review and post-event accountability.

[0132] Therefore, in the process of processing and storing foreign exchange transaction risk data on the blockchain, it is necessary to further address how to set strict on-chain status flags and version control mechanisms for off-chain risk records, regulate the operational boundaries between unconfirmed and confirmed records, allow business revisions of risk assessment results while preventing unauthorized alteration of confirmed risk records, thereby ensuring data consistency and traceability between the off-chain risk database and the blockchain ledger, and providing a clear, complete, and non-repudiable version evolution trajectory for the audit process.

[0133] In response, Figure 6 This is a flowchart illustrating a foreign exchange transaction risk data processing method according to another example embodiment of this application. Figure 6 As shown, this embodiment may further include: S310. When writing the risk assessment results of the target foreign exchange transaction into the off-chain risk database, set the on-chain status flag for the risk record corresponding to the target foreign exchange transaction to an unconfirmed state.

[0134] In the off-chain risk database, each risk record is pre-defined with an on-chain status flag field and a version number field. When the risk assessment module generates a risk assessment result for a target forex transaction, a risk record object is constructed according to a pre-defined data structure. The comprehensive risk assessment value, risk level, risk type, and customer identifier, account identifier, anonymous transaction index, and off-chain storage pointer corresponding to the target forex transaction are written into the risk record object.

[0135] When writing a risk record object to the off-chain risk database, the on-chain status flag field is initialized to an unconfirmed state, and the version number field is set to the initial version number. Through the database write interface or transaction control mechanism, it is ensured that the risk record object, its on-chain status flag field, and version number field are committed within the same transaction.

[0136] S320. After the on-chain risk evidence record corresponding to the risk assessment result completes blockchain consensus and is confirmed to be written into the blockchain ledger, the on-chain status flag is updated to the confirmed status.

[0137] When submitting on-chain risk evidence records to the blockchain network, the transaction hash value corresponding to the on-chain risk evidence record and the anonymous transaction index corresponding to the target forex transaction are recorded.

[0138] Then, listen for or subscribe to block generation events in the blockchain ledger. When a block containing a transaction hash value is detected to be packaged and reaches a preset confirmation depth, it is determined that the on-chain risk evidence record has been confirmed and written into the blockchain ledger.

[0139] Based on the anonymous transaction index, the risk record corresponding to the target forex transaction is located in the off-chain risk database. In transaction control mode, the on-chain status flag field of the risk record is updated from unconfirmed to confirmed, and the corresponding block height and block timestamp are recorded.

[0140] S330. Modification of risk records is prohibited while they are in an unconfirmed state.

[0141] Configure update trigger rules for update operations on risk records in the off-chain risk database. The update trigger rules are used to read the on-chain status flag field of the target risk record before executing the update operation.

[0142] When the on-chain status flag field is detected to be in an unconfirmed state, the update request for the risk record is intercepted, and an error code or exception message is returned to refuse the update.

[0143] When the on-chain status flag field is detected to be in a confirmed state, the new version generation process is only allowed to be triggered according to the preset version control strategy, and the original record content is not allowed to be directly overwritten.

[0144] The above update triggering rules are applied to all risk record update interfaces of the business system through database access control policies to prevent direct database write operations that bypass application logic.

[0145] S340. If a confirmed risk record needs to be revised for business reasons, a new version of the risk record will be generated, and the old version will be retained for query purposes only and will not be modified.

[0146] When the business system detects a need to revise a risk record that has been confirmed, it reads the latest version of the risk record from the off-chain risk database based on the transaction identifier or anonymous transaction index of the risk record and the current version number.

[0147] While retaining the original version number, on-chain status flag, and block timestamp of the risk record, a new risk record object is generated using the risk record as a template, and the risk level, risk type, comprehensive risk assessment value, or other fields that need to be revised are updated.

[0148] Set the version number field of the new risk record object to the target version number, which is incremented by the original version number, and initialize the on-chain status flag field to an unconfirmed state. Write the new risk record object as an independent record to the off-chain risk database, and set the writable flag of the original version risk record to a read-only state to prevent modification operations on the old version risk record.

[0149] After the new version of the risk record completes the corresponding on-chain risk evidence record and writes it into the blockchain ledger and reaches the preset confirmation depth, the on-chain status flag field of the new version of the risk record will be updated to the confirmed status.

[0150] S350: During the audit, the version number and the corresponding block timestamp are used to determine whether there has been any subsequent tampering.

[0151] During the audit process, based on the transaction identifier or anonymous transaction index of the target foreign exchange transaction, all version risk records corresponding to the target foreign exchange transaction are retrieved from the off-chain risk database and sorted in ascending order of version number.

[0152] For each version risk record, its on-chain status flag field, version number field, and the record's block height and block timestamp information are read. The generation time and on-chain confirmation time of each version risk record are compared with the corresponding block timestamp to determine whether the time sequence between versions is consistent with the incremental relationship of the version number.

[0153] When a record is detected where the on-chain status is marked as confirmed but the version content does not match the corresponding block timestamp or on-chain commitment value, or where a record was modified before a subsequent block time, this situation is marked as suspected post-event tampering, and an audit anomaly report containing the abnormal version number, abnormal fields, and corresponding block information is generated. Finally, the audit anomaly report is written to the audit log, and regulatory alerts or further manual review processes can be triggered according to the audit strategy.

[0154] In the above embodiments, when the risk assessment results of the target foreign exchange transaction are written into the off-chain risk database, the on-chain status flag is set to an unconfirmed state. Only after the corresponding on-chain risk evidence record completes blockchain consensus and is confirmed to be written into the blockchain ledger is the on-chain status flag updated to a confirmed state. During the unconfirmed state, modification of the risk record is prohibited. Confirmed risk records can only be revised by adding a new version, and the old version is kept in read-only archive. At the same time, during auditing, the version number and the corresponding block timestamp are combined to determine whether there is any subsequent tampering. Thus, the ability to modify off-chain data is strictly bound to the on-chain confirmation status. Any change to the content of the confirmed record will be explicitly exposed in the form of a new version. The old version cannot be overwritten or deleted. Auditors can restore the true risk assessment results at each point in time based on the correspondence between different versions and block times. This effectively avoids the situation where the off-chain database is quietly modified to evade supervision, and achieves consistent, traceable and tamper-resistant risk record management on and off the chain.

[0155] It is worth noting that in the above embodiments, the off-chain risk database is typically accessed directly by multiple entities such as business systems and risk control systems. Although query and modification operations can be recorded through ordinary access logs, these logs are mostly in the form of ordinary records that can be rewritten and deleted, lacking strong constraints based on time sequence and anti-tampering mechanisms. Furthermore, there is no cryptographic binding between the log content and the blockchain ledger. This makes it difficult for auditing institutions to technically prove the authenticity and completeness of the off-chain database access and modification records in the event of malicious or illegal activities such as post-event log deletion or selective recording. This results in technical problems such as insufficient audit reliability and interruption of the accountability chain.

[0156] In response, Figure 7 This is a flowchart illustrating a foreign exchange transaction risk data processing method according to yet another example embodiment of this application. Figure 7As shown, this embodiment may further include: S410. Configure a dedicated audit interface for the off-chain risk database to record query and modification operations performed on the off-chain risk database.

[0157] By setting up an audit gateway module at the application service layer, query and modification operations targeting the off-chain risk database can only be forwarded to the off-chain risk database through this module. The audit gateway module performs identity authentication and access control verification on the connected business systems, allowing only authenticated business systems to initiate query and modification operations on the off-chain risk database. Furthermore, the audit gateway module pre-configures operation type identifiers and operation object identifiers corresponding to query and modification operations to facilitate the subsequent generation of audit transaction records.

[0158] S420. For each query or modification operation, generate an audit transaction record that includes the operation type, the entity initiating the operation, the operation time, the operation object identifier, and a summary before and after the operation.

[0159] When the audit gateway module receives a query or modification request for a target risk record, it determines the operation type and the initiating entity based on the business interface identifier, the calling system identifier, and the session credentials in the request message.

[0160] Obtain the timestamp of the query or modification operation from a secure time source as the operation time. Determine the target identifier based on the transaction identifier, customer identifier, or risk record primary key carried in the query or modification request.

[0161] Before performing the modification operation, the current field value of the target risk record is read from the off-chain risk database, the field value is serialized and the hash value is calculated to obtain the pre-operation summary.

[0162] After performing the modification operation, the modified target risk record field value is read from the off-chain risk database, the field value is serialized and the hash value is calculated to obtain the post-operation digest.

[0163] Finally, the operation type, the entity initiating the operation, the operation time, the operation object identifier, the pre-operation summary, and the post-operation summary are combined to form an audit transaction record.

[0164] S430. Link audit transaction records in chronological order to form a local audit chain.

[0165] Specifically, monotonically increasing sequence numbers or timestamps can be assigned to each audit transaction record written sequentially to determine their order within the local audit chain. All fields of the current audit transaction record are then serialized to obtain the byte sequence of the current transaction content.

[0166] When recording the genesis transaction record of the local audit chain, the preset initial vector is used as the hash value of the previous record and concatenated with the byte sequence of the content of the genesis transaction record to calculate the hash value of the first audit transaction record.

[0167] When recording any subsequent audit transaction record, the byte sequence of the audit transaction record is concatenated with the hash value corresponding to the previous audit transaction record, and a one-way hash operation is performed on the concatenation result to obtain the chained hash value of the current audit transaction record.

[0168] The chained hash values ​​of each audit transaction record are stored together with the corresponding audit transaction record in the audit chain data structure, so that if the content of any audit transaction record is tampered with or deleted, at least one subsequent chained hash value will change.

[0169] S440. Within a preset time interval, obtain the root digest of the local audit chain and write the root digest into the blockchain ledger.

[0170] When each preset time interval arrives, the audit transaction record added after the previous time interval is selected from the local audit chain, and a Merkle tree structure is constructed based on the chained hash value of these audit transaction records.

[0171] The root node hash value of the Merkle tree structure is used as the root digest corresponding to the current audit time window. An on-chain audit record transaction is constructed, containing the root digest, the corresponding time window identifier, and the generating organization identifier. This on-chain audit record transaction is submitted to the consensus network where the blockchain ledger resides. After the on-chain audit record transaction passes consensus and is confirmed and written into a new block, the corresponding block hash and transaction identifier are associated and stored with the root digest for quick location during subsequent audits.

[0172] S450. During the audit, the local audit chain is verified against the root digest stored in the blockchain ledger to further verify the security and integrity of the off-chain risk database.

[0173] When performing an audit operation, the root digest corresponding to the target audit time window, along with the associated time window identifier and generating organization identifier, is retrieved from the blockchain ledger. Based on the time window identifier, all audit transaction records and their chain hash values ​​recorded within that time window are extracted from the local audit chain.

[0174] Based on the extracted chain hash value, the local Merkle tree is reconstructed according to the preset Merkle tree construction rules, and the local Merkle root digest is calculated. The local Merkle root digest is compared with the root digest obtained from the blockchain ledger. If the two match, it is determined that the local audit chain has not been tampered with within this time window.

[0175] If the two are inconsistent, it is determined that at least one audit transaction record was deleted, inserted, or modified within that time window, and the abnormal audit transaction record is located further according to the Merkle tree path for precise investigation.

[0176] In the above embodiment, by configuring a dedicated audit interface for the off-chain risk database, all query and modification operations are forced to access through this interface. For each operation, an audit transaction record is generated, containing the operation type, operation subject, operation time, operation object identifier, and summaries before and after the operation. These audit transaction records are then chained together in chronological order to form a local audit chain. The root summary of the local audit chain is calculated and written to the blockchain ledger within a preset time interval. This embodiment achieves the following technical effects: On the one hand, any query or modification to the off-chain risk database will leave an irrefutable trace with data fingerprints before and after the operation in the local audit chain, and the impact of each operation on the risk data can be restored during the audit.

[0177] On the other hand, since the local audit chain is tightly bound to the historical records through a hash chain structure, and its root digest is periodically anchored to the immutable blockchain ledger, any attempt to delete, tamper with, or forge audit records afterward will cause the root digest calculated by the local audit chain to be inconsistent with the root digest already stored on the chain, thus being immediately detected by technical means. This solves the problem that audit logs are easily tampered with afterward and that audit institutions have difficulty verifying the authenticity and integrity of off-chain risk data and its access records.

[0178] Figure 8 This is a flowchart illustrating a foreign exchange transaction risk data processing system according to an example embodiment of this application. Figure 8 As shown in the embodiment of this application, the foreign exchange transaction risk data processing system 500 includes: The splitting module 510 is used to split the risk assessment results corresponding to foreign exchange transaction data into at least two of the following: privacy risk information, audit key information, and statistical public information. The generation module 520 is used to generate commitment values ​​for the privacy risk information and the audit key information respectively, so as to obtain the privacy commitment value and the audit commitment value; Index module 530 is used to generate an anonymous transaction index based on the foreign exchange transaction data and a preset random factor; The construction module 540 is used to construct an on-chain risk evidence record, which includes at least the anonymous transaction index, the statistical public information, the privacy commitment value, the audit commitment value, and the off-chain storage pointer. The evidence storage module 550 is used to write the on-chain risk evidence storage record into the blockchain ledger to provide tamper-proof evidence of the risk assessment results of the foreign exchange transaction. Storage module 560 is used to store the privacy risk information, the audit key information, the random factor, and the plaintext risk record corresponding to the off-chain storage pointer in the off-chain risk database.

[0179] Figure 9 This is a schematic diagram of the structure of an electronic device according to an example embodiment of this application. For example... Figure 9 As shown, the electronic device 600 provided in this embodiment includes: a processor 601 and a memory 602; wherein: Memory 602 is used to store computer programs, and the memory may also be flash memory.

[0180] Processor 601 is used to execute the execution instructions stored in the memory to implement the various steps in the above method. For details, please refer to the relevant descriptions in the preceding method embodiments.

[0181] Alternatively, the memory 602 can be either standalone or integrated with the processor 601.

[0182] When the memory 602 is a device independent of the processor 601, the electronic device 600 may further include: Bus 603 is used to connect the memory 602 and the processor 601.

[0183] This embodiment also provides a readable storage medium storing a computer program, which, when executed by at least one processor of an electronic device, enables the electronic device to perform the methods provided in the various embodiments described above.

[0184] This embodiment also provides a program product including a computer program stored in a readable storage medium. At least one processor of an electronic device can read the computer program from the readable storage medium, and the at least one processor executes the computer program to cause the electronic device to perform the methods provided in the various embodiments described above.

[0185] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the claims.

[0186] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A method for processing foreign exchange transaction risk data, characterized in that, include: The risk assessment results corresponding to foreign exchange transaction data are broken down into at least two of the following: privacy risk information, key audit information, and publicly available statistical information. A commitment value is generated for the privacy risk information and the audit key information respectively, resulting in a privacy commitment value and an audit commitment value; An anonymous trading index is generated based on the aforementioned foreign exchange trading data and a preset random factor. Construct an on-chain risk evidence record, which includes at least the anonymous transaction index, the statistical public information, the privacy commitment value, the audit commitment value, and the off-chain storage pointer; The on-chain risk evidence record is written into the blockchain ledger to provide tamper-proof evidence of the risk assessment results of the foreign exchange transaction. The privacy risk information, the key audit information, the random factor, and the plaintext risk record corresponding to the off-chain storage pointer are stored in the off-chain risk database.

2. The method according to claim 1, characterized in that, The risk assessment results are broken down into at least two of the following: privacy risk information, key audit information, and publicly available statistical information: Fields containing customer identifier, account identifier, specific risk type, and specific risk score are classified as privacy risk information; The model version identifier, risk score range, partial anonymization factors, and assessment timestamp used to verify the correctness of the risk assessment process are classified as the key audit information. The risk levels or risk level ranges that are publicly displayed on the blockchain or have undergone discretization are classified as the statistical public information.

3. The method according to claim 1, characterized in that, The process of generating commitment values ​​for the privacy risk information and the audit key information, respectively, to obtain a privacy commitment value and an audit commitment value, includes: The privacy risk information is serialized to obtain a first byte sequence, and an irreversible hash operation is performed on the first byte sequence according to a first random parameter to obtain the privacy commitment value. The audit key information is serialized to obtain a second byte sequence, and an irreversible hash operation is performed on the second byte sequence according to the second random parameter to obtain the audit commitment value; The first random parameter and the second random parameter, along with the privacy risk information and the audit key information, are stored together in the off-chain risk database.

4. The method according to claim 1, characterized in that, The process of generating commitment values ​​for the privacy risk information and the audit key information respectively also includes: The key audit information is broken down into multiple audit fields; Perform commitment operations on each of the audit fields to obtain the corresponding multidimensional commitment vectors; Each commitment field in the multidimensional commitment vector is written into the on-chain risk evidence record.

5. The method according to claim 1, characterized in that, The constructed on-chain risk evidence storage record includes: A first visible field, a second visible field, and a third visible field are set in the on-chain risk evidence storage record; The statistical public information is set as the first visible field and written into the blockchain ledger in plaintext form; The risk type category information that has been de-identified is set as the second visible field, and the second visible field is encrypted with a role key and then written into the blockchain ledger. Set the privacy commitment value and the audit commitment value as the third visible field and store them in association with the off-chain storage pointer; Different role nodes have different access permissions to the first visible field, the second visible field, and the third visible field.

6. The method according to claim 5, characterized in that, The different role nodes include at least ordinary business nodes, internal audit nodes, and regulatory agency nodes; The ordinary business node is only authorized to access the first visible field; The internal audit node of the organization is authorized to access the first visible field and the second visible field, and can participate in the verification of the commitment value in the audit process; The regulatory agency node is authorized to access the first visible field and the second visible field if it has obtained valid authorization.

7. The method according to claim 1, characterized in that, Also includes: When the preset reconciliation period arrives, a consistency verification operation between the off-chain risk database and the blockchain ledger is triggered; In the consistency verification operation, risk assessment records that are added or updated within the target reconciliation period are retrieved from the off-chain risk database; For each of the aforementioned risk assessment records, the commitment value is recalculated based on off-chain plaintext data and corresponding random parameters, and then compared with the corresponding commitment value in the blockchain ledger. If an inconsistency is detected between the off-chain commitment value and the on-chain commitment value of any record, an anomaly alarm is generated and written to the audit log.

8. The method according to claim 1, characterized in that, Also includes: When writing the risk assessment results of the target foreign exchange transaction into the off-chain risk database, the on-chain status flag for the risk record corresponding to the target foreign exchange transaction is set to unconfirmed. After the on-chain risk evidence record corresponding to the risk assessment result completes blockchain consensus and is confirmed to be written into the blockchain ledger, the on-chain status flag is updated to the confirmed status. Modification of the risk record is prohibited while the risk record is in an unconfirmed state; If a confirmed risk record needs to be revised for business reasons, a new version will be generated for the risk record, while the old version will be retained for query purposes only and cannot be modified. During the audit, the version number and the corresponding block timestamp are used to determine whether there has been any subsequent tampering.

9. The method according to claim 1, characterized in that, Also includes: Configure a dedicated audit interface for the off-chain risk database to record query and modification operations performed on the off-chain risk database; For each query or modification operation, generate an audit transaction record that includes the operation type, the entity initiating the operation, the operation time, the operation object identifier, and a summary before and after the operation. The audit transaction records are linked together in chronological order to form a local audit chain; Within a preset time interval, obtain the root digest of the local audit chain and write the root digest into the blockchain ledger; During the audit, the local audit chain is verified against the root digest stored in the blockchain ledger to determine whether it has been tampered with.

10. A foreign exchange transaction risk data processing system, characterized in that, include: The splitting module is used to split the risk assessment results corresponding to foreign exchange transaction data into at least two of the following: privacy risk information, key audit information, and publicly available statistical information. The generation module is used to generate commitment values ​​for the privacy risk information and the audit key information respectively, so as to obtain the privacy commitment value and the audit commitment value; The index module is used to generate an anonymous transaction index based on the foreign exchange transaction data and a preset random factor; The construction module is used to construct on-chain risk evidence storage records, which include at least the anonymous transaction index, the statistical public information, the privacy commitment value, the audit commitment value, and the off-chain storage pointer; The evidence storage module is used to write the on-chain risk evidence storage records into the blockchain ledger to provide tamper-proof evidence of the risk assessment results of the foreign exchange transaction. The storage module is used to store the privacy risk information, the audit key information, the random factor, and the plaintext risk record corresponding to the off-chain storage pointer in the off-chain risk database.

Images