Real-time risk monitoring method, device and equipment for bank transfer, medium and program product

Abstract

The invention provides a real-time risk monitoring method for bank transfer. The method can be applied to the technical field of block chains and the field of financial science and technology. The method comprises the following steps: in response to a transfer transaction request, converting the transaction request into a standardized event; broadcasting the standardized event to a smart contract cluster; obtaining a risk control decision result generated by the smart contract cluster for the standardized event; if it is determined that the risk control decision result is transaction release, generating a risk factor bitmap according to transaction data and the risk control decision result, and performing uplink evidence storage on the risk factor bitmap; and calling a tracking contract to perform on-chain real-time tracking on the fund flow direction, performing zero-knowledge processing on the tracking result, and broadcasting the tracking result to each node of the alliance chain to update a shared risk map, the shared risk map being used for providing associated risk data for the smart contract cluster. The invention further provides a bank transfer real-time risk monitoring device and equipment, a storage medium and a program product.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, specifically to the field of smart contract technology, and more specifically to a method, apparatus, device, medium, and program product for real-time risk monitoring of bank transfers. Background Technology

[0002] With the explosive growth of real-time payment services, financial institutions have an increasingly urgent need for sub-second-level risk control. The response delays of traditional risk control systems are no longer sufficient to intercept rapidly transferring risky transactions. Related technologies suffer from response time blind spots; batch processing or near-real-time systems have an average latency of over 300ms and an interception rate of less than 45%. Data trust and auditing lag, transaction data is easily tampered with, and the speed of post-transaction audits cannot meet regulatory requirements for "verifiable transactions in progress." Furthermore, information silos exist across institutions, leading to the failure of cross-institutional collaboration. Therefore, a real-time risk monitoring solution for bank transfers with rapid response and high interception rates is urgently needed. Summary of the Invention

[0003] In view of the above problems, this application provides a method, apparatus, equipment, medium and program product for real-time risk monitoring of bank transfers that has a rapid response and high interception rate.

[0004] According to the first aspect of this application, a method for real-time risk monitoring of bank transfers is provided, comprising: responding to a transfer transaction request by converting the transaction request into a standardized event; broadcasting the standardized event to a smart contract cluster; obtaining a risk control decision result generated by the smart contract cluster for the standardized event; if the risk control decision result is determined to allow the transaction, generating a risk factor bitmap based on the transaction data and the risk control decision result, and storing the risk factor bitmap on the blockchain; invoking a tracking contract to perform real-time on-chain tracking of fund flows, and broadcasting the tracking result to each node of the consortium blockchain after zero-knowledge processing to update a shared risk graph, wherein the shared risk graph is used to provide associated risk data for the smart contract cluster; wherein the smart contract cluster includes a scanning contract, a decision contract, and a tracking contract, the scanning contract is used to invoke a risk model pre-trained off-chain and hashed and fixed on-chain for on-chain inference, the decision contract is used to execute multi-dimensional risk rules, and the tracking contract is used to perform real-time on-chain tracking of fund flows.

[0005] According to an embodiment of this application, the method further includes: if the risk control decision result is determined to be a transaction rejection, generating a risk event and broadcasting the risk event to each node of the consortium blockchain to update the shared risk graph.

[0006] According to an embodiment of this application, the smart contract cluster generates risk control decision results for the standardized events by: calling the risk model on the scanning contract to perform on-chain reasoning to generate a risk score, wherein the risk model is pre-trained off-chain and then hashed and fixed on-chain; calling the shared risk graph interface according to the multi-dimensional risk rules of the decision contract to generate a risk judgment result; and generating a risk control decision result based on the risk score and / or the risk judgment result.

[0007] According to an embodiment of this application, converting the transaction request into a standardized event includes: extracting the target fields of the transaction request message, mapping the target fields to generate standard field names; querying the cache to perform real-time supplementary calculation of lightweight features, the lightweight features including the number of transactions within a preset time, the average transaction amount, and the distance between the current device and frequently used devices; and encapsulating the supplementary lightweight features and the standard field names into a standardized event.

[0008] According to an embodiment of this application, broadcasting the tracking results to each node of the consortium blockchain after zero-knowledge processing to update the shared risk graph includes: performing irreversible hash operations on the account address, device identifier, geographical location, and amount range in the tracking results to generate multiple hash leaves; constructing the multiple hash leaves into a hash tree to obtain the root hash; using a zero-knowledge circuit, with the root hash and a preset set of risk addresses as public inputs and the tracking results as private witnesses, generating a zero-knowledge proof; and broadcasting the zero-knowledge proof and the root hash as an anonymized event to each node of the consortium blockchain to update the shared risk graph.

[0009] According to an embodiment of this application, the shared risk graph is a dynamic graph database, where nodes are used to represent accounts or devices, and edges are used to represent fund or behavioral associations. Updating the shared risk graph includes updating node attributes and edge weights.

[0010] According to an embodiment of this application, the risk factor bitmap includes multiple Boolean bits, each Boolean bit corresponding to a risk factor, and the risk factor includes at least one of a large transaction indicator bit, a geographic location anomaly indicator bit, a risk address hit indicator bit, and a device anomaly indicator bit.

[0011] According to an embodiment of this application, the method further includes: setting a maximum execution time limit for contract calls in the smart contract cluster; if any contract call takes longer than the maximum execution time limit, setting the current transaction status to a timed-out transaction; and transferring the timed-out transaction to a manual review queue.

[0012] The second aspect of this application provides a real-time risk monitoring device for bank transfers. The device includes: a conversion module for converting a transfer transaction request into a standardized event in response to the transaction request; a first broadcast module for broadcasting the standardized event to a smart contract cluster; a risk control decision result acquisition module for acquiring the risk control decision result generated by the smart contract cluster for the standardized event; a notarization module for generating a risk factor bitmap based on transaction data and the risk control decision result if the risk control decision result is determined to allow the transaction, and storing the risk factor bitmap on the blockchain; and a tracking module for calling a tracking contract to perform real-time on-chain tracking of fund flows, and broadcasting the tracking result to each node of the consortium blockchain after zero-knowledge processing to update a shared risk graph, wherein the shared risk graph provides associated risk data to the smart contract cluster; wherein the smart contract cluster includes a scanning contract, a decision contract, and a tracking contract, the scanning contract for calling a risk model pre-trained off-chain and hashed and fixed on-chain for on-chain inference, the decision contract for executing multi-dimensional risk rules, and the tracking contract for real-time on-chain tracking of fund flows.

[0013] According to an embodiment of this application, the apparatus further includes a second broadcast module.

[0014] The second broadcast module is used to generate a risk event and broadcast the risk event to each node of the consortium blockchain if the risk control decision result is determined to be a transaction rejection, so as to update the shared risk graph.

[0015] According to embodiments of this application, a risk control decision generation module is also included.

[0016] The risk control decision module generates a risk score by calling the risk model on the scanning contract for on-chain reasoning. The risk model is pre-trained off-chain and then hashed and fixed on-chain. The module calls the shared risk graph interface according to the multi-dimensional risk rules of the decision contract to generate a risk judgment result. The module also generates a risk control decision result based on the risk score and / or the risk judgment result.

[0017] According to embodiments of this application, the conversion module includes an extraction submodule, a feature compensation submodule, and an encapsulation submodule.

[0018] The extraction submodule is used to extract the target fields of the transaction request message and map the target fields to generate standard field names; the feature supplementation submodule is used to query the cache to perform real-time supplementation of lightweight features, including the number of transactions within a preset time, the average transaction amount, and the distance between the current device and commonly used devices; and the encapsulation submodule is used to encapsulate the supplemented lightweight features and the standard field names into standardized events.

[0019] According to an embodiment of this application, the tracking module is further configured to perform irreversible hash operations on the account address, device identifier, geographical location, and amount range in the tracking results to generate multiple hash leaves; construct the multiple hash leaves into a hash tree to obtain the root hash; use zero-knowledge circuits, with the root hash and a preset set of risk addresses as public inputs and the tracking results as private witnesses, to generate a zero-knowledge proof; and broadcast the zero-knowledge proof and the root hash as an anonymization event to each node of the consortium blockchain to update the shared risk graph.

[0020] A third aspect of this application provides an electronic device comprising: one or more processors; and a memory for storing one or more computer programs, wherein the one or more processors execute the one or more computer programs to implement the steps of the method described above.

[0021] A fourth aspect of this application also provides a computer-readable storage medium having a computer program or instructions stored thereon, which, when executed by a processor, implement the steps of the above-described method.

[0022] The fifth aspect of this application also provides a computer program product, including a computer program or instructions that, when executed by a processor, implement the steps of the above-described method. Attached Figure Description

[0023] The above-mentioned contents, other objects, features and advantages of this application will become clearer from the following description of embodiments with reference to the accompanying drawings, in which:

[0024] Figure 1 The illustration schematically depicts application scenarios of the real-time risk monitoring method, apparatus, device, medium, and program product for bank transfers according to embodiments of this application;

[0025] Figure 2 A flowchart illustrating a real-time risk monitoring method for bank transfers according to an embodiment of this application is shown in the schematic diagram.

[0026] Figure 3 A flowchart illustrating a method for generating risk control decision results for the standardized event using a smart contract cluster according to an embodiment of this application is shown in the schematic diagram.

[0027] Figure 4 A flowchart illustrating a method for performing zero-knowledge processing on tracking results according to an embodiment of this application is shown:

[0028] Figure 5 This schematically illustrates a structural block diagram of a real-time risk monitoring device for bank transfers according to an embodiment of this application; and

[0029] Figure 6A block diagram schematically illustrates an electronic device suitable for implementing a real-time risk monitoring method for bank transfers according to an embodiment of this application. Detailed Implementation

[0030] The embodiments of this application will now be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of this application. In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments of this application for ease of explanation. However, it will be apparent that one or more embodiments may be implemented without these specific details. Furthermore, descriptions of well-known structures and technologies are omitted in the following description to avoid unnecessarily obscuring the concepts of this application.

[0031] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the scope of this application. The terms “comprising,” “including,” etc., as used herein indicate the presence of the stated features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.

[0032] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein are to be interpreted in a manner consistent with the context of this specification, and not in an idealized or overly rigid way.

[0033] When using expressions such as "at least one of A, B and C", they should generally be interpreted in accordance with the meaning that is commonly understood by those skilled in the art (e.g., "a system having at least one of A, B and C" should include, but is not limited to, a system having A alone, a system having B alone, a system having C alone, a system having A and B, a system having A and C, a system having B and C, and / or a system having A, B and C, etc.).

[0034] Based on the aforementioned technical problems, embodiments of this application provide a method for real-time risk monitoring of bank transfers, comprising: responding to a transfer transaction request by converting the transaction request into a standardized event; broadcasting the standardized event to a smart contract cluster; obtaining a risk control decision result generated by the smart contract cluster for the standardized event; if the risk control decision result is determined to allow the transaction, generating a risk factor bitmap based on the transaction data and the risk control decision result, and storing the risk factor bitmap on the blockchain; invoking a tracking contract to perform real-time on-chain tracking of fund flows, and broadcasting the tracking result to each node of the consortium blockchain after zero-knowledge processing to update a shared risk graph, wherein the shared risk graph is used to provide associated risk data for the smart contract cluster; wherein the smart contract cluster includes a scanning contract, a decision contract, and a tracking contract, the scanning contract is used to invoke a risk model pre-trained off-chain and hashed and fixed on-chain for on-chain inference, the decision contract is used to execute multi-dimensional risk rules, and the tracking contract is used to perform real-time on-chain tracking of fund flows.

[0035] Figure 1 The illustration shows an application scenario of the real-time risk monitoring method, apparatus, device, medium, and program product for bank transfers according to embodiments of this application.

[0036] like Figure 1 As shown, application scenario 100 according to this embodiment may include a transfer risk control scenario. Network 104 is used as a medium to provide a communication link between the first terminal device 101, the second terminal device 102, the third terminal device 103, and the server 105. Network 104 may include various connection types, such as wired or wireless communication links or fiber optic cables, etc.

[0037] Users can use the first terminal device 101, the second terminal device 102, and the third terminal device 103 to interact with the server 105 via the network 104 to receive or send messages, etc. Various communication client applications can be installed on the first terminal device 101, the second terminal device 102, and the third terminal device 103, such as shopping applications, web browser applications, search applications, instant messaging tools, email clients, social media platform software, etc. (for example only).

[0038] The first terminal device 101, the second terminal device 102, and the third terminal device 103 can be various electronic devices with displays and support web browsing, including but not limited to smartphones, tablets, laptops, and desktop computers.

[0039] Server 105 can be a server that provides various services, such as a backend management server that supports websites browsed by users using the first terminal device 101, the second terminal device 102, and the third terminal device 103 (this is just an example). The backend management server can analyze and process data such as received user requests, and feed back the processing results (such as web pages, information, or data obtained or generated according to user requests) to the terminal devices.

[0040] It should be noted that the real-time risk monitoring method for bank transfers provided in this application embodiment can generally be executed by server 105. Correspondingly, the real-time risk monitoring device for bank transfers provided in this application embodiment can generally be located in server 105. The real-time risk monitoring method for bank transfers provided in this application embodiment can also be executed by a server or server cluster that is different from server 105 and capable of communicating with the first terminal device 101, the second terminal device 102, the third terminal device 103, and / or server 105. Correspondingly, the real-time risk monitoring device for bank transfers provided in this application embodiment can also be located in a server or server cluster that is different from server 105 and capable of communicating with the first terminal device 101, the second terminal device 102, the third terminal device 103, and / or server 105.

[0041] It should be understood that Figure 1 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0042] The following will be based on Figure 1 The described scene, through Figures 2-5 The method for real-time risk monitoring of bank transfers according to embodiments of this application is described in detail.

[0043] Figure 2 A flowchart illustrating a real-time risk monitoring method for bank transfers according to an embodiment of this application is shown.

[0044] like Figure 2 As shown, the real-time risk monitoring method for bank transfers in this embodiment includes operations S210 to S250, which can be executed by a server or other computing device.

[0045] In operation S210, in response to a transfer transaction request, the transaction request is converted into a standardized event.

[0046] In operation S220, the standardized event is broadcast to the smart contract cluster.

[0047] According to an embodiment of this application, converting the transaction request into a standardized event includes: extracting the target field of the transaction request message, mapping the target field to generate a standard field name; querying the cache to perform real-time supplementary calculation of lightweight features, the lightweight features including the number of transactions within a preset time, the average transaction amount, and the distance between the current device and frequently used devices; and encapsulating the supplementary lightweight features and the standard field name into a standardized event.

[0048] In one example, the real-time stream processor acts as an accelerator and converter at the forefront of the entire risk control chain, continuously transforming transfer transactions into standardized event streams that the risk control engine can process and that on-chain contracts can use. Upon receiving a transfer request, the gateway first breaks down the message, extracting six key fields: payment account, receiving account, amount, device ID, IP address, and timestamp. Then, it performs standardization conversion, unifying the formats of various channels (mobile banking, online banking, third-party payment) into internal risk control standard events. This includes standardized field names, amount units, and time zones. Sensitive information is anonymized, masking ID numbers and mobile phone numbers, retaining only the hashes or tags needed for risk control. Real-time lightweight feature calculations are performed to improve the user profile of the transaction. Specifically, a table is maintained in the cache, with the key "sender + device ID". This table stores the number of transactions and cumulative amount for the last 24 hours in real time; for new transactions, the amount is directly added, the transaction count is incremented, and the average amount is calculated immediately. The straight-line distance is then calculated using the coordinates corresponding to the real-time IP address and the "frequently used coordinates" recorded in the table, yielding the distance in kilometers between the current device and frequently used devices. The entire process is completed in memory, taking less than 1 millisecond. The aligned standard fields and the supplemented lightweight features are then encapsulated into a standardized event with a fixed format and broadcast to the smart contract cluster for processing.

[0049] It should be noted that in the technical solution of this application, the user information (including but not limited to user personal information, user image information, user device information, such as location information) and data (including but not limited to data used for analysis, stored data, and displayed data) involved are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of the relevant data all comply with relevant laws, regulations, and standards, take necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation entry points for users to choose to authorize or refuse.

[0050] In scenarios involving automated decision-making using personal information, such as before supplementing user profiles using transaction messages, the methods, devices, and systems provided in this application all offer users corresponding entry points for choosing to agree to or reject the automated decision result. If the user chooses to reject, the process proceeds to the expert decision-making stage. Here, "automated decision-making" refers to the activity of automatically analyzing and evaluating an individual's behavioral habits, interests, or economic, health, and credit status through computer programs, and then making decisions. Here, "expert decision-making" refers to the activity of making decisions by personnel who specialize in a particular field, possess specialized experience, knowledge, and skills, and have reached a certain level of professional expertise.

[0051] In operation S230, the risk control decision results generated by the smart contract cluster for the standardized event are obtained.

[0052] According to an embodiment of this application, the smart contract cluster includes a scanning contract, a decision contract, and a tracking contract. The scanning contract is used to call a risk model that has been pre-trained off-chain and then hashed and fixed on-chain for on-chain reasoning. The decision contract is used to execute multi-dimensional risk rules. The tracking contract is used to track the flow of funds on-chain in real time.

[0053] In one example, standardized events are simultaneously delivered to three parallel entry points—the "Scanning Contract," the "Decision Contract," and the "Tracking Contract"—via a high-speed message bus. Upon receiving an event, the Scanning Contract immediately inputs features such as the number of transactions in the past 24 hours, average amount, and device distance into the risk model deployed on the blockchain. This model is trained offline in the backend. After training, the model file is hashed, and the hash value is written to the on-chain "Model Version Table." Only a very lightweight interpreter is maintained on-chain, completing the inference process within 5 milliseconds and outputting a risk score of 0-255. The Decision Contract simultaneously initiates multiple risk rules. These rules could include, for example, a large transaction dual authentication rule—if the amount exceeds a threshold, it checks whether two-factor authentication has been performed; a geolocation anomaly rule—if the device distance differs significantly from the usual distance, it triggers behavioral authentication; or a network association rule—it performs a two-hop lookup of the sender and receiver addresses in the shared risk graph, and if a known risk node is matched, the transaction is rejected. The three rules are executed in parallel, taking approximately 20 milliseconds in total. The final risk control decision is given based on the risk score and rule results: "allow the transaction / reject the transaction / supplement the authentication".

[0054] In operation S240, if the risk control decision result is determined to allow the transaction, a risk factor bitmap is generated based on the transaction data and the risk control decision result, and the risk factor bitmap is stored on the blockchain for evidence.

[0055] According to an embodiment of this application, the risk factor bitmap includes multiple Boolean bits, each Boolean bit corresponding to a risk factor, and the risk factor includes at least one of a large transaction indicator bit, a geographic location anomaly indicator bit, a risk address hit indicator bit, and a device anomaly indicator bit.

[0056] In one example, after determining that the risk control decision result is to approve the transaction, the system immediately enters the on-chain preparation stage. First, a risk factor bitmap is generated, which is stored as an attribute of the transaction, equivalent to a transaction snapshot. Specifically, a 128-bit empty string is used as a template; the risk control decision result is mapped to the transaction data into 8 Boolean flags, for example: 0th bit: large transaction flag (amount ≥ threshold, set to 1); 1st bit: remote device flag (distance > 500 km, set to 1); 2nd bit: gray market association flag (map hit, set to 1); 3rd bit: high frequency flag (24-hour transaction count > threshold, set to 1); the remaining 4 bits are reserved for subsequent expansion. After bit-by-bit filling, the 128-bit string is compressed into 16 bytes, which is the "risk factor bitmap". The unique transaction ID, sender hash, receiver hash, amount, timestamp, risk factor bitmap, and pre- and post-transaction state hashes are encapsulated into a "real-time transaction record". The above records are written into the block through the evidence storage contract of the consortium blockchain; the average time from call to block confirmation is less than 100 milliseconds, ensuring that funds have been released but the data cannot be tampered with and can be audited in real time.

[0057] In operation S250, the tracking contract is invoked to perform real-time on-chain tracking of fund flows, and the tracking results are broadcast to each node of the consortium chain after zero-knowledge processing to update the shared risk graph. The shared risk graph is used to provide associated risk data for the smart contract cluster.

[0058] According to an embodiment of this application, the shared risk graph is a dynamic graph database, where nodes are used to represent accounts or devices, and edges are used to represent fund or behavioral associations. Updating the shared risk graph includes updating node attributes and edge weights.

[0059] In one example, after a transaction is approved, the tracking contract completes a 10-layer scan of fund flows on-chain within 40 ms. If a suspicious node is found, sensitive fields such as address, device, and amount range are hashed into leaves and a zero-knowledge proof is generated. The root hash and proof are then broadcast to the entire network. After each node verifies, it writes the new node attributes and edge weights into the shared risk graph and completes a global update within 500 ms, providing real-time correlation data for the next round of risk control.

[0060] According to an embodiment of this application, if the risk control decision result is determined to be a transaction rejection, a risk event is generated and the risk event is broadcast to each node of the consortium blockchain to update the shared risk graph.

[0061] In one example, if the risk control decision is to reject the transaction, the system immediately sets the transaction status to rejected and stops subsequent on-chain transfers, keeping the funds in their original accounts. A risk event is generated using the transaction's unique ID, rejection reason (rule number and risk score), risk factor bitmap, and timestamp as the event body. The event format is fixed within 128 bytes for rapid broadcasting. This risk event is pushed to all nodes within 500 ms via the consortium blockchain event channel. Upon receiving the risk event, each node adds a "rejection count" attribute to the corresponding node in the shared risk graph. If the number of rejections by the same node within 24 hours is greater than or equal to a threshold, its risk level is increased, and the probability of allowing subsequent transactions is reduced. The updated node attributes and edge weights are immediately read by the scanning and decision contracts, ensuring that the next related transaction will be intercepted with higher weight in the next round of risk control, forming a closed loop of "rejection equals joint defense."

[0062] The method provided in this application involves first standardizing transaction requests and calculating lightweight features using a real-time stream processor to form "clean fuel." This standardized event is simultaneously pushed to three types of smart contracts: scanning, decision-making, and tracking. The scanning contract uses an off-chain trained and on-chain solidified model to provide a risk score. The decision-making contract combines a shared graph to verify multi-dimensional rules in parallel, outputting a pass or rejection within 50ms. Once passed, the system immediately compresses the risk control basis into a 128-bit risk factor bitmap and stores it on the blockchain for auditability. Simultaneously, the tracking contract completes a multi-hop scan of fund flows within 40ms. Upon discovering suspicious nodes, it encrypts sensitive information into a root hash and proof using zero-knowledge proof, broadcasting it across the entire network within 500ms. After verification by each node, the shared risk graph is updated immediately, allowing the next transaction to re-enter the same closed loop within 700ms using the latest intelligence. This significantly improves the efficiency of cross-institutional collaborative interception, achieving millisecond-level continuous closed loops for data cleaning, parallel risk control, on-chain traceability, and anonymous joint defense.

[0063] Figure 3 A flowchart illustrating a method for generating risk control decision results for the standardized event using a smart contract cluster according to an embodiment of this application is shown. Figure 3 As shown, this includes operations S310 to S330.

[0064] In operation S310, the risk model on the scanning contract is invoked to perform on-chain inference to generate a risk score. The risk model is pre-trained off-chain and then hashed and fixed on-chain.

[0065] In one example, the risk model in this application adopts a two-layer architecture of "off-chain training and on-chain inference". During the off-chain training phase, a GPU cluster is used to train the model on anonymized transaction data, device fingerprints, IP geolocation, and blacklist tags from a pre-defined time period, producing a compact gradient boosting tree model. After training, the bank performs a SHA-256 hash on the model file and writes the hash value into the consortium blockchain's "model version table" as an immutable version fingerprint. During the on-chain phase, each node deploys only one lightweight interpreter. When the scanning contract receives real-time lightweight features, the interpreter completes tree traversal within 5 milliseconds and outputs a risk score of 0-255. Simultaneously, it compares the hash of the model used with the latest hash on the chain in real time, ensuring that the inference result always comes from the latest, tamper-proof model. If an upgrade is needed, only off-chain retraining and hash updates are required, without downtime or contract redeployment.

[0066] In operation S320, the shared risk graph interface is invoked according to the multidimensional risk rules of the decision contract to generate risk judgment results.

[0067] In operation S330, a risk control decision result is generated based on the risk score and / or the risk assessment result.

[0068] According to an embodiment of this application, a maximum execution time limit is set for contract calls in the smart contract cluster; if any contract call takes longer than the maximum execution time limit, the current transaction status is set to timed-out transaction; and the timed-out transaction is transferred to a manual review queue.

[0069] In one example, the system sets a maximum execution time limit (e.g., 50ms) for scanning contracts, decision contracts, and tracking contracts upon startup. This value is written to the on-chain configuration table and takes effect after all nodes load it. Whenever a standardized event arrives at the smart contract cluster, the gateway starts a high-precision timer for each contract call within the same millisecond. The timer runs in parallel with the contract logic. If any contract call takes longer than the maximum execution time limit, the current transaction status is set to a timed-out transaction; the timed-out transaction is then transferred to a manual review queue. Decision contracts call the shared risk graph interface and multi-dimensional risk rules in parallel. If any rule or interface call is completed within 20ms, the results are summarized; if the cumulative time reaches 50ms, the remaining rules are immediately terminated, and a "decision timeout" flag is recorded. The gateway collects contract return or timeout signals. If all returns are normal, it generates transaction approval, transaction rejection, or supplementary authentication based on weighted logic; if any contract times out, the current transaction is directly marked as a "timed-out transaction," and the transaction is suspended until manual review. Overdue transactions, along with some calculated results (risk score incomplete, matched rule number, and overdue log), are packaged into a pending review record and written to the "manual review queue." The queue uses a first-in, first-out strategy. Back-end risk control personnel can see the transaction in a graphical interface and can add information or manually decide whether to approve or reject it.

[0070] Figure 4 A flowchart illustrating a method for performing zero-knowledge processing on tracking results according to an embodiment of this application is shown schematically. Figure 4 As shown, this includes operations S410 to S440.

[0071] In operation S410, irreversible hash operations are performed on the account address, device identifier, geographical location, and amount range in the tracking results to generate multiple hash leaves.

[0072] In operation S420, the multiple hash leaves are constructed into a hash tree to obtain the root hash.

[0073] In operation S430, using zero-knowledge circuitry, the root hash and a preset set of risky addresses are used as public inputs, and the tracking results are used as private witnesses to generate zero-knowledge proofs.

[0074] In operation S440, the zero-knowledge proof and the root hash are broadcast as anonymization events to each node of the consortium blockchain to update the shared risk graph.

[0075] In one example, after a transaction is approved and uploaded to the blockchain, the tracking contract immediately obtains the transaction hash and amount information. It then recursively queries the flow of funds on the chain, tracking a preset depth, such as 10 hops. Each hop records only the target address, amount range, and time difference, completing the entire process in 30-40 milliseconds. If any address is found to match a preset risk node, mixing node, or blacklist node, the path is marked as "suspicious," and key nodes and edge information along the entire path are extracted. An irreversible hash is performed on the account address, device identifier, geographical location, and amount range in the path, resulting in multiple 32-byte hash leaves. These leaves are then constructed into a Merkle tree to obtain a 32-byte root hash. Using the root hash and a preset set of risk addresses as public input, and the original path as private witness, a zero-knowledge proof of approximately 256 bytes is generated. The root hash, risk type identifier, and zero-knowledge proof are packaged into an "anonymous risk event" and synchronized to all nodes within 500 milliseconds via a consortium blockchain protocol. After each node passes the zero-knowledge proof verification, the node's (account / device) attributes (risk score, latest hit time) are inserted or updated in the dynamic graph database; edge weights (number of fund transfers, total amount) are inserted or accumulated; and the graph algorithm is triggered to recalculate the node's risk score, so that the shared risk graph is always up-to-date, providing real-time associated risk data for the next round of transactions.

[0076] Based on the aforementioned real-time risk monitoring method for bank transfers, this application also provides a real-time risk monitoring device for bank transfers. The following will combine... Figure 5 The device is described in detail.

[0077] Figure 5 A schematic diagram of a real-time risk monitoring device for bank transfers according to an embodiment of this application is shown.

[0078] like Figure 5 As shown, the real-time risk monitoring device 500 for bank transfers in this embodiment includes a conversion module 510, a first broadcast module 520, a risk control decision result acquisition module 530, an evidence storage module 540, and a tracking module 550.

[0079] The conversion module 510 is used to convert a transfer transaction request into a standardized event in response to the request. In one embodiment, the conversion module 510 may be used to perform the operation S210 described above, which will not be repeated here.

[0080] The first broadcast module 520 is used to broadcast the standardized event to the smart contract cluster. In one embodiment, the first broadcast module 520 can be used to perform the operation S220 described above, which will not be repeated here.

[0081] The risk control decision result acquisition module 530 is used to acquire the risk control decision result generated by the smart contract cluster for the standardized event. In one embodiment, the risk control decision result acquisition module 530 can be used to execute the operation S230 described above, which will not be repeated here.

[0082] The evidence storage module 540 is used to generate a risk factor bitmap based on the transaction data and the risk control decision result if the risk control decision result is determined to allow the transaction, and then store the risk factor bitmap on the blockchain for evidence storage. In one embodiment, the evidence storage module 540 can be used to perform the operation S240 described above, which will not be repeated here.

[0083] The tracking module 550 is used to invoke the tracking contract to perform real-time on-chain tracking of fund flows, and broadcasts the tracking results to each node of the consortium blockchain after zero-knowledge processing to update the shared risk graph. The shared risk graph provides associated risk data to the smart contract cluster, which includes a scanning contract, a decision contract, and a tracking contract. The scanning contract invokes a risk model pre-trained off-chain and hashed and fixed on-chain for on-chain inference. The decision contract executes multi-dimensional risk rules, and the tracking contract performs real-time on-chain tracking of fund flows. In one embodiment, the tracking module 550 can be used to execute the operation S250 described above, which will not be repeated here.

[0084] According to an embodiment of this application, the apparatus further includes a second broadcast module.

[0085] The second broadcast module is used to generate a risk event and broadcast the risk event to each node of the consortium blockchain if the risk control decision result is determined to be a transaction rejection, so as to update the shared risk graph.

[0086] According to embodiments of this application, a risk control decision generation module is also included.

[0087] The risk control decision module generates a risk score by calling the risk model on the scanning contract for on-chain reasoning. The risk model is pre-trained off-chain and then hashed and fixed on-chain. The module calls the shared risk graph interface according to the multi-dimensional risk rules of the decision contract to generate a risk judgment result. The module also generates a risk control decision result based on the risk score and / or the risk judgment result.

[0088] According to embodiments of this application, the conversion module includes an extraction submodule, a feature compensation submodule, and an encapsulation submodule.

[0089] The extraction submodule is used to extract the target fields of the transaction request message and map the target fields to generate standard field names; the feature supplementation submodule is used to query the cache to perform real-time supplementation of lightweight features, including the number of transactions within a preset time, the average transaction amount, and the distance between the current device and commonly used devices; and the encapsulation submodule is used to encapsulate the supplemented lightweight features and the standard field names into standardized events.

[0090] According to an embodiment of this application, the tracking module is further configured to perform irreversible hash operations on the account address, device identifier, geographical location, and amount range in the tracking results to generate multiple hash leaves; construct the multiple hash leaves into a hash tree to obtain the root hash; use zero-knowledge circuits, with the root hash and a preset set of risk addresses as public inputs and the tracking results as private witnesses, to generate a zero-knowledge proof; and broadcast the zero-knowledge proof and the root hash as an anonymization event to each node of the consortium blockchain to update the shared risk graph.

[0091] According to embodiments of this application, any multiple modules among the conversion module 510, the first broadcast module 520, the risk control decision result acquisition module 530, the evidence storage module 540, and the tracking module 550 can be combined into one module, or any one of these modules can be split into multiple modules. Alternatively, at least some of the functions of one or more of these modules can be combined with at least some of the functions of other modules and implemented in one module. According to embodiments of this application, at least one of the conversion module 510, the first broadcast module 520, the risk control decision result acquisition module 530, the evidence storage module 540, and the tracking module 550 can be at least partially implemented as hardware circuitry, such as a field-programmable gate array (FPGA), a programmable logic array (PLA), a system-on-a-chip, a system-on-a-substrate, a system-on-package, an application-specific integrated circuit (ASIC), or any other reasonable means of integrating or packaging the circuitry, or implemented in software, hardware, or firmware, or in any suitable combination of any of these three implementation methods. Alternatively, at least one of the conversion module 510, the first broadcast module 520, the risk control decision result acquisition module 530, the evidence storage module 540, and the tracking module 550 can be at least partially implemented as a computer program module, which can perform corresponding functions when the computer program module is run.

[0092] Figure 6 A block diagram schematically illustrates an electronic device suitable for implementing a real-time risk monitoring method for bank transfers according to an embodiment of this application.

[0093] like Figure 6As shown, an electronic device 600 according to an embodiment of this application includes a processor 601, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 602 or a program loaded from a storage portion 608 into a random access memory (RAM) 603. The processor 601 may include, for example, a general-purpose microprocessor (e.g., a CPU), an instruction set processor and / or an associated chipset and / or a special-purpose microprocessor (e.g., an application-specific integrated circuit (ASIC)), etc. The processor 601 may also include onboard memory for caching purposes. The processor 601 may include a single processing unit or multiple processing units for performing different actions of the method flow according to an embodiment of this application.

[0094] RAM 603 stores various programs and data required for the operation of electronic device 600. Processor 601, ROM 602, and RAM 603 are interconnected via bus 604. Processor 601 executes various operations of the method flow according to embodiments of this application by executing programs in ROM 602 and / or RAM 603. It should be noted that the programs may also be stored in one or more memories other than ROM 602 and RAM 603. Processor 601 may also execute various operations of the method flow according to embodiments of this application by executing programs stored in said one or more memories.

[0095] According to embodiments of this application, the electronic device 600 may further include an input / output (I / O) interface 605, which is also connected to a bus 604. The electronic device 600 may also include one or more of the following components connected to the input / output (I / O) interface 605: an input section 606 including a keyboard, mouse, etc.; an output section 607 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 608 including a hard disk, etc.; and a communication section 609 including a network interface card such as a LAN card, modem, etc. The communication section 609 performs communication processing via a network such as the Internet. A drive 99 is also connected to the input / output (I / O) interface 605 as needed. A removable medium 611, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 99 as needed so that computer programs read from it can be installed into the storage section 608 as needed.

[0096] This application also provides a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiments; or it may exist independently and not assembled into the device / apparatus / system. The computer-readable storage medium carries one or more programs, which, when executed, implement the method according to the embodiments of this application.

[0097] According to embodiments of this application, the computer-readable storage medium can be a non-volatile computer-readable storage medium, such as including but not limited to: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this application, the computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. For example, according to embodiments of this application, the computer-readable storage medium may include ROM 602 and / or RAM 603 and / or one or more memories other than ROM 602 and RAM 603 described above.

[0098] Embodiments of this application also include a computer program product comprising a computer program containing program code for performing the methods shown in the flowchart. When the computer program product is run on a computer system, the program code enables the computer system to implement the real-time risk monitoring method for bank transfers provided in the embodiments of this application.

[0099] When the computer program is executed by the processor 601, it performs the functions defined in the system / apparatus of this application embodiment. According to the embodiments of this application, the systems, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0100] In one embodiment, the computer program may rely on a tangible storage medium such as an optical storage device or a magnetic storage device. In another embodiment, the computer program may also be transmitted and distributed in the form of signals over a network medium, and downloaded and installed via the communication section 609, and / or installed from the removable medium 611. The program code contained in the computer program can be transmitted using any suitable network medium, including but not limited to: wireless, wired, etc., or any suitable combination thereof.

[0101] In such an embodiment, the computer program can be downloaded and installed from a network via the communication section 609, and / or installed from the removable medium 611. When the computer program is executed by the processor 601, it performs the functions defined in the system of this application embodiment. According to the embodiments of this application, the systems, devices, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0102] According to embodiments of this application, program code for executing the computer programs provided in the embodiments of this application can be written in any combination of one or more programming languages. Specifically, these computational programs can be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. Programming languages ​​include, but are not limited to, languages ​​such as Java, C++, Python, "C", or similar programming languages. The program code can be executed entirely on the user's computing device, partially on the user's device, partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0103] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0104] Those skilled in the art will understand that the features described in the various embodiments of this application can be combined and / or combined in various ways, even if such combinations or combinations are not explicitly described in this application. In particular, the features described in the various embodiments of this application can be combined and / or combined in various ways without departing from the spirit and teachings of this application. All such combinations and / or combinations fall within the scope of this application.

Claims

1. A method for real-time risk monitoring of bank transfers, characterized in that, include: In response to a transfer transaction request, the transaction request is converted into a standardized event; Broadcast the standardized events to the smart contract cluster; Obtain the risk control decision results generated by the smart contract cluster in response to the standardized event; If the risk control decision result is determined to allow the transaction, a risk factor bitmap is generated based on the transaction data and the risk control decision result, and the risk factor bitmap is stored on the blockchain for evidence. The tracking contract is invoked to perform real-time on-chain tracking of fund flows, and the tracking results are broadcast to each node of the consortium blockchain after zero-knowledge processing to update the shared risk graph. The shared risk graph is used to provide associated risk data for the smart contract cluster. The smart contract cluster includes a scanning contract, a decision contract, and a tracking contract. The scanning contract is used to call a risk model that has been pre-trained off-chain and then hashed and fixed on-chain for on-chain reasoning. The decision contract is used to execute multi-dimensional risk rules. The tracking contract is used to track the flow of funds on-chain in real time.

2. The method according to claim 1, characterized in that, The method further includes: If the risk control decision result is determined to be a transaction rejection, a risk event is generated and broadcast to all nodes of the consortium blockchain to update the shared risk graph.

3. The method according to claim 1, characterized in that, The smart contract cluster generates risk control decision results for the standardized events, including: The risk model on the scanning contract is invoked to perform on-chain inference to generate a risk score. The risk model is pre-trained off-chain and then hashed and fixed on-chain. The shared risk graph interface is invoked according to the multi-dimensional risk rules of the decision contract to generate a risk assessment result; and Risk control decision results are generated based on the risk score and / or the risk assessment results.

4. The method according to claim 1, characterized in that, The step of converting the transaction request into a standardized event includes: Extract the target fields from the transaction request message, and map the target fields to generate standard field names; The query cache performs real-time supplementary calculations of lightweight features, including the number of transactions within a preset time period, the average transaction amount, and the distance between the current device and frequently used devices; and The lightweight features of the supplementary calculation and the standard field names are encapsulated into standardized events.

5. The method according to claim 1, characterized in that, After performing zero-knowledge processing on the tracking results, they are broadcast to all nodes of the consortium blockchain to update the shared risk graph, including: Irreversible hash operations are performed on the account address, device identifier, geographical location, and amount range in the tracking results to generate multiple hash leaves; Construct a hash tree from the multiple hash leaves to obtain the root hash; Using zero-knowledge circuits, with the root hash and a preset set of risky addresses as public inputs, and the tracking results as private witnesses, a zero-knowledge proof is generated; and The zero-knowledge proof and the root hash are broadcast as anonymization events to all nodes of the consortium blockchain to update the shared risk graph.

6. The method according to any one of claims 1 to 5, characterized in that, The shared risk graph is a dynamic graph database, where nodes represent accounts or devices and edges represent fund or behavioral associations. Updating the shared risk graph includes updating node attributes and edge weights.

7. The method according to claim 6, characterized in that, The risk factor bitmap includes multiple Boolean bits, each of which corresponds to a risk factor. The risk factor includes at least one of the following: large transaction indicator bit, abnormal geographical location indicator bit, risk address hit indicator bit, and device abnormality indicator bit.

8. The method according to claim 6, characterized in that, The method further includes: Set a maximum execution time limit for contract calls in the smart contract cluster; If any contract call takes longer than the maximum execution time limit, the current transaction status will be set to timeout transaction; The timed-out transactions will be transferred to the manual review queue.

9. A real-time risk monitoring device for bank transfers, characterized in that, The device includes: The conversion module is used to convert a transfer transaction request into a standardized event in response to the transaction request. The first broadcast module is used to broadcast the standardized events to the smart contract cluster; The risk control decision result acquisition module is used to acquire the risk control decision results generated by the smart contract cluster in response to the standardized event; The evidence storage module is used to generate a risk factor bitmap based on the transaction data and the risk control decision result if the risk control decision result is determined to allow the transaction, and to store the risk factor bitmap on the blockchain for evidence storage. The tracking module is used to call the tracking contract to track the flow of funds on the blockchain in real time, and to broadcast the tracking results to each node of the consortium blockchain after zero-knowledge processing, so as to update the shared risk graph. The shared risk graph is used to provide associated risk data for the smart contract cluster. The smart contract cluster includes a scanning contract, a decision contract, and a tracking contract. The scanning contract is used to call a risk model that has been pre-trained off-chain and then hashed and fixed on-chain for on-chain reasoning. The decision contract is used to execute multi-dimensional risk rules. The tracking contract is used to track the flow of funds on-chain in real time.

10. An electronic device, comprising: One or more processors; Memory, used to store one or more computer programs. The characteristic feature is that the one or more processors execute the one or more computer programs to implement the steps of the method according to any one of claims 1 to 8.

11. A computer-readable storage medium having a computer program or instructions stored thereon, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 8.

12. A computer program product, comprising a computer program or instructions, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 8.

Images