Cross-border payment dynamic risk control system and method

Abstract

The invention provides a cross-border payment dynamic risk control system and method, and the method comprises the steps: defining an access point for each flow node of cross-border payment dynamic risk control through a data access layer, so as to access transaction data, configuring a corresponding basic object model through a basic data layer, configuring a decision rule through a decision engine layer based on the model, and completing the cross-border payment dynamic risk control. And when the conditions are met, executing actions to obtain decision results and feeding back the decision results to the transaction system. According to the invention, the transaction system is endowed with risk judgment and event handling capabilities through the access point series service data and logic, has a real-time response characteristic, can adapt to diversified transaction scenes of the cross-border financial market, and realizes continuous mining of major risk events. Quick butt joint of an external data source and a service interface is supported, and decision data support is enhanced; fine classification of cross-border payment businesses is realized by means of a machine learning technology, a rule is dynamically adjusted based on real-time data and transaction behaviors, a traditional fixed threshold mode is abandoned, data change is matched through an adaptive rule, and risk control accuracy and flexibility are remarkably improved.

Description

Technical Field

[0001] The present invention relates to the field of cross-border payment security technology, and in particular to a cross-border payment dynamic risk control system and method. Background Art

[0002] In the cross-border payment sector, dynamic risk control is a core component of ensuring transaction security. Traditional cross-border payment risk control systems face significant real-time bottlenecks. They generally employ a T+1 offline risk control batch processing model and rely on post-audits. This fundamentally conflicts with the time-sensitive nature of cross-border payments, such as cryptocurrency transactions and real-time settlements in cross-border e-commerce, leading to significant delays in risk response.

[0003] Traditional cross-border payment risk control systems struggle to flexibly respond to the diverse transaction scenarios in cross-border financial markets. Their rigid business logic and data processing models make it difficult to quickly adjust risk control strategies based on regulatory requirements, transaction types (such as B2B, B2C, C2C, etc.), and currency settlement rules in different countries or regions, making it highly susceptible to missed or misjudgment of risks in specific scenarios. Furthermore, the system's identification of business types is relatively crude, mixing the same risk control strategies for businesses with vastly different risk levels, such as cross-border e-commerce, student study abroad fees, and ODI investments. For example, a single $100,000 semiconductor import payment and tour group fees would be subject to the same review process, making it difficult to achieve refined risk control management.

[0004] Traditional cross-border payment risk control systems lack a continuous, dynamic analysis mechanism for major risk events. They can only perform static rule matching based on historical data, making it difficult to proactively identify new fraud patterns or systemic risks. This results in inadequate and inaccurate risk warnings. Furthermore, static rule engines rely on a rule base with fixed thresholds (e.g., a single transaction exceeding $50,000 triggers manual review), making them unable to adapt to evolving fraud methods. This leads to a high rate of false positives and makes it difficult to meet the precise risk identification requirements of cross-border payment services. Summary of the Invention

[0005] In view of the shortcomings of the existing technology mentioned above, the purpose of the present invention is to provide a cross-border payment dynamic risk control system and method to solve the technical problems of traditional cross-border payment risk control systems such as insufficient real-time performance, poor scenario adaptability and delayed risk mining.

[0006] To achieve the above-mentioned and other related objectives, the present invention provides a cross-border payment dynamic risk control system, comprising: an infrastructure layer, a data access layer, a basic data layer, a decision engine layer, a decision application layer, and a system management layer. The infrastructure layer is used to store system-related data; the data access layer is used to define access points for each process node in the transaction system requiring cross-border payment dynamic risk control, and access transaction data through the defined access points; the basic data layer is used to configure the basic object model corresponding to the transaction data at each access point; the decision engine layer is used to configure decision rules based on the basic object model of each access point, and when the accessed transaction data meets the conditions of the corresponding decision rule, execute the corresponding risk control linkage action to obtain a decision result, which is then fed back to the transaction system via the data access layer; the decision application layer is used to perform secondary packaging based on the basic functions of the decision engine layer and the basic data layer; and the system management layer is used to perform basic system management.

[0007] In one embodiment of the present invention, the infrastructure layer includes: Mongo DB, which is used to store all data of system applications; Redis cluster, which is used to store indicator data and temporarily cache related data; Kafka, which is used for message caching during real-time indicator processing.

[0008] In one embodiment of the present invention, the data access layer includes: a data import module for importing external data into MongoDB for storage; an external interface management module for receiving external data from a third-party system using an external data service interface; an external library management module for receiving external data from an external business database; an access point management module for defining each access point defined by each process node of risk control and communicating with the trading system through each access point; and an access point statistics module for collecting statistics on data usage at each access point.

[0009] In one embodiment of the present invention, the basic data layer includes: a variable library management module, which is used to configure variables for each access point; a constant library management module, which is used to define all constants under each variable; an action library management module, which is used to define various risk control linkage disposal actions used for transaction data processing of each access point; a list library management module, which is used to define the blacklist and whitelist of each access point; and an indicator library management module, which is used to receive real-time transaction data transmitted through Kafka, calculate the indicator data of each access point, and store the indicator data in a Redis cluster.

[0010] In one embodiment of the present invention, the indicator library management module performs time series behavior analysis on the real-time transaction data through a sliding window to obtain traffic indicator data within any time period.

[0011] In one embodiment of the present invention, the decision engine layer includes: a decision rule management module, a calculation expression management module, a decision condition management module, a rule parser, a condition parser management module, a rule engine, and an expression evaluation engine; wherein the decision rule management module is used to create decision rules for each access point based on the basic object model configured by the basic data layer; the calculation expression management module is used to define the calculation expressions used by the decision rules; the decision condition management module is used to define the conditions used by the decision rules; the rule parser is used to parse the decision rules and send the parsing results to the condition parser to parse the various conditions of the decision rules and their relationships; it is also used to generate rule scripts and expression evaluation scripts based on the condition parsing results parsed by the condition parser, and send them to the rule engine and expression evaluation engine respectively, so that when the received transaction data meets the conditions of the decision rules, the rule engine and expression evaluation engine execute corresponding risk control linkage disposal actions to obtain decision results; the secondary packaging module is used to secondary package the decision rules.

[0012] In one embodiment of the present invention, the secondary encapsulation module includes: a decision table management module, which is used to encapsulate decision rules into rules with the function of generating a decision table; a scorecard management module, which is used to encapsulate decision rules into rules with the function of generating a scorecard; a decision tree management module, which is used to encapsulate decision rules into rules with the function of generating a decision tree; and a decision flow management module, which is used to encapsulate decision rules into rules with the function of generating a decision flow.

[0013] In one embodiment of the present invention, the decision application layer includes: a merchant rating management module, which is used to rate merchants based on scorecard rules and merchant information; a visualization rule module, which is used to configure the conditions and calculation expressions of each decision rule in the operation interface; a merchant rule threshold module, which is used to set the rule threshold of each merchant to configure the decision rules of different merchants; a quota management center, which is used to set the transaction quota of each access point; a data query engine, which is used to query business data; a big data center, which is used to manage business data; a blacklist and whitelist management module, which is used to manage the blacklist and whitelist of each access point; a rule backtesting optimization center, which is used to backtest the decision rules using historical data and optimize the decision rules based on the backtesting results; and a workflow engine, which is used to manage business processes.

[0014] In one embodiment of the present invention, the system management layer includes: a user management module for managing system users; a function menu management module for creating function menus at all levels; an authorization group management module for creating different authorization groups to batch manage users with the same permissions; a menu authorization management module for allocating permissions for function menus to users and authorization groups; a data authorization management module for allocating data permissions to users and authorization groups; and a scheduled task module for creating various scheduled tasks.

[0015] To achieve the above-mentioned purpose and other related purposes, the present invention provides a cross-border payment dynamic risk control method, which is applied to the cross-border payment dynamic risk control system. The method includes: defining access points for each process node of the transaction system that needs to perform cross-border payment dynamic risk control through the data access layer; configuring the basic object model corresponding to the transaction data of each access point through the basic data layer; configuring decision rules based on the basic object model of each access point by the decision engine layer; accessing the transaction data of the transaction system through the access point of the data access layer, and when the conditions of the corresponding decision rule are met, the decision engine layer executes the corresponding risk control linkage disposal action to obtain a decision result; and feeding back the decision result to the transaction system through the data access layer.

[0016] As described above, the present invention is a cross-border payment dynamic risk control system and method, which has the following beneficial effects: the present invention defines access points for each process node of the cross-border payment dynamic risk control through the data access layer to access transaction data, the basic data layer configures the corresponding basic object model, and the decision engine layer configures the decision rules based on the model. When the conditions are met, the action is executed to obtain the decision result and feedback is given to the transaction system. The present invention connects business data and logic in series through the access point, giving the transaction system the risk judgment and event handling capabilities, with real-time response characteristics, can adapt to the diversified transaction scenarios of the cross-border financial market, and realize the continuous mining of major risk events. It also supports quick docking of external data sources and service interfaces to strengthen decision-making data support; with the help of machine learning technology, it realizes the refined classification of cross-border payment business, and dynamically adjusts the rules based on real-time data and transaction behavior, abandoning the traditional fixed threshold model, matching data changes through adaptive rules, and significantly improving the accuracy and flexibility of risk control. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Figure 1 Shown is a structural diagram of a cross-border payment dynamic risk control system in one embodiment of the present invention.

[0018] Figure 2 Shown is a structural diagram of a cross-border payment dynamic risk control system in one embodiment of the present invention.

[0019] Figure 3Shown is a flow chart of a cross-border payment dynamic risk control method in one embodiment of the present invention.

[0020] Figure 4 Shown is a schematic structural diagram of an electronic terminal in an embodiment of the present invention. DETAILED DESCRIPTION

[0021] The following describes the embodiments of the present invention through specific examples. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments. The details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of the present invention. It should be noted that the following embodiments and features in the embodiments can be combined with each other unless they conflict.

[0022] It should be noted that in the following description, reference is made to the accompanying drawings, which describe several embodiments of the present invention. It should be understood that other embodiments may be used and that structural changes may be made without departing from the spirit and scope of the present invention. The following detailed description should not be considered limiting, and the scope of the embodiments of the present invention is limited only by the claims of the issued patents. The terminology used herein is for the purpose of describing specific embodiments only and is not intended to limit the present invention.

[0023] Throughout this specification, when a part is said to be "connected" to another part, this includes not only "direct connection" but also "indirect connection" with other elements interposed therebetween. Furthermore, when a part is said to "include" a certain component, unless otherwise stated, this does not exclude the other component but rather implies that the other component may be included.

[0024] The terms "first," "second," and "third" are used to describe various parts, components, regions, layers, and / or segments, but are not intended to be limiting. These terms are used solely to distinguish one part, component, region, layer, or segment from another. Therefore, a reference to a first part, component, region, layer, or segment below may also refer to a second part, component, region, layer, or segment without departing from the scope of the present invention.

[0025] Furthermore, as used herein, the singular forms "a", "an", and "the" are intended to include the plural forms as well, unless the context indicates otherwise. It should be further understood that the terms "comprise", "include" indicate the presence of the described features, operations, elements, components, items, kinds, and / or groups, but do not exclude the presence, occurrence, or addition of one or more other features, operations, elements, components, items, kinds, and / or groups. The terms "or" and "and / or" used herein are interpreted as inclusive, or mean any one or any combination. Thus, "A, B, or C" or "A, B, and / or C" means "any of the following: A; B; C; A and B; A and C; B and C; A, B, and C". Exceptions to this definition occur only when the combination of elements, functions, or operations is inherently mutually exclusive in some way.

[0026] The present invention provides a cross-border payment dynamic risk control system, which defines access points for each process node of the cross-border payment dynamic risk control through the data access layer to access transaction data, configures the corresponding basic object model by the basic data layer, and configures the decision engine layer based on the model to configure the decision rules. When the conditions are met, the action is executed to obtain the decision result and feedback to the transaction system. The present invention connects the business data and logic in series through the access point, giving the transaction system the risk judgment and event handling capabilities, with real-time response characteristics, can adapt to the diversified transaction scenarios of the cross-border financial market, and realize the continuous mining of major risk events. The system supports quick docking of external data sources and service interfaces to strengthen decision-making data support; with the help of machine learning technology, it realizes the refined classification of cross-border payment business, and dynamically adjusts the rules based on real-time data and transaction behavior, abandoning the traditional fixed threshold mode, matching data changes through adaptive rules, and significantly improving the accuracy and flexibility of risk control.

[0027] The following is a detailed description of the embodiments of the present invention with reference to the accompanying drawings so that those skilled in the art can easily implement the present invention. The present invention can be embodied in many different forms and is not limited to the embodiments described herein.

[0028] like Figure 1 A schematic structural diagram of a cross-border payment dynamic risk control system in an embodiment of the present invention is shown.

[0029] The system includes: an infrastructure layer 1, a data access layer 2, a basic data layer 3, a decision engine layer 4, a decision application layer 5 and a system management layer 6;

[0030] The infrastructure layer 1 serves as the data storage base of the system and is responsible for storing various static data and dynamic data required for the operation of the system.

[0031] The data access layer 2 is used to define access points for each process node of the transaction system that requires dynamic risk control of cross-border payments, and access transaction data through the defined access points;

[0032] The basic data layer 3 is in communication with the infrastructure layer 1 and the data access layer 2 and is used to configure a basic object model corresponding to the transaction data of each access point.

[0033] The decision engine layer 4 is in communication with the basic data layer 3 and the data access layer 2, and is used to configure decision rules based on the basic object model of each access point, and execute corresponding risk control linkage disposal actions to obtain decision results when the transaction data accessed by the corresponding access point meets the conditions of the corresponding decision rules, and then feed back to the trading system through the data access layer;

[0034] The decision application layer 5 is in communication with the basic data layer 3 and the decision engine layer 4, and is used for secondary packaging based on the basic functions of the decision engine layer and the basic data layer;

[0035] The system management layer 6 is used to perform basic management of the system.

[0036] Risk control personnel define access points at the process nodes in the trading system that require risk control through the data access layer 2, and then configure the basic object model corresponding to the business data at each access point through the basic data layer 3. After the object model configuration is completed, the risk control decision rules are configured based on the model through the decision engine layer 4. After all risk control rules are configured, these rules can be bound to the defined access points. The trading system calls the access point and passes in the transaction data. The risk control system maps the transaction data to the basic object model. When the accessed transaction data meets specific conditions, the decision engine layer 4 performs the corresponding business logic processing, and finally generates a decision result and returns it to the trading system through the data access layer 2. This system connects business data and logic through access points, giving the trading system the ability to adjudicate risks and handle events.

[0037] In one embodiment, the cross-border payment dynamic risk control system utilizes stream processing frameworks such as Apache Flink and KafkaStreams to achieve millisecond-level event response. After transaction data enters the system from an access point, KafkaStreams efficiently captures and performs preliminary processing, converting and transmitting the data format. The data is then rapidly transferred to Apache Flink, leveraging its low-latency stream processing capabilities to enable real-time analysis and risk assessment. Once the data meets pre-set risk control rules, Flink immediately triggers risk control actions and feeds the results back to the transaction system. The entire process is completed within milliseconds, significantly improving the timeliness and accuracy of risk control decisions. This architecture not only supports stable operation at high throughput, but also ensures system reliability through Flink's fault tolerance and Kafka Streams' high availability, ensuring continued operation even in the event of partial node failures. Furthermore, the system offers high flexibility, enabling it to flexibly address complex business needs and providing robust and reliable risk management support for cross-border payment services.

[0038] In one embodiment, if Figure 2 , the infrastructure layer 1 includes:

[0039] MongoDB is a non-relational database based on distributed file storage, developed in C++, and designed to provide a scalable, high-performance data storage solution for web applications. Its flexible document model, high scalability, and powerful query capabilities have made it a leading tool for processing unstructured data. MongoDB is used to store all data in system applications, such as business entity data (such as user information, transaction records, and risk control rules) and historical data.

[0040] Redis Cluster is a distributed solution for the Redis database, designed to address single-node memory limitations, high-concurrency access bottlenecks, and single points of failure. By sharding data across multiple nodes, it enables horizontal scalability, high availability, and automatic failover. It is suitable for scenarios requiring massive data volumes and high concurrent requests (such as caching, real-time statistics, and leaderboards). Redis Cluster is used to store metrics and temporarily cache related data.

[0041] Kafka, a distributed stream processing platform developed by Apache, was originally used to process log data and has now become the de facto standard for real-time data pipelines and stream processing. Its core advantages include high throughput, scalability, data persistence, and cross-platform compatibility. It is widely used in scenarios such as log collection, real-time monitoring, user behavior analysis, and real-time financial transaction processing. Kafka is used for transaction data access and message caching for real-time metrics processing.

[0042] The infrastructure layer 1 of the present invention uses Mongo DB, Redis cluster and Kafka to store the relevant data of this system, which has special advantages: MongoDB is responsible for low-frequency, large-capacity data storage and query. Redis is responsible for high-frequency, small-volume real-time access (such as indicator verification during rule execution), avoiding MongoDB's performance degradation due to high-concurrency queries. Kafka, as an asynchronous message middleware, decouples the transaction system and the risk control system to ensure that data is not lost, so that the basic data layer 1 can calmly handle backlog messages and avoid system crashes due to sudden traffic. When adding a new indicator type, it is only necessary to add calculation logic to the basic data layer 3 without modifying the MongoDB table structure. The infrastructure layer 1 provides underlying support for the real-time, accuracy and stability of the cross-border payment dynamic risk control system.

[0043] In one embodiment, if Figure 2 , the data access layer 2 includes:

[0044] The data import module is used to import external data into Mongo DB for storage; specifically, the external data is imported into the data table of the corresponding variable Schema in Mongo DB using a predefined basic object model (Schema).

[0045] The external interface management module is used to define and manage the external data service interface for third-party systems to access the risk control system, receive external data from third-party systems through standardized interface protocols, and ensure the standardization and consistency of data interaction.

[0046] The external database management module is used to synchronize data from external business databases to the risk control system in real time or on a scheduled basis.

[0047] The access point management module is used to define standardized access points for each process node in cross-border payment risk control, serving as an interface for communication with the transaction system. Each access point communicates with the transaction system using a predefined basic object model (Schema); access points include transaction initiation, funds verification, compliance review, transaction execution, and post-transaction process nodes. The access point management module defines standardized access points for all nodes in the cross-border payment risk control process, adapting to the diverse transaction scenarios in cross-border financial markets and resolving data format mismatches and confusing interaction logic between transaction and risk control systems. It unifies data interaction standards and business logic interaction processes, enabling more efficient system collaboration. By defining standardized access points for each process node in cross-border payment risk control, the system can flexibly configure corresponding risk control rules and business logic based on different transaction types, business scenarios, and regulatory requirements.

[0048] The access point statistics module is used to collect statistics on data usage at each access point. Specifically, it monitors data flow, call frequency, error rate, and other indicators of each access point in real time, generates statistical reports and trend analysis, and assists in system optimization and problem location. For example, it can measure the number of calls per transaction.

[0049] The data import module, external interface management module, and external library management module in the data access layer 2 cover multiple data sources, achieving flexibility and compatibility in data access. The access point management module defines unified access standards for each risk control process node, reducing the cost of connecting the trading system with the risk control system.

[0050] In one embodiment, if Figure 2 The basic data layer 3 configures the basic object model (Schema) corresponding to the transaction data of each access point, including:

[0051] The variable library management module is used to configure variables for each access point. Variables are fundamental elements in constructing the basic object model of transaction data and represent various transaction attributes, such as the merchant, user, gender, income, credit score, transaction amount, time, and location, and the device's IP address and type. These attributes reflect the characteristics and status of the transaction, providing data support for subsequent risk assessment and decision-making. The required variables vary at different access points for cross-border payments. For example, at the "transaction initiation access point," variables such as "transaction amount," "payer account balance," and "recipient country code" are configured. At the "transaction review access point," in addition to the basic variables mentioned above, variables such as "payer's historical transaction success rate" and "recipient industry category" may also be added to enable a more comprehensive risk assessment.

[0052] The constant library management module is responsible for defining all constants associated with each variable. For each variable, the constant library management module is responsible for defining a series of specific, fixed reference values ​​or thresholds. These constants are used to clarify the variable's reasonable range, restrictions, or other important criteria. Constants provide a reference standard for judging and evaluating variables and are an indispensable component of the basic object model. For example, for the "transaction amount" variable, constants such as "maximum single transaction limit" and "daily cumulative transaction limit" may be defined. For the "transaction time" variable, constants such as "normal trading hours" may be defined.

[0053] The action library management module is used to define the various risk control linkage actions used in transaction data processing at each access point. These actions are specific operations performed on transaction data, reflecting the application logic of the basic object model in actual business operations. For example, at the "Transaction Data Verification Access Point," actions such as "Verify that the transaction amount is within a reasonable range" and "Check that the payer's account status is normal" might be defined. At the "Risk Assessment Access Point," actions such as "Calculate Risk Score" and "Query Blacklist" are executed, and the subsequent processing of the transaction is determined based on the assessment results. If a transaction is determined to be high-risk, actions such as "Intercept Transaction" and "Send Risk Notification to Administrator" are triggered. The actions in the action library can be flexibly configured and adjusted based on business needs and risk strategies. This enables the system to dynamically execute corresponding operations based on different access points and business scenarios, thereby improving the flexibility and adaptability of risk control.

[0054] The list library management module is used to define blacklists and whitelists for each access point and effectively manage blacklist and whitelist data, including operations such as adding, deleting, modifying, and querying lists. Blacklists and whitelists are important rule elements in the basic object model. By comparing them with transaction-related entity information, they can quickly determine whether transactions are risky. For example, at the "Risk Review Access Point," transactions not on the blacklist are further checked to see if they are on the whitelist. If so, the strictness of the risk assessment can be appropriately reduced.

[0055] The indicator library management module receives real-time transaction data transmitted via Kafka, calculates indicator data for each access point, and stores this data in a Redis cluster. The calculated indicator data is the result of statistical analysis of transaction data, reflecting the dynamic characteristics and trends of transactions. These indicators can be statistical data reflecting business operations and risk levels, including transaction indicators, risk indicators, and user behavior indicators. For example, at the "real-time transaction monitoring access point," indicators such as the "number of transactions in the past hour" and the "total transaction amount in the past day" are calculated to determine whether current transactions are unusually active. At the "risk assessment access point," the legitimacy of transactions is assessed by combining indicators such as the "average transaction amount of the payer in the past month."

[0056] In one embodiment, the indicator library management module performs time-series behavior analysis on real-time transaction data using a sliding window to obtain traffic indicator data for any time period. The sliding window is set to a fixed time range based on requirements. As time passes, the window continuously moves forward, new transaction data continuously enters the window, and old data outside the window time range is removed. In this way, real-time calculations can be performed on the data within the window to obtain traffic indicator data for any time period.

[0057] In a cross-border payment scenario, let's take the example of calculating the number of transactions in the past hour. The indicator library management module continuously monitors real-time transaction data from Kafka. Whenever new transaction data arrives, it determines whether the timestamp of the data falls within the time range of the current sliding window. If so, the transaction is included in the calculation. If the oldest transaction data in the window is older than one hour before the current time, the old data is removed from the window. The number of transactions in the window is then recounted, resulting in a real-time flow metric for the number of transactions in the past hour. Similarly, other flow metrics, such as total transaction amount and transaction frequency, can be calculated using a similar approach.

[0058] The real-time traffic indicators output by the indicator calculation are the raw data basis for time series feature analysis and subsequence analysis. The granularity of the indicator calculation (such as hourly or daily statistics) determines the time scale of subsequent analysis. The traffic indicators calculated by the indicator library management module can be used to analyze the time series characteristics of user payment behavior, including the time sequence, frequency, and periodicity of transactions. By extracting these time series characteristics, abnormal behavior can be better identified. The traffic indicators calculated by the indicator library management module can be used for contextual subsequence analysis, which is to divide the entire transaction sequence into multiple smaller subsequences according to certain rules. The basis for division can be factors such as time interval, transaction type, and transaction amount. In each divided subsequence, the indicator library management module will analyze the various attributes of the transaction to identify key transaction behavior patterns. By identifying these key transaction points, the context information of the transaction can be better understood and whether there are any abnormalities in the transaction can be determined.

[0059] In one embodiment, if Figure 2 , the decision engine layer 4, includes: a decision rule management module, a calculation expression management module, a decision condition management module, a rule parser, a condition parser management module, a rule engine and an expression evaluation engine;

[0060] The decision rule management module primarily creates decision rules for each access point based on the basic object model configured by the basic data layer 2. The basic data layer 2 already has basic object models for transaction data, such as variables, constants, actions, blacklists and whitelists, and indicators. The decision rule management module uses these models to define specific decision rules to meet the needs of different business scenarios.

[0061] The calculation expression management module is used to define the calculation expressions used in decision rules. These expressions can perform mathematical, logical, or other complex operations on variables and constants, providing specific data support for decision making. For example, they can calculate whether a transaction amount exceeds a certain threshold or whether a risk score exceeds a certain standard.

[0062] The decision condition management module is used to define the conditions used in decision rules; these conditions are the core logic of the decision rules and determine how the system evaluates and processes transaction data. It supports complex logical relationships, such as "AND", "OR", "NOT", etc., so that multiple conditions can be combined to form more complex decision logic. By precisely setting conditions, it supports refined risk management strategies and can be flexibly adjusted for different business scenarios and risk characteristics. The calculation expression management module provides specific operation logic and data processing capabilities to generate intermediate results or final results. The decision condition management module uses these results, combined with variables and constants, to set specific conditional logic to determine whether the requirements for performing a certain action are met.

[0063] The rule parser performs preliminary analysis of the conditions and calculation expressions in the decision rules. It extracts key elements from the rules, such as variables, constants, and calculation expressions, and breaks these elements into executable logical units. The rule parser sends the parsed results to the condition parser for further analysis of the conditions and their relationships. After the condition parser completes the analysis, it generates a rule script and an expression evaluation script based on the condition parsing results and the results of previous parsing. These scripts are sent to the rule engine and expression evaluation engine, respectively. When the incoming transaction data meets the conditions of the decision rule, the rule engine and expression evaluation engine execute the corresponding actions, ultimately obtaining a decision result.

[0064] The conditional parser performs conditional parsing on the parsing result of the rule parser, parses out all conditions and the relationships between the conditions, and sends the conditional parsing result to the rule parser.

[0065] The rules engine receives rule scripts and matches input transaction data based on the logic and conditions in the scripts. It checks whether the transaction data meets the conditions defined in the rule scripts. When a matching rule is found, the rules engine executes the risk control actions defined in the rule scripts. These actions may include blocking transactions, sending alerts, or triggering manual review. Based on the matching results and executed actions, the rules engine generates a final decision and feeds the results back to the upper application layer.

[0066] The expression evaluation engine receives an expression evaluation script and calculates the input transaction data based on the logic and calculation expressions in the script. The calculation results are fed back to the rule engine, which further determines whether the rule conditions are met based on these results. The expression evaluation engine's calculation results are an important basis for the rule engine's decision-making, ensuring that the rule engine can make correct decisions based on accurate data.

[0067] The secondary packaging module is used to secondary package the decision rules, which can provide risk control personnel with a more intuitive and clear way to display decision rules.

[0068] Preferably, the rule engine uses Drools, an open-source business rule management system that can execute decisions based on Drools rule scripts generated by a rule parser and input transaction data. After receiving the Drools rule scripts generated by the rule parser, Drools matches and executes the rules. When the conditions in the rules are met, Drools triggers corresponding actions, such as intercepting transactions or sending notifications.

[0069] The expression evaluation engine uses Aviator, a lightweight Java expression evaluation engine that can evaluate computational expressions. After receiving the expression evaluation script generated by the rule parser, Aviator calculates the expression and feeds the calculation results back to the rule engine Drools so that Drools can make decisions based on the results.

[0070] In one embodiment, the secondary packaging module includes:

[0071] The decision table management module encapsulates decision rules into rules that generate decision tables. A decision table is a tool that presents decision logic in a tabular format, clearly listing different condition combinations and corresponding decision outcomes. Business personnel can modify, add, or delete rules directly through the table without requiring in-depth technical knowledge, thus lowering the operational barrier. This module is ideal for situations with a large number of rules and complex conditions, helping business personnel quickly identify and adjust rules.

[0072] The scorecard management module encapsulates decision rules into rules that generate scorecards. Decision results are converted into scorecards, and a comprehensive score is calculated by assigning weights and scores to different criteria. This approach quantifies risk assessment and provides a more refined risk grading. Based on the scoring results, transactions are classified into different risk levels (e.g., low, medium, and high), enabling business personnel to take appropriate measures based on the risk level. This module is suitable for scenarios requiring quantitative risk assessment, such as credit assessment and fraud prevention, helping business personnel quickly determine the degree of risk.

[0073] The decision tree management module encapsulates decision rules into rules that generate decision trees. Decision rules are displayed in a tree-like structure, clearly illustrating the logical relationships between conditions and the decision path. This intuitive and easy-to-understand format helps business personnel quickly understand the decision-making process. Through the decision tree, business personnel can clearly see each decision path, its corresponding conditions, and its results, facilitating rule analysis and optimization. This module is suitable for situations where rule logic is complex and a clear display of decision paths is required, helping business personnel quickly identify issues and optimize rules.

[0074] The decision flow management module encapsulates decision rules into rules that generate decision flows. It displays the execution order and logical relationships of decision rules in a flowchart format, clearly presenting the dynamic changes in the decision-making process. This format helps business personnel understand the execution order and mutual influence of rules. Business personnel can directly adjust the execution order and logical relationships of rules through the flowchart, optimizing the decision process and improving decision efficiency. This module is suitable for situations where the rule execution sequence is complex and requires dynamic adjustment, helping business personnel quickly optimize the decision process.

[0075] By converting decision rules into decision tables, scorecards, decision trees, and decision flows for secondary packaging, the cross-border payment risk control system provides risk control personnel with an intuitive and clear presentation of rules. This not only facilitates efficient rule management, risk assessment, and decision-making, but also significantly improves the efficiency and accuracy of risk control. Furthermore, the visual management interface significantly reduces reliance on technical personnel, enabling personnel to more independently adjust and optimize rules, thereby better navigating the complex and ever-changing cross-border payment risk environment.

[0076] In one embodiment, if Figure 2 The decision application layer 5 is mainly based on the secondary encapsulation of the basic functions of the decision engine layer 4 and the basic data layer 4, including:

[0077] The merchant rating management module is responsible for rating merchants based on scorecard rules and merchant information. Specifically, the scorecard rules are provided by the scorecard management module of the decision engine layer 4. These rules are pre-defined based on business requirements and risk strategies and are used to quantitatively assess the risk characteristics of merchants. Merchant information comes from the basic data layer 2, including but not limited to merchant type, registration time, industry category, transaction data, etc. The merchant rating management module automatically calculates the merchant's risk score based on the scorecard rules. This automated scoring process reduces manual intervention and improves efficiency and accuracy.

[0078] The visual rule module is used to configure the common conditions and calculation expressions of each decision rule in the operation interface; specifically, based on the basic object model of the basic data layer 2, the available conditions and expressions are called from the calculation expression management module and the decision condition management module of the decision engine layer 4. Through the visual operation interface, business personnel can flexibly adjust the conditions and calculation expressions of the decision rules according to business needs without in-depth understanding of technical details, thereby lowering the operation threshold.

[0079] The Merchant Rule Threshold Module is used to set rule thresholds for each merchant. Different merchants may have different business characteristics and risk profiles. By setting rule thresholds, personalized rules can be generated for each merchant. The Visual Rule Module configures universal decision rules that apply to all merchants but can be customized using thresholds. Once universal rules are set, personalized rules are automatically generated based on the thresholds set for each merchant in the Merchant Rule Threshold Module, reducing the workload of repeated configuration.

[0080] The Quota Control Center is used to set transaction limits for each access point. Based on these limits, it defines relevant decision-making rules, such as limit caps and risk control conditions. These rules monitor transaction amounts in real time to ensure they remain within the set limits. By comparing transaction amounts with transaction limits, it can quickly identify abnormal transactions and implement timely risk control measures.

[0081] The data query engine is used to provide an efficient query interface, allowing users to directly access the business database and obtain the required data.

[0082] The Big Data Center manages business data and provides data storage, backup, and recovery capabilities. It centrally stores business data, including transaction records, merchant information, and risk assessment data, ensuring data integrity and availability. Regular data backups prevent data loss or corruption and ensure data durability. In the event of data loss or corruption, data can be quickly restored to minimize business interruption. Data statistics and analysis are supported, providing data support for risk management decisions.

[0083] The blacklist and whitelist management module is used to manage the blacklist and whitelist of each access point defined by the list library management module of the basic data layer 3; it allows users to add, delete, modify and query entity information in the blacklist and whitelist, such as merchant ID, account number, etc.

[0084] The Rule Backtesting and Optimization Center uses historical data to backtest created decision rules and analyze key metrics from the backtest results, such as accuracy, false positive rate, and maximum drawdown. Backtesting allows you to evaluate the performance of decision rules under different historical market conditions and identify their strengths and weaknesses. Based on the backtest results, you can adjust rule parameters, such as thresholds and weights, to optimize their performance. You can also refine the rule logic to make it more stable across different market conditions.

[0085] The workflow engine is used to manage business processes. Through the workflow engine, the system can efficiently coordinate and execute complex business processes, ensuring the smooth connection and efficient operation of each link, thereby improving overall business efficiency and risk management.

[0086] In one embodiment, if Figure 2 , the system management layer 6 includes:

[0087] The user management module is used to manage system users; specifically, it supports operations such as user creation, editing, freezing / unfreezing, and deletion, and records basic user information (such as name, department, role, and contact information).

[0088] Function menu management module, used to create function menus at all levels;

[0089] The authorization group management module is used to create different authorization groups. Specifically, authorization groups can be created by role, department, or business scenario, and users with the same permissions can be managed in batches.

[0090] Menu authorization management module, used to assign permissions to function menus for users and authorization groups;

[0091] The data authorization management module is used to assign data permissions to users and authorization groups; specifically, permissions to view data, edit data, delete data, etc.

[0092] The scheduled task module is used to create various scheduled tasks, such as regularly backing up data or generating risk reports.

[0093] In one embodiment, the cross-border payment dynamic risk control system can monitor exchange rate dynamics in real time through an external interface, track exchange rate changes between currencies of various countries in real time, and grasp market dynamics in a timely manner. When the exchange rate fluctuation exceeds a set threshold, the system automatically issues an early warning to remind enterprises or financial institutions to take measures.

[0094] Similar to the principles of the above embodiments, the present invention provides a method for dynamic risk control of cross-border payments.

[0095] The following provides specific embodiments in conjunction with the accompanying drawings:

[0096] like Figure 3A flow chart showing a method for dynamic risk control of cross-border payments in an embodiment of the present invention is provided.

[0097] The cross-border payment dynamic risk control system applied in the above embodiment includes:

[0098] Step S1: Define access points for each process node in the transaction system that requires dynamic risk control of cross-border payments through the data access layer;

[0099] Step S2: configuring the basic object model corresponding to the transaction data of each access point through the basic data layer;

[0100] Step S3: The decision engine layer configures decision rules based on the basic object model of each access point;

[0101] Step S4: Accessing the transaction data of the transaction system through the access point of the data access layer, and when the conditions of the corresponding decision rules are met, the decision engine layer executes the corresponding risk control linkage disposal action to obtain the decision result;

[0102] Step S5: Feedback the decision result to the transaction system through the data access layer.

[0103] Since the implementation principle of the cross-border payment dynamic risk control method has been described in the above embodiments, it will not be repeated here.

[0104] The cross-border payment dynamic risk control system provided by the embodiment of the present invention can be implemented on the terminal side or the server side. As for the hardware structure of the electronic terminal, please refer to Figure 4 , is an optional hardware structure diagram of the electronic terminal 1000 provided in an embodiment of the present invention. The terminal 1000 can be a mobile phone, a computer device, a tablet device, a personal digital processing device, a factory background processing device, etc. The terminal 1000 includes: at least one processor 1001, a memory 1002, at least one network interface 10010 and a user interface 1009. The various components in the device are coupled together through a bus system 1005. It can be understood that the bus system 1005 is used to realize the connection and communication between these components. In addition to the data bus, the bus system 1005 also includes a power bus, a control bus and a status signal bus. However, for the sake of clarity, Figure 4 Various buses are labeled as bus systems.

[0105] The user interface 1009 may include a display, a keyboard, a mouse, a trackball, a click gun, keys, buttons, a touch pad or a touch screen.

[0106] It will be appreciated that the memory 1002 may be a volatile memory or a non-volatile memory, or may include both volatile and non-volatile memories. Among them, the non-volatile memory may be a read-only memory (ROM) or a programmable read-only memory (PROM), which is used as an external cache. By way of example but not limitation, many forms of RAM are available, such as static random access memory (SRAM) and synchronous static random access memory (SSRAM). The memory described in the embodiments of the present invention is intended to include, but is not limited to, these and any other suitable types of memory.

[0107] The memory 1002 in the embodiment of the present invention is used to store various categories of data to support the operation of the terminal 1000. Examples of such data include: any executable program for operating on the terminal 1000, such as an operating system 10021 and an application 10022; the operating system 10021 includes various system programs, such as a framework layer, a core library layer, a driver layer, etc., for implementing various basic services and processing hardware-based tasks. The application 10022 can include various applications, such as a media player (MediaPlayer), a browser (Browser), etc., for implementing various application services. The cross-border payment dynamic risk control system provided by the embodiment of the present invention can be included in the application 10022.

[0108] The methods disclosed in the above embodiments of the present invention can be applied to or implemented by processor 1001. Processor 1001 may be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above method can be completed by hardware integrated logic circuits in processor 1001 or by software instructions. The above processor 1001 may be a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Processor 1001 can implement or execute the various methods, steps, and logic block diagrams disclosed in the embodiments of the present invention. The general-purpose processor 1001 may be a microprocessor or any conventional processor. The steps of the accessory optimization method provided in the embodiments of the present invention can be directly implemented and executed by a hardware decoding processor, or by a combination of hardware and software modules in the decoding processor. The software module can be located in a storage medium located in a memory. The processor reads the information in the memory and, in conjunction with its hardware, completes the steps of the above method.

[0109] In an exemplary embodiment, the terminal 1000 may be used by one or more application-specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), and complex programmable logic devices (CPLDs) to execute the aforementioned method.

[0110] Those skilled in the art will appreciate that all or part of the steps in the above-described method embodiments can be implemented using hardware associated with a computer program. The aforementioned computer program can be stored in a computer-readable storage medium. When executed, the program performs the steps in the above-described method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0111] In the embodiments provided herein, the computer readable and writable storage medium may include a read-only memory, a random access memory, an EEPROM, a CD-ROM or other optical disk storage device, a magnetic disk storage device or other magnetic storage device, a flash memory, a USB flash drive, a mobile hard disk, or any other medium that can be used to store desired program code in the form of instructions or data structures and can be accessed by a computer. In addition, any connection can be appropriately referred to as a computer readable medium. For example, if the instruction is sent from a website, a server or other remote source using a coaxial cable, a fiber optic cable, a twisted pair, a digital subscriber line (DSL) or wireless technologies such as infrared, radio and microwaves, the coaxial cable, fiber optic cable, twisted pair, DSL or wireless technologies such as infrared, radio and microwaves are included in the definition of the medium. However, it should be understood that computer readable and writable storage media and data storage media do not include connections, carriers, signals or other temporary media, but are intended to be non-temporary, tangible storage media. Disk and disc, as used in this application, includes compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk and Blu-ray disc where disks usually reproduce data magnetically, while discs reproduce data optically with lasers.

[0112] Compared with the prior art, the present invention has the following advantages:

[0113] (1) This system builds a real-time data stream processing link by introducing stream processing frameworks such as Apache Flink / Kafka Streams, compressing the entire process delay from transaction data access to risk determination to milliseconds. After the real-time transaction data is automatically mapped to a standardized object model through the data access layer, the stream processing framework can calculate indicators such as transaction frequency and amount fluctuation in real time based on technologies such as sliding windows and state management, and simultaneously trigger the rule engine to perform condition verification and risk disposal, achieving real-time response capabilities of "transaction is risk control", and completely solving the lag problem of traditional batch processing mode.

[0114] (2) This system achieves dynamic configuration and scenario-based adaptation of risk control strategies through the configuration of access points, object models, rule engines, and dynamic strategies. Risk control personnel can customize access points at key nodes in the transaction process and independently configure data object models for each access point. At the same time, based on the visual rule configuration interface, conditions such as transaction amount, region, and currency can be flexibly combined to match differentiated disposal actions.

[0115] (3) The system integrates a dynamic rule engine with real-time data to build a closed loop of risk control. On the one hand, the rule engine supports real-time invocation of external data (such as dynamic blacklists and device fingerprints) and traffic indicators (such as transaction frequency in the past 5 minutes), breaking the limitations of traditional static thresholds. On the other hand, for major risk events, the system can execute continuous disposal actions (such as freezing accounts and tracking fund flows) through access point linkage, and dynamically adjust subsequent risk control strategies based on real-time feedback, forming an adaptive capability to new fraud methods, significantly improving the accuracy of risk identification and the timeliness of early warning.

[0116] In summary, the cross-border payment dynamic risk control system and method of the present invention defines access points for each process node of cross-border payment dynamic risk control through the data access layer to access transaction data. The basic data layer configures the corresponding basic object model, and the decision engine layer configures decision rules based on the model. When the conditions are met, the action is executed to obtain the decision result and feedback is sent to the transaction system. The present invention connects business data and logic in series through the access point, giving the transaction system risk adjudication and event handling capabilities. It has real-time response characteristics, can adapt to the diverse transaction scenarios of the cross-border financial market, and realizes the continuous mining of major risk events. It also supports the quick connection of external data sources and service interfaces to strengthen decision-making data support; uses machine learning technology to achieve refined classification of cross-border payment business, and dynamically adjusts rules based on real-time data and transaction behavior, abandoning the traditional fixed threshold model. By matching data changes through adaptive rules, the accuracy and flexibility of risk control are significantly improved. Therefore, the present invention effectively overcomes the various shortcomings of the existing technology and has high industrial application value.

[0117] The above embodiments are merely illustrative of the principles and effects of the present invention and are not intended to limit the present invention. Anyone skilled in the art may modify or alter the above embodiments without departing from the spirit and scope of the present invention. Therefore, any equivalent modifications or alterations made by one of ordinary skill in the art without departing from the spirit and technical principles disclosed herein are intended to be covered by the claims of the present invention.

Claims

1. A cross-border payment dynamic risk control system, characterized by: The system includes: infrastructure layer, data access layer, basic data layer, decision engine layer, decision application layer and system management layer; Wherein, the infrastructure layer is used to store system-related data; The data access layer is used to define access points for each process node of the transaction system that requires dynamic risk control of cross-border payments, and access transaction data through the defined access points; The basic data layer is used to configure the basic object model corresponding to the transaction data of each access point; The decision engine layer is used to configure decision rules based on the basic object model of each access point, and when the accessed transaction data meets the conditions of the corresponding decision rules, execute the corresponding risk control linkage disposal actions to obtain decision results, and then feed them back to the transaction system through the data access layer; The decision application layer is used for secondary packaging based on the basic functions of the decision engine layer and the basic data layer; The system management layer is used to perform basic management of the system.

2. The cross-border payment dynamic risk control system according to claim 1, characterized in that: The infrastructure layer includes: Mongo DB, used to store all data of system applications; Redis cluster, used to store indicator data and temporarily cache related data; Kafka, used for message caching during real-time indicator processing.

3. The cross-border payment dynamic risk control system according to claim 2, characterized in that: The data access layer includes: Data import module, used to import external data into Mongo DB for storage; External interface management module, used to receive external data from third-party systems using external data service interface; External database management module, used to receive external data from external business database; The access point management module is used to define the access points defined in each process node of risk control and communicate with the trading system through each access point; The access point statistics module is used to collect statistics on the data usage of each access point.

4. The cross-border payment dynamic risk control system according to claim 3, characterized in that: The basic data layer includes: Variable library management module, used to configure variables for each access point; Constant library management module, used to define all constants under each variable; The action library management module is used to define various risk control linkage actions used in transaction data processing at each access point; List library management module, used to define the blacklist and whitelist of each access point; The indicator library management module is used to receive real-time transaction data transmitted through Kafka, calculate the indicator data of each access point, and store the indicator data in the Redis cluster.

5. The cross-border payment dynamic risk control system according to claim 4, characterized in that: The index library management module performs time series behavior analysis on real-time transaction data through a sliding window to obtain traffic index data within any time period.

6. The cross-border payment dynamic risk control system according to claim 2, characterized in that: The decision engine layer includes: a decision rule management module, a calculation expression management module, a decision condition management module, a rule parser, a condition parser management module, a rule engine and an expression evaluation engine; The decision rule management module is configured to create a decision rule for each access point based on a basic object model configured by the basic data layer; The calculation expression management module is used to define the calculation expression used by the decision rule; The decision condition management module is used to define the conditions used in decision rules; The rule parser is used to parse the decision rules and send the parsing results to the condition parser to parse the conditions and their relationships within the decision rules. It is also used to generate a rule script and an expression evaluation script based on the condition parsing results of the condition parser, and send them to the rule engine and the expression evaluation engine, respectively, so that when the received transaction data meets the conditions of the decision rules, the rule engine and the expression evaluation engine will execute the corresponding risk control linkage disposal actions to obtain a decision result. The secondary packaging module is used to perform secondary packaging on the decision rules.

7. The cross-border payment dynamic risk control system according to claim 6, characterized in that: The secondary packaging module includes: A decision table management module is used to encapsulate decision rules into rules with the function of generating decision tables; The scorecard management module is used to encapsulate decision rules into rules with the function of generating scorecards; A decision tree management module is used to encapsulate decision rules into rules with the function of generating a decision tree; The decision flow management module is used to encapsulate decision rules into rules with the function of generating decision flows.

8. The cross-border payment dynamic risk control system according to claim 7, characterized in that: The decision application layer includes: Merchant rating management module, used to rate merchants based on scorecard rules and merchant information; Visual rule module, used to configure the conditions and calculation expressions of each decision rule in the operation interface; The merchant rule threshold module is used to set the rule threshold of each merchant to configure the decision rules of different merchants; The quota control center is used to set the transaction quota for each access point; Data query engine, used to query business data; Big data center, used to manage business data; Blacklist and whitelist management module, used to manage the blacklist and whitelist of each access point; The rule backtesting and optimization center is used to backtest decision rules using historical data and optimize them based on the backtesting results; Workflow engine, used to manage business processes.

9. The cross-border payment dynamic risk control system according to claim 1, characterized in that: The system management layer includes: User management module, used to manage system users; Function menu management module, used to create function menus at all levels; The authorization group management module is used to create different authorization groups to manage users with the same permissions in batches; Menu authorization management module, used to assign permissions to function menus for users and authorization groups; Data authorization management module, used to assign data permissions to users and authorization groups; Scheduled task module, used to create various scheduled tasks.

10. A cross-border payment dynamic risk control method, characterized in that: Applied to a cross-border payment dynamic risk control system according to any one of claims 1 to 9, the method comprising: Define access points through the data access layer for each process node in the transaction system that requires dynamic risk control of cross-border payments; Configuring the basic object model corresponding to the transaction data of each access point through the basic data layer; The decision engine layer configures decision rules based on the basic object model of each access point; Access the transaction data of the transaction system through the access point of the data access layer, and when the conditions of the corresponding decision rules are met, the decision engine layer executes the corresponding risk control linkage disposal action to obtain the decision result; The decision results will be fed back to the transaction system through the data access layer.

Images