Quick identification method and device for abnormal transaction event and electronic equipment

Abstract

The invention provides a method and a device for quickly identifying an abnormal transaction event, and electronic equipment. The method comprises the steps that transaction data is acquired, the transaction data at least comprises an event identification code, a risk control index and a time window corresponding to the risk control index, the event identification code is a unique identification code representing a transaction event, the risk control index is an index used for determining the risk of the transaction event, and the time window represents the length of a time statistics window of the risk control index; dividing risk control indexes into short-time indexes and long-time indexes according to time windows in the transaction data; and calculating the short-time index, calculating the long-time index by adopting an Flink distributed stream processing framework to obtain a risk control index value, and carrying out transaction interception under the condition that the risk control index value is greater than a preset threshold value so as to avoid occurrence of a transaction abnormal event. Through the method and the device, the problem of user property loss caused by incapability of timely finding financial abnormal behaviors due to poor stability of a wind control calculation method in the prior art is solved.

Description

Technical Field

[0001] This application relates to the technical field of financial data processing, and more specifically, to a method, apparatus, computer-readable storage medium, and electronic device for quickly identifying transaction anomaly events. Background Art

[0002] In the field of financial ecosystems, due to the huge daily trading volume and business volume, as well as the complexity and extensiveness of financial rules, a financial risk control system based on a rule engine can not only achieve real-time processing of large-scale transactions, reduce operational risks, but also cope with complex and changeable business rules, decouple business decision-making logic from system logic to achieve automatic decision-making and reduce financial abnormal behaviors.

[0003] The main idea of the rule engine is to extract the business decision part in the application program and write business rules using predefined semantic modules, which can be configured and managed by users or developers when needed. A common rule engine is divided into a rule layer, an engine layer, a calculation layer, and a storage layer from top to bottom. Among them, the calculation layer serves as the data support for risk decision-making, provides operation results to help with decision-making for the rule engine system, and provides reliability guarantee for the operation of the system. The core module of the calculation layer is the index calculation module, and as the most basic and highly reusable element at the bottom layer, the operation efficiency of the index directly affects the efficiency of the system.

[0004] In the risk control management business of abnormal behaviors, in order to discover new black production behaviors in the first time, business index calculations need to be launched at any time. When both the time window and the calculation dimension combination are uncertain, it is required that the index calculation delay is very low, generally at the millisecond level. Therefore, in order to meet the requirements of the risk control system for quick response, it is particularly important to build a real-time and efficient risk control index calculation system.

[0005] Common implementation methods in existing index calculation solutions include: a calculation solution based on database SQL, a calculation solution based on event-driven, and a calculation solution based on a real-time calculation framework. The implementation method based on database SQL is simple but not flexible enough, and the response time cannot be guaranteed. The calculation solution based on event-driven needs to process the message system, intermediate result storage system, and business logic for each index calculation, needs to develop logic for different event scenarios, and requires a large amount of pre-calculation. When the data volume is large, the memory is prone to crashing. The disadvantage of the calculation solution based on the real-time calculation framework is that due to the additional windowing steps during Flink calculation, the real-time performance is impaired, and due to the inability to close the window in time, a large amount of memory may be occupied, the program stability is poor, and it is easy to get stuck. Summary of the Invention

[0006] The main purpose of this application is to provide a method, device, computer-readable storage medium, and electronic device for quickly identifying transaction abnormal events, so as to at least solve the problem in the prior art that the stability of the risk control calculation method is poor, so that financial abnormal behaviors cannot be detected in time, resulting in property losses of users.

[0007] To achieve the above object, according to one aspect of the present application, a method for quickly identifying transaction abnormal events is provided, including: obtaining transaction data, where the transaction data at least includes an event identification code, a risk control indicator, and a time window corresponding to the risk control indicator, the event identification code is a unique identification code representing a transaction event, the risk control indicator is an indicator used to determine the risk of the transaction event, and the time window represents the length of the time statistical window of the risk control indicator; dividing the risk control indicator into a short-term indicator and a long-term indicator according to the time window in the transaction data, where the short-term indicator represents the risk control indicator with a time window less than a preset time threshold, and the long-term indicator represents the risk control indicator with a time window greater than or equal to the preset time threshold; calculating the short-term indicator and calculating the long-term indicator using the Flink distributed stream processing framework to obtain a risk control indicator value, and performing transaction interception when the risk control indicator value is greater than a preset threshold to avoid the occurrence of transaction abnormal events.

[0008] Optionally, dividing the risk control indicator into a short-term indicator and a long-term indicator according to the time window includes: determining the risk control indicator with a time window less than the preset time threshold as the short-term indicator; determining the risk control indicator with a time window greater than or equal to the preset time threshold as the long-term indicator.

[0009] Optionally, after obtaining the transaction data, the method further includes: parsing the transaction data to obtain an indicator dimension, where each indicator dimension corresponds to one or more risk control indicators; storing the risk control indicators corresponding to each indicator dimension in an indicator set, where each indicator dimension corresponds to one indicator set.

[0010] Optionally, after dividing the risk control indicator into a short-term indicator and a long-term indicator according to the time window in the transaction data, the method further includes: obtaining transaction flow information corresponding to the short-term indicator, where the transaction flow information at least includes a transaction account and a transaction amount; storing the transaction flow information corresponding to the short-term indicator in a pre-stored area.

[0011] Optionally, calculating the short-term indicator includes: obtaining the transaction flow information from the pre-stored area; obtaining the calculation function corresponding to the short-term indicator, and using the calculation function to calculate the transaction flow information to obtain the risk control indicator value corresponding to the short-term indicator.

[0012] Optionally, using the Flink distributed stream processing framework to calculate the long-term indicator includes: obtaining the transaction flow data corresponding to the long-term indicator at every preset time interval; calculating the transaction flow data within the preset time interval to obtain the risk control indicator value corresponding to the long-term indicator.

[0013] Optionally, before obtaining the transaction data, the method further includes: obtaining at least an indicator calculation function, a calculation window, and calculation fields, where the indicator calculation function is a function for indicator calculation, and the calculation window represents the time window for calculation; configuring an indicator calculation model at least according to the indicator calculation function, the calculation window, and the calculation fields, where the indicator calculation model is used to calculate and obtain the risk control indicator value.

[0014] According to another aspect of the present application, there is provided a rapid identification device for transaction abnormal events, including: a first acquisition unit, configured to acquire transaction data, where the transaction data at least includes an event identification code, a risk control indicator, and a time window corresponding to the risk control indicator, the event identification code is a unique identification code for representing a transaction event, the risk control indicator is an indicator for determining the risk of the transaction event, and the time window represents the length of the time statistical window of the risk control indicator; a division unit, configured to divide the risk control indicator into a short-term indicator and a long-term indicator according to the time window in the transaction data, where the short-term indicator represents the risk control indicator with the time window less than a preset time threshold, and the long-term indicator represents the risk control indicator with the time window greater than or equal to the preset time threshold; an interception unit, configured to calculate the short-term indicator and use the Flink distributed stream processing framework to calculate the long-term indicator to obtain a risk control indicator value, and perform transaction interception when the risk control indicator value is greater than a preset threshold to avoid the occurrence of transaction abnormal events.

[0015] According to still another aspect of the present application, there is provided a computer-readable storage medium, where the computer-readable storage medium includes a stored program, and when the program runs, it controls the device where the computer-readable storage medium is located to execute any one of the rapid identification methods for transaction abnormal events.

[0016] According to another aspect of the present application, an electronic device is provided, including: one or more processors, a memory, and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the one or more processors, and the one or more programs include a method for quickly identifying any one of the above-mentioned transaction anomaly events.

[0017] Applying the technical solution of the present application, transaction data is obtained. The transaction data at least includes an event identification code, a risk control index, and a time window corresponding to the risk control index. The event identification code is a unique identification code representing a transaction event. The risk control index is an index used to determine the risk of a transaction event. The time window represents the length of the time statistical window of the risk control index. The risk control index is divided into a short-term index and a long-term index according to the time window in the transaction data. The short-term index represents a risk control index with a time window less than a preset time threshold, and the long-term index represents a risk control index with a time window greater than or equal to the preset time threshold. The short-term index is calculated, and the Flink distributed stream processing framework is used to calculate the long-term index to obtain a risk control index value. When the risk control index value is greater than the preset threshold, transaction interception is performed to avoid the occurrence of transaction anomaly events. Compared with the prior art, where the risk control calculation method has poor stability and cannot detect financial anomaly behaviors in time, ultimately resulting in property losses of users, the present application can divide the risk control index into a short-term index and a long-term index through the time window and calculate them separately, avoiding the problem of poor stability or jamming caused by excessive memory occupation when calculating the indexes simultaneously, so as to quickly identify financial anomaly behaviors and avoid property losses of users. Therefore, it can solve the problem in the prior art that the risk control calculation method has poor stability, so that financial anomaly behaviors cannot be detected in time, ultimately resulting in property losses of users, and achieve the problem of timely identifying financial anomaly behaviors and avoiding property losses of users by improving the stability of the risk control calculation method. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] The specification drawings constituting a part of the present application are used to provide a further understanding of the present application. The schematic embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation to the present application. In the drawings:

[0019] Figure 1 A hardware structure block diagram of a mobile terminal for implementing a method for quickly identifying a transaction anomaly event provided by an embodiment of the present application is shown;

[0020] Figure 2 A flowchart showing a method for quickly identifying a transaction anomaly event provided by an embodiment of the present application is shown;

[0021] Figure 3 A flowchart showing a method for specifically quickly identifying a transaction anomaly event provided by an embodiment of the present application is shown;

[0022] Figure 4 The block diagram of a rapid identification device for transaction abnormal events provided by an embodiment of the present application is shown.

[0023] Among them, the above-mentioned drawings include the following reference numerals:

[0024] 102. Processor; 104. Memory; 106. Transmission device; 108. Input / output device. Detailed implementation manners

[0025] It should be noted that, without conflict, the embodiments in the present application and the features in the embodiments may be combined with each other. The present application will be described in detail below with reference to the drawings and in combination with the embodiments.

[0026] In order to enable those skilled in the art to better understand the solution of the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of the present application.

[0027] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged under appropriate circumstances, so as to implement the embodiments of the present application described herein. In addition, the terms "comprising" and "having" and any variations thereof are intended to cover non-exclusive inclusion. For example, a process, method, system, product or device that includes a series of steps or units does not necessarily have to be limited to those clearly listed steps or units, but may include other steps or units that are not clearly listed or are inherent to these processes, methods, products or devices.

[0028] For the convenience of description, some nouns or terms related to the embodiments of the present application are described below:

[0029] Event object: A unified field set passed in by the channel side when calling the risk decision interface, which consists of multiple basic fields;

[0030] Transaction flow: Transaction data or transaction records, which contain the values of some basic fields, such as name, mobile phone number, transaction serial number, etc.;

[0031] Rule: A set of set conditions followed by a set of actions;

[0032] Strategy: Implement risk decision-making and management by applying the combination of model scoring and rule results;

[0033] Rule Engine: Extract the business decision-making part in the application and write business rules using predefined semantic modules, which can be configured and managed by users or developers when needed;

[0034] Indicator: Statistically calculate business data and provide the calculation results to the rule engine to assist in decision-making. For example, "The transaction amount within 5 minutes for the same card number is greater than 500", and its business indicator definition is: Sum the amounts in the transaction water flow for the same card number within 5 minutes;

[0035] Dimension: The dimension for indicator statistics, and the selection range is some basic fields, such as mobile phone number, device number, etc.;

[0036] Time Window: The time range for indicator statistics;

[0037] Flink: A distributed, high-performance, scalable, and fault-tolerant stream processing engine that supports batch processing and stream processing;

[0038] Redis: An in-memory database that can be used in scenarios such as databases, caches, and message middleware.

[0039] As introduced in the background art, the existing risk control calculation method has poor stability, so that financial abnormal behaviors cannot be detected in time, resulting in property losses of users. To solve the problem that the risk control calculation method has poor stability and cannot detect financial abnormal behaviors in time, resulting in property losses of users, the embodiments of the present application provide a method, device, computer-readable storage medium, and electronic device for quickly identifying transaction abnormal events.

[0040] Next, the technical solutions in the embodiments of the present invention will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of the present invention.

[0041] The method embodiments provided in the embodiments of the present application can be executed on a mobile terminal, a computer terminal, or a similar computing device. Taking running on a mobile terminal as an example, Figure 1 is a hardware structure block diagram of a mobile terminal for a method of quickly identifying transaction abnormal events in the embodiments of the present invention. As Figure 1 shown, the mobile terminal may include one or more ( Figure 1 only one is shown in Figure 1The structure shown is only schematic and does not limit the structure of the above-mentioned mobile terminal. For example, the mobile terminal may further include more or fewer components than those shown in Figure 1 or have a different configuration from that shown in Figure 1 .

[0042] The memory 104 can be used to store computer programs, for example, software programs and modules of application software, such as the computer program corresponding to the method for quickly identifying transaction anomaly events in the embodiments of the present invention. The processor 102 executes various functional applications and data processing by running the computer program stored in the memory 104, that is, implements the above-mentioned method. The memory 104 may include a high-speed random access memory and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memories. In some instances, the memory 104 may further include a memory remotely disposed relative to the processor 102, and these remote memories can be connected to the mobile terminal through a network. Examples of the above-mentioned network include but are not limited to the Internet, enterprise intranet, local area network, mobile communication network, and combinations thereof. The transmission device 106 is used to receive or send data via a network. Specific examples of the above-mentioned network may include the wireless network provided by the communication provider of the mobile terminal. In one instance, the transmission device 106 includes a network adapter (Network Interface Controller, abbreviated as NIC), which can be connected to other network devices through a base station and thus can communicate with the Internet. In one instance, the transmission device 106 may be a radio frequency (RF) module, which is used to communicate with the Internet wirelessly.

[0043] In this embodiment, a method for quickly identifying transaction anomaly events running on a mobile terminal, a computer terminal, or a similar computing device is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although the logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in a different order from that here.

[0044] Figure 2 is a flowchart of the method for quickly identifying transaction anomaly events according to an embodiment of the present application. As Figure 2 shown, the method includes the following steps:

[0045] Step S201: Obtain transaction data, where the transaction data includes at least an event identification code, a risk control indicator, and a time window corresponding to the risk control indicator. The event identification code is a unique identification code representing a transaction event. The risk control indicator is an indicator used to determine the risk of the transaction event. The time window represents the length of the time statistical window of the risk control indicator.

[0046] Specifically, the sources of transaction data are diverse, including but not limited to transactions made through mobile phone clients, etc. These transaction data are generated in real time by the transaction system and contain a large number of basic fields, such as transaction amount, transaction time, user identification, card number, mobile phone number, device number, etc. The system needs to have the ability to collect real-time data, capture transaction data from various transaction systems or channels, and convert it into event objects in a unified format. The event object should at least contain an event identification code, a risk control indicator, and corresponding time window information. The event identification code is a unique identifier used to distinguish different transaction events, ensuring the independence and traceability of each event. It is usually a transaction serial number, a transaction request ID, or a hash value generated by combining a transaction timestamp, a user ID, etc. The risk control indicator is a rule for statistical calculation of specific fields in the transaction flow. For example, "the transaction amount within 5 minutes for the same card number is greater than 500" is a risk control indicator. The indicator consists of an indicator name, a calculation function, a time window length, a main dimension field, and additional dimension fields, etc. The time window represents the time range for risk control indicator statistics. It can be a fixed length (such as 5 minutes, 1 hour) or a dynamic length (such as the last 7 days), used to define the start and end time points of indicator calculation, so as to accurately reflect the transaction situation within a specific time interval.

[0047] Step S202: Divide the risk control indicators into short-term indicators and long-term indicators according to the time window in the transaction data, where the short-term indicators represent the risk control indicators with a time window less than a preset time threshold, and the long-term indicators represent the risk control indicators with a time window greater than or equal to the preset time threshold.

[0048] Specifically, after receiving the transaction data, the system first parses the risk control metrics and their corresponding time windows in each event object. Based on a preset time threshold (e.g., 7 days), the risk control metrics are divided into two categories: short-term metrics and long-term metrics. Short-term metrics refer to those with a time window length less than the preset time threshold, while long-term metrics are those with a time window length greater than or equal to the preset time threshold. Through this classification, different calculation strategies can be adopted according to the characteristics of different metrics. Determination of the preset time threshold: The setting of the preset time threshold is based on the reasonable utilization of memory and computing resources. The transaction data volume within 7 days is relatively small, suitable for real-time calculation in memory, which can quickly respond and reduce calculation latency. However, the data volume exceeding 7 days is huge, and in-memory calculation may lead to resource exhaustion or slower processing speed. Therefore, long-term metrics are suitable for calculation using stream processing frameworks such as Flink to maintain the stability and efficiency of the system.

[0049] Step S203, calculate the short-term metrics and calculate the long-term metrics using the Flink distributed stream processing framework to obtain the risk control metric values, and in the case where the risk control metric values are greater than the preset threshold, perform transaction interception to avoid the occurrence of transaction anomaly events.

[0050] Specifically, after the division, the short-term metrics and long-term metrics are calculated separately. For short-term metrics, the system first extracts the transaction flow information related to the current event from the in-memory database of Redis. Through the main dimension fields (such as mobile phone number, card number) and additional dimension fields (such as device number, transaction type) in the event object, the flow is filtered to ensure that only the data relevant to the current calculation is processed. Based on the filtered data, the system applies predefined calculation functions for metric calculation. The calculation functions may include summation, average, standard deviation, statistics of the last N transactions, etc. These calculations are performed in real time in memory to ensure that the response speed meets the real-time requirements of the risk control system. For long-term metrics, since the time window exceeds 7 days, the data volume may be very large and not suitable for in-memory processing. The system uses the Flink framework for data preprocessing, including data cleaning, format unification, etc., to ensure data quality. At the same time, the Flink framework can set time windows. For long-term metrics, it can be set as a tumbling window or a sliding window, and the window size and calculation frequency can be adjusted according to business requirements. Flink can handle large-scale stream data, and it performs calculations by continuously reading the data stream. For long-term metrics, the system inputs the transaction flow data as a continuous stream into Flink, and Flink performs statistical calculations on the data according to the preset window strategy, such as calculating the number of transactions, total amount, etc. for a specific dimension (such as the same mobile phone number and the same card number) in the past 7 days.

[0051] Through this embodiment, transaction data is obtained. The transaction data at least includes an event identification code, a risk control indicator, and a time window corresponding to the risk control indicator. The event identification code is a unique identification code representing a transaction event. The risk control indicator is an indicator used to determine the risk of a transaction event. The time window represents the length of the time statistical window of the risk control indicator. The risk control indicators are divided into short-term indicators and long-term indicators according to the time window in the transaction data. The short-term indicator represents a risk control indicator with a time window less than a preset time threshold, and the long-term indicator represents a risk control indicator with a time window greater than or equal to the preset time threshold. The short-term indicators are calculated, and the long-term indicators are calculated using the Flink distributed stream processing framework to obtain risk control indicator values. When the risk control indicator values are greater than the preset threshold, transaction interception is performed to avoid the occurrence of transaction anomaly events. Compared with the prior art in which the risk control calculation method has poor stability and cannot detect financial abnormal behaviors in time, ultimately resulting in property losses of users, this application can divide the risk control indicators into short-term indicators and long-term indicators according to the time window and calculate them separately, avoiding the problem that the simultaneous calculation of indicators occupies too much memory, resulting in poor stability or jamming, so as to quickly identify financial abnormal behaviors and avoid property losses of users. Therefore, it can solve the problem in the prior art that the risk control calculation method has poor stability, so that financial abnormal behaviors cannot be detected in time, ultimately resulting in property losses of users, and achieve the problem of timely identifying financial abnormal behaviors by improving the stability of the risk control calculation method and avoiding property losses of users.

[0052] In the specific implementation process, the above step S202 of dividing the risk control indicators into short-term indicators and long-term indicators according to the time window can be implemented through the following steps: Step S2021: Determine the risk control indicators with a time window less than the preset time threshold as the short-term indicators; Step S2022: Determine the risk control indicators with a time window greater than or equal to the preset time threshold as the long-term indicators. By calculating the long-term indicators and short-term indicators through the above steps, different indicators can be calculated separately to avoid the problem of poor stability of the risk control calculation method.

[0053] Specifically, when the system receives an event object, it will parse the risk control indicators in the object and the length of their corresponding time windows. The time window is a key attribute of the risk control indicator, which is used to limit the time range of the indicator calculation, such as "the number of transactions with the same card number in the past 5 minutes". The system presets a time threshold, such as 7 days, as a benchmark for distinguishing short-term indicators from long-term indicators. This threshold is set based on system resources, memory capacity, and the capabilities and efficiency of the real-time computing framework to ensure that the system can reasonably allocate computing resources while meeting real-time requirements. If the time window length of a risk control indicator is less than the preset time threshold (i.e., less than 7 days), the indicator is determined to be a short-term indicator. The calculation of short-term indicators usually requires a quick response to adapt to the ever-changing trading environment, such as identifying abnormal trading patterns in a short period of time. Short-term indicators are screened by corresponding basic features, the basic feature set of the largest time window under the main dimension. For example, there are two strategies running online in the same time period, one is that the transaction amount in the past 3 seconds is greater than 5,000, and the other is that the transaction amount in the past 10 minutes is greater than 100,000. The basic features corresponding to these two strategies are: the sum of the transaction amount in the past 3 seconds and the sum of the transaction amount in the past 10 minutes. Here, the basic feature of the largest time window is taken, that is, the sum of the transaction amount in the past 10 minutes. Of course, there are many strategies in the same time period, so according to this idea, the basic feature set of all the largest time windows can be screened. The calculation of long-term indicators adopts the Flink distributed stream processing framework. Flink supports real-time processing of large-scale data streams, has low latency, high throughput and powerful window operation capabilities, and can handle indicator calculation tasks with longer time windows. The system inputs transaction flow data into Flink as a continuous data stream. Flink divides the data into windows according to the preset time window (such as transaction records with the same mobile phone number and card number in the past 30 days), and applies the corresponding calculation function for statistical analysis, such as calculating the cumulative distribution of the number of transactions under a specific dimension in the past 30 days.

[0054] In the specific implementation process, after obtaining the transaction data, the method further includes the following steps: Step S204: parsing the transaction data to obtain indicator dimensions, wherein each indicator dimension corresponds to one or more risk control indicators; Step S205: storing the risk control indicators corresponding to each indicator dimension into an indicator set, wherein each indicator dimension corresponds to one indicator set. The method simplifies the storage and retrieval process of indicators through the above steps, and also provides a clear logical framework for subsequent indicator calculation and strategy execution.

[0055] Specifically, the system first parses the received transaction data, extracts the basic fields in the data (such as transaction amount, transaction time, user ID, card number, mobile phone number, etc.), and maps them to a unified data model. This step ensures the standardization and consistency of all transaction data, providing a reliable data basis for subsequent identification of metric dimensions and metric calculations. In the standardized transaction data model, the system identifies the dimension fields related to risk control metrics. The dimension field can be a single field, such as a card number, or a combined field, such as the number of transactions within the same device and at the same time. In the actual application process, the main dimension information needs to be parsed. Common main dimensions include card number, mobile phone number, merchant number, etc. The main dimension is the rule triggered by transactions occurring under the same account (card number) or the same person (mobile phone number) or the same merchant (merchant number). That is, the main dimension can filter out the transaction flows under the same dimension to the greatest extent. For example: for the policy that the overseas transaction amount of the same account within the last 3 seconds is greater than 5000, the main dimension is the card number because this policy filters the sum of the amounts of the transaction flows under the same card number. Each dimension field or combined field corresponds to a specific set of risk control metrics, which are used to measure the risk status under that dimension. Association between metrics and dimensions: The system further parses the definition of each risk control metric to determine which dimension fields it is associated with. For example, the metric "the transaction amount of the same card number exceeds 10,000 yuan within one day" is associated with the "card number" and "one-day time" dimensions. This step is the basis for establishing the correspondence between metrics and dimensions, providing guidance for subsequent metric classification and calculation.

[0056] To optimize the storage and access efficiency of the metric set, the system uses a Map data structure to implement the storage of the metric set, where the key is the dimension field name and the value is a list containing all relevant risk control metrics. In this way, whether for metric calculation or policy execution, the system can quickly obtain all relevant risk control metrics through the dimension field name, reducing unnecessary data retrieval and processing time.

[0057] In some alternative embodiments, after dividing the risk control metrics into short-term metrics and long-term metrics according to the time window in the transaction data, the method further includes the following steps: Step S206: Obtain the transaction flow information corresponding to the short-term metrics, where the transaction flow information at least includes the transaction account and the transaction amount; Step S207: Store the transaction flow information corresponding to the short-term metrics in a pre-stored area. This method speeds up the response speed of risk decision-making through the above steps and also ensures the stability of the system and the effective utilization of resources through data cleaning strategies.

[0058] In the specific implementation process, the system first identifies which short-term metrics are relevant to the current event based on the dimension fields in the current event object (such as mobile phone number, card number, device number, etc.). The dimension fields are the key basis for filtering transaction flow information, ensuring the accuracy and pertinence of the calculation. The system extracts transaction flow information that matches the current event and the relevant dimension fields from the real-time transaction data stream. This information usually includes, but is not limited to, transaction accounts, transaction amounts, transaction times, etc., and is the basic data for calculating short-term risk control metrics. For each short-term metric, the system needs to screen out transaction flow information within a specific time range from the real-time transaction data stream according to the length of its time window. For example, if the time window of the metric is "the past 5 minutes", the system needs to extract all relevant transaction flows within 5 minutes back from the current time point. After data extraction, the system preprocesses the transaction flow information, including data cleaning (removing abnormal or invalid data), format unification (ensuring that all transaction flow information has the same format), and necessary data conversion (such as converting the transaction time to a comparable timestamp format) to meet the needs of subsequent calculations.

[0059] To ensure that short-term metrics can be calculated in real time and reduce latency during calculation, the system chooses to use local high-speed memory as a pre-storage area, such as a Redis in-memory database. Redis provides fast data access capabilities and is very suitable for storing small data sets that need to be accessed frequently. The system organizes the extracted and preprocessed transaction flow information into specific data structures, such as using a Map or a List, and then stores it in Redis. The Map structure can use the dimension field as the key and the transaction flow information as the value, facilitating quick data lookup based on the dimension during subsequent calculations. The List structure is suitable for storing flow information in chronological order, facilitating calculations based on the time window.

[0060] In some alternative embodiments, the above step S203 for calculating the short-term metric can be implemented through the following steps: Step S2031: Obtain the transaction flow information from the pre-storage area; Step S2032: Obtain the calculation function corresponding to the short-term metric, and use the calculation function to calculate the transaction flow information to obtain the risk control metric value corresponding to the short-term metric. This method provides fast response capabilities for short-term risk control metrics through the above steps, further ensuring that the risk control system can detect potential risks in the shortest possible time.

[0061] In the specific implementation process, the pre-storage area in the system is designed as a high-speed memory area, and usually the Redis in-memory database is used. This is because Redis provides excellent data read and write performance, can quickly access data, and meet the requirements of real-time computing. When an event occurs, the system will parse the dimension fields in the event object, such as mobile phone numbers, card numbers, or device numbers, etc. These fields are the keys for calculating short-term metrics and are used to locate and extract relevant transaction flow information from the pre-storage area. According to the dimension fields, the system retrieves all transaction flow information related to the current event from Redis. This information has been filtered according to the time window and only contains data within the time range defined by the short-term metrics. After obtaining the transaction flow information, the system will verify its format to ensure that the data meets the input requirements of the calculation function. For example, if the calculation function requires a timestamp of the transaction time accurate to the second, the system will check whether the time field in the flow information has been converted to the corresponding format. Each short-term metric is associated with one or more predefined calculation functions. These functions can be sum, average, maximum or minimum, or even more complex statistical analysis functions, such as calculating the cumulative distribution of the number of transactions within a specific time window. The system calls the corresponding function from the configured calculation function library according to the definition of the short-term metric. The calculation function library is part of the system and contains all the preset calculation logics, ensuring the consistency and accuracy of the calculation. The called calculation function will process the transaction flow information obtained from the pre-storage area and perform relevant statistical analysis calculations. For example, for the metric "the transaction amount of the same card number is greater than 500 within 5 minutes", the calculation function will calculate the sum of all transaction flow amounts of the same card number in the past 5 minutes. The obtained risk control metric value will be stored in the system as a decision-making basis. For short-term metrics, the calculation results can be stored in memory for subsequent quick access and judgment by the rule engine. If the calculation results need to be persisted, they can also be stored in the database.

[0062] In some alternative embodiments, step S203 above calculates the long-term metric using the Flink distributed stream processing framework, which can be implemented through the following steps: step S2031: obtain the transaction flow data corresponding to the long-term metric at preset time intervals; step S2032: calculate the risk control metric value corresponding to the long-term metric for the transaction flow data within the preset time interval. This method realizes the efficient and real-time processing of long-term metrics by setting the above preset time intervals for regular calculation of long-term metrics and combining the data stream processing capabilities of Flink and the high-speed caching technology of Redis.

[0063] Specifically, the time window of the long-term indicator often exceeds 7 days, which means that a large amount of historical transaction flow data needs to be processed. Directly calculating during real-time event processing may lead to calculation delays and excessive resource consumption. Therefore, the system needs to set a reasonable preset time interval for regularly calculating the values of long-term indicators. This time interval can be determined according to business requirements and system performance. For example, it can be set to once per hour, once per day, or once per week. The setting of the preset time interval is also based on the consideration of resource optimization to ensure that the system does not consume excessive computing resources when processing large-scale data, while maintaining the real-time and high efficiency of data processing. Too short an interval may lead to frequent calculations and resource waste, while too long an interval may affect the timeliness of indicator updates. At the beginning of each preset time interval, the system extracts the transaction flow data within the time window related to the long-term indicator from long-term data storage (such as a distributed file system or a database). For example, if the time window of the long-term indicator is 30 days, the system extracts all transaction flow data in the past 30 days at the beginning of each hour. Flink can be configured to perform time window calculations on an hourly basis to ensure the real-time nature of the calculation results.

[0064] In the specific implementation process, before obtaining transaction data, the method further includes the following steps: obtaining at least an indicator calculation function, a calculation window, and calculation fields. Among them, the indicator calculation function is a function used for indicator calculation, and the calculation window represents the time window of the calculation; configuring an indicator calculation model at least according to the indicator calculation function, the calculation window, and the calculation fields, where the indicator calculation model is used to calculate the risk control indicator value. This method constructs an indicator calculation model that can efficiently calculate the risk control indicator value by integrating a function library, defining a time window, and extracting calculation fields, and can flexibly adapt to changes in business requirements, which is the key technical support for realizing accurate and real-time risk control.

[0065] Specifically, the system is designed with a rich set of indicator calculation function libraries, including but not limited to basic mathematical operation functions (such as summation, average value, maximum value, minimum value, etc.) and more complex statistical analysis functions (such as the maximum distance of devices, the average daily transaction times, etc.). These functions are preset in the system and can be called according to the specific requirements of the indicator. The calculation window is a key attribute in the indicator definition, which is used to limit the time range of indicator calculation. For example, the time window for "the transaction amount within 5 minutes with the same card number is greater than 500" is 5 minutes. The time window of the long-term indicator may exceed 7 days and needs to be processed through a real-time calculation framework such as Flink. Each risk control indicator involves one or more calculation fields, which are extracted from the transaction flow data and used to perform specific calculation operations. For example, for the indicator of calculating "the transaction amount within 5 minutes with the same card number", the calculation fields include the card number and the transaction amount.

[0066] Based on the metric calculation function, calculation window, and calculation fields, the system constructs a metric calculation model. The structural design of the model needs to consider the real-time nature, accuracy, and scalability of the calculation to ensure it can adapt to different business scenarios and risk control requirements. Each metric calculation model needs to be configured with specific parameters, including the parameters of the calculation function, the length of the time window, and the selection of calculation fields. These parameters determine the calculation logic and execution details of the model and are the basis for the model to run. The metric calculation model needs to have dynamic adaptability and be able to automatically adjust the calculation logic according to changes in business requirements and real-time updates of data. For example, when new transaction flow data arrives, the model can immediately update the calculation results to ensure that risk control decisions are based on the latest and most accurate data. Considering the complexity and diversity of the business, the metric calculation model supports multi-dimensional configuration and can simultaneously process the calculation of risk control metrics based on different fields or combinations of fields. This flexibility enables the system to more precisely identify and evaluate risks, improving the accuracy and effectiveness of risk control.

[0067] To enable those skilled in the art to more clearly understand the technical solution of this application, the following will specifically describe in detail the implementation process of the method for quickly identifying transaction abnormal events of this application in combination with specific embodiments.

[0068] This embodiment relates to a specific method for quickly identifying transaction abnormal events, as Figure 3 shown, and includes the following steps:

[0069] Step S1: Start;

[0070] Step S2: Orchestrate the metric model;

[0071] Step S3: Whether it is a short-term metric. If so, execute Step S4; if not, execute Step S6;

[0072] Step S4: Metric calculation result;

[0073] Step S5: Policy execution;

[0074] Step S6: Flink metric calculation;

[0075] Step S7: Redis storage;

[0076] Redis includes a set of strategies named StrategyVersions and a trading object (basic fields) ApplyEvent. The set of strategies includes multiple strategies. A strategy refers to the combination application of model scoring and rule results. For example, the sum of the absolute values of the transaction amounts in overseas accounts within the last 3 seconds is greater than 5000 yuan. This is a strategy. If the strategy is hit, the transaction will be blocked; if the strategy is not hit, the transaction will proceed. The trading object refers to the basic fields of a transaction record, such as a transaction message containing name, ID number, card number, amount, and transaction location.

[0077] Extract and split out metrics (at most including three types: derived fields, basic features, and derived features) through strategies and trading objects. The above strategy can be split into: Derived field: Absolute value of transaction amount = Take the absolute value (basic function) of the transaction amount (basic field); Basic feature: The sum of the absolute values of the transaction amounts in overseas trading accounts within the last 3 seconds. Store these in the pg database for pre - operation preparation.

[0078] Further store the above - mentioned metrics into the preset data class - PrepareCalculationData. Screen out the transaction messages that meet the criteria of overseas transactions occurring within the last 3 seconds and store them in Redis as short - term metric records for backup. If there are long - term metric records and calculation results processed by big data Flink, they are also stored in Redis for backup. Redis includes short - term metric records and long - term metric calculation results.

[0079] The embodiment of the present application also provides a device for quickly identifying transaction abnormal events. It should be noted that the device for quickly identifying transaction abnormal events in the embodiment of the present application can be used to execute the method for quickly identifying transaction abnormal events provided in the embodiment of the present application. The device is used to implement the above - mentioned embodiment and preferred implementation manners, and those that have been described will not be repeated. As used hereinafter, the term "module" can be a combination of software and / or hardware that can achieve a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, implementation in hardware, or a combination of software and hardware is also possible and contemplated.

[0080] The following introduces the device for quickly identifying transaction abnormal events provided in the embodiment of the present application.

[0081] Figure 4 It is a schematic diagram of the device for quickly identifying transaction abnormal events according to the embodiment of the present application. As Figure 4 shown, the device includes:

[0082] The first acquisition unit 10 is configured to acquire transaction data, where the transaction data at least includes an event identification code, a risk control indicator, and a time window corresponding to the risk control indicator. The event identification code is a unique identification code representing a transaction event. The risk control indicator is an indicator used to determine the risk of the transaction event. The time window represents the length of the time statistical window of the risk control indicator.

[0083] Specifically, the sources of transaction data are diverse, including but not limited to transactions through mobile phone clients and the like. These transaction data are generated in real time by the transaction system and contain a large number of basic fields, such as transaction amount, transaction time, user identification, card number, mobile phone number, device number, etc. The system needs to have the ability to collect real-time data, capture transaction data from various transaction systems or channels, and convert it into event objects in a unified format. The event object at least contains an event identification code, a risk control indicator, and corresponding time window information. The event identification code is a unique identifier used to distinguish different transaction events, ensuring the independence and traceability of each event. It is usually a transaction serial number, a transaction request ID, or a hash value generated by combining a transaction timestamp, a user ID, etc. The risk control indicator is a rule for statistical calculation of specific fields in the transaction flow. For example, "the transaction amount within 5 minutes for the same card number is greater than 500" is a risk control indicator. The indicator consists of an indicator name, a calculation function, a time window length, a main dimension field, and additional dimension field, etc. The time window represents the time range for risk control indicator statistics. It can be a fixed length (such as 5 minutes, 1 hour) or a dynamic length (such as the last 7 days), used to limit the start and end time points of indicator calculation, so as to accurately reflect the transaction situation within a specific time interval.

[0084] The division unit 20 is configured to divide the risk control indicator into a short-term indicator and a long-term indicator according to the time window in the transaction data, where the short-term indicator represents the risk control indicator with a time window less than a preset time threshold, and the long-term indicator represents the risk control indicator with a time window greater than or equal to the preset time threshold.

[0085] Specifically, after receiving the transaction data, the system first parses the risk control metrics and their corresponding time windows in each event object. Based on a preset time threshold (e.g., 7 days), the risk control metrics are classified into two categories: short-term metrics and long-term metrics. Short-term metrics refer to those with a time window length less than the preset time threshold, while long-term metrics are those with a time window length greater than or equal to the preset time threshold. Through this classification, different calculation strategies can be adopted according to the characteristics of different metrics. Determination of the preset time threshold: The setting of the preset time threshold is based on the reasonable utilization of memory and computing resources. The transaction data volume within 7 days is relatively small and suitable for real-time calculation in memory, which can quickly respond and reduce calculation latency. However, the data volume exceeding 7 days is huge, and in-memory calculation may lead to resource exhaustion or slow processing speed. Therefore, long-term metrics are suitable for calculation using stream processing frameworks such as Flink to maintain the stability and efficiency of the system.

[0086] The interception unit 30 is used to calculate the short-term metrics and calculate the long-term metrics using the Flink distributed stream processing framework, obtain the risk control metric values, and perform transaction interception when the risk control metric values are greater than the preset threshold to avoid the occurrence of transaction abnormal events.

[0087] Specifically, after the division, the short-term metrics and long-term metrics are calculated separately. For short-term metrics, the system first extracts the transaction flow information related to the current event from the Redis in-memory database. Through the main dimension fields (such as mobile phone number, card number) and additional dimension fields (such as device number, transaction type) in the event object, the flow is filtered to ensure that only the data relevant to the current calculation is processed. Based on the filtered data, the system applies predefined calculation functions for metric calculation. The calculation functions may include summation, average value, standard deviation, statistics of the last N transactions, etc. These calculations are performed in real-time in memory to ensure that the response speed meets the real-time requirements of the risk control system. For long-term metrics, since the time window exceeds 7 days, the data volume may be very large and not suitable for in-memory processing. The system uses the Flink framework for data preprocessing, including data cleaning, format unification, etc., to ensure data quality. At the same time, the Flink framework can set time windows. For long-term metrics, it can be set as a tumbling window or a sliding window, and the window size and calculation frequency can be adjusted according to business requirements. Flink can handle large-scale stream data, and it performs calculations by continuously reading the data stream. For long-term metrics, the system inputs the transaction flow data as a continuous stream into Flink, and Flink performs statistical calculations on the data according to the preset window policy, such as calculating the number of transactions, total amount, etc. for a specific dimension (such as the same mobile phone number and the same card number) in the past 7 days.

[0088] Through this embodiment, transaction data is obtained. The transaction data at least includes an event identification code, a risk control indicator, and a time window corresponding to the risk control indicator. The event identification code is a unique identification code representing a transaction event. The risk control indicator is an indicator used to determine the risk of a transaction event. The time window represents the length of the time statistical window of the risk control indicator. The risk control indicators are divided into short-term indicators and long-term indicators according to the time window in the transaction data. The short-term indicator represents a risk control indicator with a time window less than a preset time threshold, and the long-term indicator represents a risk control indicator with a time window greater than or equal to the preset time threshold. The short-term indicators are calculated, and the Flink distributed stream processing framework is used to calculate the long-term indicators to obtain risk control indicator values. When the risk control indicator value is greater than the preset threshold, transaction interception is performed to avoid the occurrence of transaction anomaly events. Compared with the prior art in which the risk control calculation method has poor stability and cannot detect financial abnormal behaviors in time, ultimately resulting in property losses of users, this application can divide the risk control indicators into short-term indicators and long-term indicators through the time window and calculate them separately, avoiding the problem of poor stability or jamming caused by excessive memory occupation when calculating indicators simultaneously, so as to quickly identify financial abnormal behaviors and avoid property losses of users. Therefore, it can solve the problem in the prior art that the risk control calculation method has poor stability, so that financial abnormal behaviors cannot be detected in time, ultimately resulting in property losses of users, and achieve the problem of timely identifying financial abnormal behaviors and avoiding property losses of users by improving the stability of the risk control calculation method.

[0089] In the specific implementation process, the division unit includes a first determination module and a second determination module. The first determination module is used to determine the risk control indicator with a time window less than the preset time threshold as the short-term indicator. The second determination module is used to determine the risk control indicator with a time window greater than or equal to the preset time threshold as the long-term indicator. The method calculates the long-term indicators and short-term indicators through the above steps, so that different indicators can be calculated separately to avoid the problem of poor stability of the risk control calculation method.

[0090] Specifically, when the system receives an event object, it will parse the risk control metrics and their corresponding time window lengths in the object. The time window is a key attribute of the risk control metric, which is used to define the time range for metric calculation, such as "the number of transactions with the same card number in the past 5 minutes". The system presets a time threshold, for example, 7 days, as the benchmark for distinguishing short-term metrics and long-term metrics. This threshold is set based on system resources, memory capacity, and the capabilities and efficiency of the real-time computing framework to ensure that the system can reasonably allocate computing resources while meeting real-time requirements. If the time window length of a risk control metric is less than the preset time threshold (i.e., less than 7 days), then the metric is determined as a short-term metric. The calculation of short-term metrics usually requires quick response to adapt to the rapidly changing trading environment, such as identifying abnormal trading patterns within a short period. The calculation of long-term metrics uses the Flink distributed stream processing framework. Flink supports the real-time processing of large-scale data streams, has low latency, high throughput, and powerful window operation capabilities, and can handle metric calculation tasks with longer time window lengths. The system inputs the transaction flow data as a continuous data stream into Flink. Flink divides the data according to the preset time window (such as transaction records with the same mobile phone number and the same card number in the last 30 days), and applies the corresponding calculation functions for statistical analysis, such as calculating the cumulative distribution of the number of transactions in a specific dimension in the past 30 days.

[0091] In the specific implementation process, after obtaining the transaction data, the method further includes a parsing unit and a first storage unit. The parsing unit is used to parse the transaction data to obtain metric dimensions, where each metric dimension corresponds to one or more of the risk control metrics; the first storage unit is used to store the risk control metrics corresponding to each metric dimension into a metric set, where each metric dimension corresponds to one metric set. Through the above steps, the method simplifies the process of metric storage and retrieval, and also provides a clear logical framework for subsequent metric calculation and policy execution.

[0092] Specifically, the system first parses the received transaction data, extracts the basic fields in the data (such as transaction amount, transaction time, user ID, card number, mobile phone number, etc.), and maps them to a unified data model. This step ensures the standardization and consistency of all transaction data, providing a reliable data basis for subsequent identification of metric dimensions and metric calculation. In the standardized transaction data model, the system identifies the dimension fields related to risk control metrics. The dimension field can be a single field, such as a card number, or a combined field, such as the number of transactions within the same device and the same time. Each dimension field or combined field corresponds to a specific set of risk control metrics, which are used to measure the risk status in that dimension. Association between metrics and dimensions: The system further parses the definition of each risk control metric to determine which dimension fields it is associated with. For example, the metric "the transaction amount of the same card number exceeds 10,000 yuan within one day" is associated with the "card number" and "one-day time" dimensions. This step is the basis for establishing the correspondence between metrics and dimensions, providing guidance for subsequent metric classification and calculation.

[0093] To optimize the storage and access efficiency of the metric set, the system uses a Map data structure to implement the storage of the metric set, where the key is the dimension field name and the value is a list containing all relevant risk control metrics. In this way, whether for metric calculation or policy execution, the system can quickly obtain all relevant risk control metrics through the dimension field name, reducing unnecessary data retrieval and processing time.

[0094] In some alternative embodiments, after dividing the risk control metrics into short-term metrics and long-term metrics according to the time window in the transaction data, the method further includes a second acquisition unit and a second storage unit. The second acquisition unit is used to acquire the transaction flow information corresponding to the short-term metrics, where the transaction flow information at least includes a transaction account and a transaction amount; the second storage unit is used to store the transaction flow information corresponding to the short-term metrics in a pre-stored area. This method speeds up the response speed of risk decision-making through the above steps, and also ensures the stability of the system and the effective utilization of resources through data cleaning strategies.

[0095] In the specific implementation process, the system first identifies which short-term metrics are relevant to the current event based on the dimension fields in the current event object (such as mobile phone number, card number, device number, etc.). The dimension fields are the key basis for filtering transaction flow information, ensuring the accuracy and pertinence of the calculation. The system extracts transaction flow information that matches the current event and the relevant dimension fields from the real-time transaction data stream. This information usually includes, but is not limited to, transaction accounts, transaction amounts, transaction times, etc., and is the basic data for calculating short-term risk control metrics. For each short-term metric, the system needs to screen out transaction flow information within a specific time range from the real-time transaction data stream according to the length of its time window. For example, if the time window of the metric is "the past 5 minutes", the system needs to extract all relevant transaction flows within 5 minutes back from the current time point. After data extraction, the system preprocesses the transaction flow information, including data cleaning (removing abnormal or invalid data), format unification (ensuring that all transaction flow information has the same format), and necessary data conversion (such as converting transaction times to comparable timestamp formats) to meet the needs of subsequent calculations.

[0096] To ensure that short-term metrics can be calculated in real time and reduce latency during calculation, the system chooses to use local high-speed memory as a pre-storage area, such as a Redis in-memory database. Redis provides fast data access capabilities and is very suitable for storing small data sets that need to be accessed frequently. The system organizes the extracted and preprocessed transaction flow information into specific data structures, such as using a Map or List, and then stores it in Redis. The Map structure can use the dimension field as the key and the transaction flow information as the value, facilitating quick data lookup based on the dimension during subsequent calculations. The List structure is suitable for storing flow information in chronological order, facilitating calculations based on time windows.

[0097] In some alternative embodiments, the above interception unit includes a first acquisition module and a first calculation module. The acquisition module is used to obtain the transaction flow information from the pre-storage area; the calculation module is used to obtain the calculation function corresponding to the short-term metric and calculate the transaction flow information using the calculation function to obtain the risk control metric value corresponding to the short-term metric. This method provides fast response capabilities for short-term risk control metrics through the above steps, further ensuring that the risk control system can detect potential risks in the shortest possible time.

[0098] In the specific implementation process, the pre-storage area in the system is designed as a high-speed memory area, and usually the Redis in-memory database is used. This is because Redis provides excellent data read and write performance, can quickly access data, and meet the requirements of real-time computing. When an event occurs, the system will parse the dimension fields in the event object, such as mobile phone numbers, card numbers, or device numbers, etc. These fields are the key to calculating short-term metrics and are used to locate and extract relevant transaction flow information from the pre-storage area. According to the dimension fields, the system retrieves all transaction flow information related to the current event from Redis. This information has been filtered according to the time window and only contains data within the time range defined by the short-term metrics. After obtaining the transaction flow information, the system will verify its format to ensure that the data meets the input requirements of the calculation function. For example, if the calculation function requires a timestamp of the transaction time accurate to seconds, the system will check whether the time field in the flow information has been converted to the corresponding format. Each short-term metric is associated with one or more predefined calculation functions. These functions can be sum, average, maximum, or minimum, or even more complex statistical analysis functions, such as calculating the cumulative distribution of the number of transactions within a specific time window. The system calls the corresponding function from the configured calculation function library according to the definition of the short-term metric. The calculation function library is part of the system and contains all the preset calculation logics, ensuring the consistency and accuracy of the calculation. The called calculation function will process the transaction flow information obtained from the pre-storage area and perform relevant statistical analysis calculations. For example, for the metric "the transaction amount of the same card number is greater than 500 within 5 minutes", the calculation function will calculate the sum of all transaction flow amounts of the same card number in the past 5 minutes. The obtained risk control metric value will be stored in the system as a decision-making basis. For short-term metrics, the calculation results can be stored in memory for subsequent rapid access and judgment by the rule engine. If the calculation results need to be persisted, they can also be stored in the database.

[0099] In some alternative embodiments, the above interception unit further includes a second acquisition module and a second calculation module. The second acquisition module is used to acquire the transaction flow data corresponding to the long-term metric at every preset time interval; the second calculation module is used to calculate the transaction flow data within the preset time interval to obtain the risk control metric value corresponding to the long-term metric. This method realizes the efficient and real-time processing of long-term metrics by setting the above preset time interval for regular calculation of long-term metrics and combining the data stream processing ability of Flink and the high-speed caching technology of Redis.

[0100] Specifically, the time window of the long-term indicator is often greater than 7 days, which means that a large amount of historical transaction flow data needs to be processed. Direct calculation during real-time event processing may lead to calculation delays and excessive resource consumption. Therefore, the system needs to set a reasonable preset time interval for periodically calculating the value of the long-term indicator. This time interval can be determined according to business requirements and system performance. For example, it can be set to once per hour, once per day, or once per week. The setting of the preset time interval is also based on the consideration of resource optimization to ensure that the system does not consume excessive computing resources when processing large-scale data, while maintaining the real-time and efficient data processing. A too short interval may lead to frequent calculations and resource waste, while a too long interval may affect the timeliness of indicator updates. At the beginning of each preset time interval, the system extracts the transaction flow data within the time window related to the long-term indicator from the long-term data storage (such as a distributed file system or a database). For example, if the time window of the long-term indicator is 30 days, the system extracts all transaction flow data within the past 30 days at the beginning of each hour. Flink can be configured to perform time window calculations on an hourly basis to ensure the real-time nature of the calculation results.

[0101] In the specific implementation process, before obtaining the transaction data, the method further includes a third acquisition unit and a configuration unit. The third acquisition unit is used to acquire at least an index calculation function, a calculation window, and calculation fields, where the index calculation function is a function for index calculation, and the calculation window represents the time window of the calculation; the configuration unit is used to configure an index calculation model at least according to the index calculation function, the calculation window, and the calculation fields, where the index calculation model is used to calculate and obtain the risk control index value. By integrating the function library, defining the time window, and extracting the calculation fields, the method constructs a set of index calculation models that can efficiently calculate the risk control index value, can flexibly adapt to changes in business requirements, and is the key technical support for realizing accurate and real-time risk control.

[0102] Specifically, the system is designed with a rich set of index calculation function libraries, including but not limited to basic mathematical operation functions (such as summation, average value, maximum value, minimum value, etc.) and more complex statistical analysis functions (such as the maximum distance of devices, the average number of daily transactions, etc.). These functions are preset in the system and can be called according to the specific requirements of the index. The calculation window is a key attribute in the index definition and is used to limit the time range of index calculation. For example, the time window for "the transaction amount within 5 minutes with the same card number is greater than 500" is 5 minutes. The time window of the long-term indicator may be greater than 7 days and needs to be processed through a real-time calculation framework such as Flink. Each risk control index involves one or more calculation fields, which are extracted from the transaction flow data and used to perform specific calculation operations. For example, for the index of calculating "the transaction amount within 5 minutes with the same card number", the calculation fields include the card number and the transaction amount.

[0103] Based on the metric calculation function, calculation window, and calculation fields, the system constructs a metric calculation model. The structural design of the model needs to consider the real-time nature, accuracy, and scalability of the calculations to ensure it can adapt to different business scenarios and risk control requirements. Each metric calculation model needs to be configured with specific parameters, including the parameters of the calculation function, the length of the time window, and the selection of calculation fields, etc. These parameters determine the calculation logic and execution details of the model and are the basis for the model to run. The metric calculation model needs to have dynamic adaptability and be able to automatically adjust the calculation logic according to changes in business requirements and real-time updates of data. For example, when new transaction flow data arrives, the model can instantly update the calculation results to ensure that risk control decisions are based on the latest and most accurate data. Considering the complexity and diversity of the business, the metric calculation model supports multi-dimensional configuration and can simultaneously process the calculation of risk control metrics based on different fields or combinations of fields. This flexibility enables the system to more precisely identify and evaluate risks, improving the accuracy and effectiveness of risk control.

[0104] The rapid identification device for transaction abnormal events includes a processor and a memory. The above-mentioned first acquisition unit, division unit, interception unit, etc. are all stored in the memory as program units and are executed by the processor to implement the corresponding functions. The above-mentioned modules are all located in the same processor; or, the above-mentioned each module is located in different processors in any combined form.

[0105] The processor contains a kernel, and the kernel retrieves the corresponding program units from the memory. One or more kernels can be set, and the stability of the risk control calculation method can be improved by adjusting the kernel parameters.

[0106] The memory may include non-permanent memory in a computer-readable medium, forms such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash memory (flash RAM), and the memory includes at least one storage chip.

[0107] An embodiment of the present invention provides a computer-readable storage medium, where the computer-readable storage medium includes a stored program. When the program runs, it controls the device where the computer-readable storage medium is located to execute the rapid identification method for transaction abnormal events.

[0108] An embodiment of the present invention provides an electronic device, including a processor, a memory, and a program stored on the memory and executable on the processor. When the processor executes the program, it implements the rapid identification method for transaction abnormal events.

[0109] The devices herein can be servers, PCs, PADs, mobile phones, etc.

[0110] The present application also provides a computer program product, including a computer program, which, when executed by a processor, implements the method for quickly identifying transaction anomaly events described in the various embodiments of the present application.

[0111] Obviously, those skilled in the art should understand that the above-mentioned modules or steps of the present invention can be implemented by a general-purpose computing device. They can be concentrated on a single computing device or distributed on a network composed of multiple computing devices. They can be implemented by program codes executable by the computing device. Thus, they can be stored in a storage device and executed by the computing device. And in some cases, the steps shown or described can be executed in a different order than here, or they can be separately fabricated into individual integrated circuit modules, or multiple modules or steps among them can be fabricated into a single integrated circuit module for implementation. In this way, the present invention is not limited to any specific combination of hardware and software.

[0112] Those skilled in the art should understand that the embodiments of the present application can be provided as a method, a system, or a computer program product. Therefore, the present application can take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware aspects. Moreover, the present application can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program codes.

[0113] The present application is described with reference to the flowcharts and / or block diagrams of methods, apparatuses (systems), and computer program products according to the embodiments of the present application. It should be understood that each flow and / or block in the flowcharts and / or block diagrams, as well as the combination of flows and / or blocks in the flowcharts and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to the processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing devices to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing devices generate a device for implementing the functions specified in Figure 1 one or more flows and / or blocks Figure 1 one or more blocks.

[0114] These computer program instructions can also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer-readable memory generate a manufactured article including an instruction device, and the instruction device implements the functions specified in Figure 1 one or more flows and / or blocks Figure 1 one or more blocks.

[0115] These computer program instructions can also be loaded onto a computer or other programmable data processing device, so that a series of operation steps are executed on the computer or other programmable device to generate a computer-implemented process, and thus the instructions executed on the computer or other programmable device provide for implementing the process Figure 1 one process or multiple processes and / or blocks Figure 1 steps for the functions specified in one block or multiple blocks.

[0116] In a typical configuration, a computing device includes one or more processors (CPUs), an input / output interface, a network interface, and memory.

[0117] The memory may include non-permanent memory in the form of computer-readable media, random access memory (RAM) and / or non-volatile memory such as read-only memory (ROM) or flash memory (flash RAM). The memory is an example of computer-readable media.

[0118] Computer-readable media includes permanent and non-permanent, removable and non-removable media that can store information by any method or technology. The information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassette tapes, magnetic disk storage or other magnetic storage devices, or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transitory media such as modulated data signals and carrier waves.

[0119] It should also be noted that the term "comprising", "including" or any other variant thereof is intended to cover non-exclusive inclusion, so that a process, method, commodity or device including a series of elements not only includes those elements, but also includes other elements not expressly listed, or elements inherent to such process, method, commodity or device. Without further limitation, an element defined by the statement "including one..." does not exclude the existence of additional identical elements in the process, method, commodity or device including the element.

[0120] From the above description, it can be seen that the above embodiments of the present application achieve the following technical effects:

[0121] 1), In the method for quickly identifying transaction anomaly events of this application, transaction data is obtained. The transaction data includes at least an event identification code, a risk control indicator, and a time window corresponding to the risk control indicator. The event identification code is the unique identification code representing the transaction event. The risk control indicator is an indicator used to determine the risk of the transaction event. The time window represents the length of the time statistical window of the risk control indicator; the risk control indicators are divided into short-term indicators and long-term indicators according to the time window in the transaction data. The short-term indicator represents a risk control indicator with a time window less than a preset time threshold, and the long-term indicator represents a risk control indicator with a time window greater than or equal to the preset time threshold; the short-term indicators are calculated, and the Flink distributed stream processing framework is used to calculate the long-term indicators to obtain risk control indicator values. When the risk control indicator values are greater than the preset threshold, transaction interception is performed to avoid the occurrence of transaction anomaly events. Compared with the prior art where the stability of the risk control calculation method is poor and financial abnormal behaviors cannot be detected in time, ultimately resulting in property losses of users, this application can divide the risk control indicators into short-term indicators and long-term indicators through the time window and calculate them separately, avoiding the problem of excessive memory occupation caused by simultaneous calculation of indicators, resulting in poor stability or jamming, so as to quickly identify financial abnormal behaviors and avoid property losses of users. Therefore, it can solve the problem in the prior art that the stability of the risk control calculation method is poor, so that financial abnormal behaviors cannot be detected in time, ultimately resulting in property losses of users, and achieve the problem of timely identifying financial abnormal behaviors and avoiding property losses of users by improving the stability of the risk control calculation method.

[0122] The above are only the preferred embodiments of this application and are not used to limit this application. For those skilled in the art, various changes and modifications can be made to this application. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of this application shall be included in the protection scope of this application.

Claims

1. A method for quickly identifying abnormal transaction events, characterized in that: include: Acquire transaction data, wherein the transaction data at least includes an event identification code, a risk control indicator, and a time window corresponding to the risk control indicator, wherein the event identification code is a unique identification code representing a transaction event, the risk control indicator is an indicator used to determine the risk of the transaction event, and the time window represents the length of a time statistical window of the risk control indicator; Dividing the risk control indicator into a short-term indicator and a long-term indicator according to the time window in the transaction data, wherein the short-term indicator represents the risk control indicator when the time window is less than a preset time threshold, and the long-term indicator represents the risk control indicator when the time window is greater than or equal to the preset time threshold; The short-term indicator is calculated, and the long-term indicator is calculated using the Flink distributed stream processing framework to obtain a risk control indicator value. When the risk control indicator value is greater than a preset threshold, the transaction is intercepted to avoid the occurrence of abnormal transaction events.

2. The method for rapid identification of abnormal transaction events according to claim 1, characterized in that: The risk control indicators are divided into short-term indicators and long-term indicators according to the time window, including: Determine the risk control indicator whose time window is less than the preset time threshold as the short-term indicator; The risk control indicator whose time window is greater than or equal to the preset time threshold is determined as the long-term indicator.

3. The method for rapid identification of abnormal transaction events according to claim 1, characterized in that: After acquiring the transaction data, the method further includes: Parsing the transaction data to obtain indicator dimensions, wherein each indicator dimension corresponds to one or more risk control indicators; The risk control indicator corresponding to each indicator dimension is stored in an indicator set, wherein each indicator dimension corresponds to one indicator set.

4. The method for rapid identification of abnormal transaction events according to claim 1, characterized in that: After dividing the risk control indicator into a short-term indicator and a long-term indicator according to the time window in the transaction data, the method further includes: Acquire transaction flow information corresponding to the short-term indicator, wherein the transaction flow information at least includes a transaction account and a transaction amount; The transaction flow information corresponding to the short-term indicator is stored in a pre-storage area.

5. The method for rapid identification of abnormal transaction events according to claim 4, characterized in that: The short-term indicators are calculated, including: Acquire the transaction flow information from the pre-storage area; Obtain a calculation function corresponding to the short-term indicator, use the calculation function to calculate the transaction flow information, and obtain the risk control indicator value corresponding to the short-term indicator.

6. The method for rapid identification of abnormal transaction events according to claim 1, characterized in that: The Flink distributed stream processing framework is used to calculate the long-term indicators, including: Obtaining transaction flow data corresponding to the long-term indicator at preset time intervals; The transaction flow data within the preset time interval is calculated to obtain the risk control indicator value corresponding to the long-term indicator.

7. The method for rapid identification of abnormal transaction events according to claim 1, characterized in that: Before acquiring the transaction data, the method further includes: At least an indicator calculation function, a calculation window, and a calculation field are obtained, wherein the indicator calculation function is a function used for indicator calculation, and the calculation window represents a time window for calculation; An indicator calculation model is configured at least according to the indicator calculation function, the calculation window and the calculation field, wherein the indicator calculation model is used to calculate the risk control indicator value.

8. A device for quickly identifying abnormal transaction events, characterized in that: include: a first acquisition unit, configured to acquire transaction data, wherein the transaction data at least includes an event identification code, a risk control indicator, and a time window corresponding to the risk control indicator, wherein the event identification code is a unique identification code representing a transaction event, the risk control indicator is an indicator used to determine the risk of the transaction event, and the time window indicates the length of a time statistical window of the risk control indicator; a dividing unit, configured to divide the risk control indicator into a short-term indicator and a long-term indicator according to the time window in the transaction data, wherein the short-term indicator represents the risk control indicator when the time window is less than a preset time threshold, and the long-term indicator represents the risk control indicator when the time window is greater than or equal to the preset time threshold; The interception unit is used to calculate the short-term indicator and the long-term indicator using the Flink distributed stream processing framework to obtain the risk control indicator value, and intercept the transaction when the risk control indicator value is greater than a preset threshold to avoid the occurrence of abnormal transaction events.

9. A computer-readable storage medium, characterized in that: The computer-readable storage medium includes a stored program, wherein when the program is executed, the device where the computer-readable storage medium is located is controlled to execute the method for quickly identifying abnormal transaction events as described in any one of claims 1 to 7.

10. An electronic device, characterized in that: include: One or more processors, a memory, and one or more programs, wherein the one or more programs are stored in the memory and are configured to be executed by the one or more processors, and the one or more programs include a method for quickly identifying abnormal transaction events as described in any one of claims 1 to 7.

Images