A risk detection method, device, electronic device and readable storage medium

Abstract

This application relates to the field of computer technology, and in particular, to a risk detection method, device, electronic device, and readable storage medium. The method includes storing the obtained target transaction data of the target user in the Kafka message system; reading the target transaction data in the Kafka message system by a program based on Apache Storm; analyzing and processing the target transaction data by a program based on Apache Storm and the Esper complex event processing component and outputting an analysis result; and if the analysis result meets the preset risk warning rule, starting a risk warning. The risk detection solution provided by this application realizes high availability of 7*24 hours, supports online horizontal expansion, provides business personnel with an efficient rule editing function, and supports historical transaction regression verification and query, and supports a data volume of tens of billions.

Description

Technical Field

[0001] This application relates to the technical field of computer data processing, and in particular, to a risk detection method, device, electronic device, and readable storage medium. Background Art

[0002] Online payment has been favored by consumers due to its convenience and close correlation with daily life, and has become the mainstream transaction payment method. However, online payment has also led to more transaction fraud risks. Currently, the industry mainly uses rule-based methods to deal with transaction fraud risks in online payment. For example, traditional transaction risk detection systems based on relational databases mainly use SQL query statements in database tables, that is, risk control rules. The number of SQL queries to the database = the number of risk control rules * the current instantaneous transaction volume. There is no problem when the daily risk detection data volume is small. However, when the instantaneous transaction volume of the customer group surges (such as a large number of customers concentrating on consumption transactions after zero o'clock on Double Eleven), after the number of SQL queries to the database is proportionally enlarged (i.e., read amplification), the database performance drops sharply, resulting in a sharp decline in the system processing ability, and ultimately leading to a delay in risk transaction alarms and untimely corresponding risk control measures, causing losses to customers and financial companies. Summary of the Invention

[0003] The purpose of this application aims to solve at least one of the above technical defects. The technical solutions adopted in this application are as follows:

[0004] In a first aspect, an embodiment of this application provides a risk detection method, and the method includes:

[0005] Store the obtained target transaction data of the target user in the Kafka message system;

[0006] Read the target transaction data in the Kafka message system based on a program of Apache Storm;

[0007] Analyze and process the target transaction data based on a program of Apache Storm and Esper complex event processing components and output an analysis result;

[0008] If the analysis result meets a preset risk warning rule, start a risk warning.

[0009] Optionally, the storing the obtained target transaction data of the target user in the Kafka message system includes:

[0010] Extract at least one feature information of the target transaction data; wherein the target transaction data at least includes the following feature information: target user identity information, target transaction card information, target transaction type, target transaction direction, target transaction time, target transaction geographical location, target transaction amount;

[0011] Divide the target transaction data into N shards according to the at least one piece of extracted feature information;

[0012] Store the N shards in the Kafka messaging system.

[0013] Optionally, before analyzing and processing the target transaction data by a program based on Apache Storm and Esper complex event processing components, the method further includes:

[0014] Store the target transaction data of the N shards in the Cassandra database.

[0015] Optionally, the analysis and processing of the target transaction data by the program based on Apache Storm and Esper complex event processing components includes:

[0016] Parse the feature information in the target transaction data of the N shards and process it into formatted data that can be processed by Esper;

[0017] Store the processed formatted target transaction data in the Cassandra database;

[0018] Generate risk detection rules according to the parsed feature information and the pre-stored rule configuration table;

[0019] Esper reads the target transaction data in the Cassandra database and analyzes and processes the target transaction data according to the risk detection rules.

[0020] Optionally, the initiation of the risk alarm includes:

[0021] Send the risk alarm information to the Kafka messaging system;

[0022] The Kafka messaging system sends a risk handling message to the system according to the risk alarm information.

[0023] Optionally, the program based on Apache Storm and Esper complex event processing components reads the target data of the N shards respectively.

[0024] Optionally, the method further includes:

[0025] Construct a time window in the Esper component; wherein the time window has an editable display interface;

[0026] The time window can be used to write target transaction data and risk detection rules.

[0027] Second aspect, an embodiment of the present application provides a risk detection device, the device includes: a reading module, a storage module, a processing module, an output module, a judgment module and an alarm module, wherein,

[0028] The reading module is used to obtain the target transaction data of the target user;

[0029] The storage module is used to store the obtained target transaction data of the target user in the Kafka message system;

[0030] The reading module is further used to read the target transaction data in the Kafka message system based on the program of Apache Storm;

[0031] The processing module is further used to analyze and process the target transaction data based on the programs of Apache Storm and the Esper complex event processing component;

[0032] The output module is further used to output the analysis result;

[0033] The judgment module is used to judge whether the analysis result conforms to the preset risk alarm rule;

[0034] The alarm module is used to start the risk alarm

[0035] Third aspect, an embodiment of the present invention provides an electronic device, including a processor and a memory;

[0036] The memory is used to store operation instructions;

[0037] The processor is used to execute the above risk detection method by calling the operation instructions.

[0038] Fourth aspect, a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, the above risk detection method is implemented.

[0039] The risk detection solution disclosed in the embodiments of the present application stores the obtained target transaction data of the target user in the Kafka message system; reads the target transaction data in the Kafka message system based on the program of Apache Storm; analyzes and processes the target transaction data based on the programs of Apache Storm and the Esper complex event processing component and outputs the analysis result; if the analysis result conforms to the preset risk alarm rule, the risk alarm is started. The beneficial effects brought by the technical solution provided by the embodiments of the present application are:

[0040] (1) The system relies on distributed components such as Kafka message queue, Storm distributed computing framework, and Cassandra distributed database, avoiding single-node failures of the system and achieving high availability for 7 * 24 hours. It also supports online horizontal scaling, and when scaling, the system does not need to be shut down and the business can operate normally.

[0041] (2) It provides an efficient rule editing function for professional data analysis / risk control personnel. The new risk control rules are completely edited by business personnel themselves. When adding / modifying rules, they can take effect immediately without the intervention of technical personnel.

[0042] (3) The monitoring time window period is extended, and rule alarms support data volumes in the hundreds of millions;

[0043] (4) It supports historical transaction regression verification and query, and supports data volumes in the tens of billions. Description of the Drawings

[0044] To more clearly illustrate the technical solutions in the embodiments of the present application, the following will briefly introduce the drawings required for the description of the embodiments of the present application.

[0045] Figure 1 It is a schematic flowchart of a risk detection method provided by an embodiment of the present application;

[0046] Figure 2 It is a schematic structural diagram of a risk detection device provided by an embodiment of the present application;

[0047] Figure 3 It is a schematic structural diagram of an electronic device provided by an embodiment of the present application. Detailed Embodiments

[0048] The following will describe in detail the embodiments of the present application. The examples of the embodiments are shown in the drawings, where the same or similar reference numerals indicate the same or similar elements or elements with the same or similar functions from beginning to end. The embodiments described below with reference to the drawings are exemplary and are only used to explain the present application and should not be construed as a limitation of the present invention.

[0049] Those skilled in the art of the present technology can understand that unless specifically stated otherwise, the singular forms "a", "an", "the", and "said" used herein may also include the plural forms. It should be further understood that the term "comprising" used in the specification of the present application means the presence of the described features, integers, steps, operations, elements, and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or their groups. The term "and / or" used herein includes all or any unit and all combinations of one or more related listed items.

[0050] To introduce the embodiments of the present application more clearly, some definitions, concepts or devices that may be used in the embodiments are introduced below:

[0051] MySQL is an open-source relational database management system (RDBMS) that uses the most common database management language - Structured Query Language (SQL) for database management.

[0052] Kafka is an open-source stream processing platform developed by the Apache Software Foundation, written in Scala and Java. Kafka is a high-throughput distributed publish-subscribe messaging system that can process all action stream data of consumers in a website.

[0053] Apache Storm is a free and open-source distributed real-time computing system. It simplifies the reliable processing of stream data and enables real-time batch processing like Hadoop. Storm is very simple and can be used in any programming language. Apache Storm is developed using Clojure.

[0054] Apache Cassandra is an open-source distributed database management system developed by Facebook for storing extremely large amounts of data. It is distributed, column-based structured, and highly scalable. Cassandra is a hybrid non-relational database similar to Google's BigTable. The main feature of Cassandra is that it is not a single database but a distributed network service composed of a cluster of database nodes. A write operation to Cassandra will be replicated to other nodes, and a read operation to Cassandra will also be routed to a certain node for reading. For a Cassandra cluster, it is relatively easy to expand the performance by simply adding nodes to the cluster.

[0055] Structured Query Language, abbreviated as SQL, is a special-purpose programming language, a database query and programming language used for accessing data and querying, updating, and managing relational database systems.

[0056] Esper is a complex event processing component that runs embedded in a Java process.

[0057] As described above, the industry mainly adopts rule-based methods to address the transaction fraud risks in online payments. Currently, there are the following technical problems with this risk detection method: (1) When the transaction data surges, the performance of the database will drop sharply in this method, resulting in a sharp decline in the system processing capacity, and ultimately leading to delays in risk transaction alarms and untimely corresponding risk control measures. At the same time, the horizontal scalability of relational databases is average, and the amount of data they support is in the tens of millions level, making it difficult to quickly expand capacity and improve the system processing capacity. (2) Regarding transaction risks, various new fraud methods change rapidly and emerge in an endless stream, and risk control rules need to be quickly adjusted to respond to the changes. However, when the distributed stream computing component calculates the risk characteristics related to transactions, every time a new risk characteristic is added, technical personnel need to add new coding to implement it, and the implementation cycle is long. (3) Currently, this method basically uses caching transaction records to implement, but the data in the cache system is volatile and non-retraceable, which is extremely unfriendly to the regression verification of risk control rules and affects the interpretability of alarm transactions. Based on this, this application discloses a risk detection solution to at least solve one of the above technical problems.

[0058] The technical solution of this application and how this technical solution solves the above technical problems will be described in detail below with specific embodiments in conjunction with the accompanying drawings. These specific embodiments below can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments. The embodiments of this application will be described below in conjunction with the accompanying drawings.

[0059] To make the purpose, technical solution, and advantages of this application clearer, Figure 1 The flowchart of a risk detection method provided by an embodiment of this application is disclosed, as Figure 1 shown, the risk detection method includes:

[0060] S101. Store the target transaction data of the target user obtained in the Kafka message system;

[0061] In this step, optionally, the method further includes extracting at least one feature information of the target transaction data; wherein the target transaction data at least includes the following feature information: target user identity information, target transaction card information, target transaction type, target transaction direction, target transaction time, target transaction geographical location, target transaction amount; dividing the target transaction data into N shards according to the at least one extracted feature information; storing the N shards in the Kafka message system. In an actual embodiment, the solution can be interpreted as follows: when a customer uses a credit card and generates customer credit card authorization transaction data at any moment, after real-time collection from the host of the credit card core system, each transaction is written as a message into the Topic of the distributed message component Kafka, forming an uninterrupted Kafka message stream or data stream. Specifically, when writing, feature fields such as the credit card number are used for data sharding. For example, the credit card number is used to determine the shard where the corresponding transaction data is written into Kafka, which are the N data shards in the distributed system.

[0062] Based on the embodiments of the present application, the problem of capacity expansion for storing target transaction information is solved. When the number of credit card customers increases or the transaction volume on Double Eleven suddenly surges, the capacity of the distributed message component Kafka can be increased by expanding and increasing the number of shards of the Kakfa Topic.

[0063] S102. A program based on Apache Storm reads the target transaction data in the Kafka message system;

[0064] In an optional embodiment of the present application, the risk control engine can be deployed on top of the Apache Storm cluster of the distributed streaming computing component. The risk control engine runs in a multi-process and multi-threaded manner, and each of its Java processes can subscribe to, consume, and process the messages of one or more corresponding shards in the Kafka Topic.

[0065] S103. A program based on Apache Storm and the Esper complex event processing component analyzes and processes the target transaction data and outputs an analysis result;

[0066] In the embodiments of the present application, Esper described is a complex event processing component embedded in a Java process. A time window is constructed in the Esper component; wherein the time window has an editable display interface; the time window can be used to write target transaction data and risk detection rules, and save multiple transaction messages of a certain credit card in chronological order in the time window in Esper memory. When within a certain time range (or within the time window), multiple transactions of a certain credit card in chronological order meet the preset risk detection rules, it is determined that these transactions trigger a risk warning. Similarly to the expansion of the above Kafka message system, by increasing the number of Java processes to increase the throughput of the monitored "time window", horizontal expansion can be achieved to improve the processing capacity of the risk detection engine.

[0067] S104. If the analysis result meets the preset risk warning rules, start the risk warning.

[0068] In an alternative embodiment, the implementation method of starting the risk warning in this step is to send the risk warning information to the message queue of the Kafka message system, that is, send the alarm transactions that trigger the rules to another Topic of the Kafka message system to trigger subsequent system handling, and the Kafka message system sends risk handling messages to the system according to the risk warning information. The risk handling messages include notifying card freezing, restricting transaction amounts, etc., or triggering interactions between the system and customers, and warning through SMS notifications, WeChat transaction confirmations, and intelligent voice outbound calls, which will not be elaborated here.

[0069] In an alternative embodiment of the present application, before or during the analysis and processing of the target transaction data by a program based on the Apache Storm and Esper complex event processing components, the method further includes: storing the target transaction data of the N shards in the Cassandra database. That is, when the system risk control engine is running, write the just-occurred credit card transaction data into the distributed database Cassandra, and at the same time read the historical transaction data of the card. The distributed database Cassandra has multiple shards, and all transaction data of a certain credit card is saved to a specific shard according to the hash algorithm.

[0070] Similarly to the expansion of the above Kafka message system, by increasing the number of nodes in the Cassandra database, the read and write performance can be improved to enhance the system processing capacity.

[0071] Since financial transaction data has the characteristics of time series data. For example, for the same card, the transactions that occur within a certain time range can be organized or arranged in the order of the transaction occurrence time. Therefore, financial transaction data is very suitable for being stored in a time series database. The distributed NoSQL database Cassandra is an excellent time series database. According to its characteristics, its write performance is extremely good. When designing the table, it should be optimized for query statements, and the query statements should be designed as queries for the specified RowKey. Based on this, this application uses the Cassandra database to record transaction data. The recording logic is that the table for storing card authorization transaction data (named tran_window) should use the card number as the PartitioningKey for partitioning, and the account number, customer number, etc. as secondary indexes; the transaction time is the Clustering Column and is arranged in reverse order, and the specific transaction information fields are organized according to the transaction timestamp. Logically, it can be abstracted as storing all transaction data of the same card number in one row of the Cassandra table.

[0072] In the above embodiments of this application, from the level of the overall system architecture, through the integration and integration of the above three distributed components Apache Kafka, Apache Storm, and Apache Cassandra, a complete financial transaction risk detection system based on distributed complex event processing can be formed. It avoids single-node failures of the system and realizes high availability of 7*24 hours. At the same time, it supports online horizontal expansion, and when expanding, the system does not need to be shut down and the business can proceed normally.

[0073] In an optional embodiment of itself, optionally, the program based on the Apache Storm and Esper complex event processing components analyzes and processes the target transaction data, including:

[0074] Parse the feature information in the target transaction data of N shards and process it into format data that can be processed by Esper;

[0075] Store the processed format target transaction data in the Cassandra database;

[0076] Generate risk detection rules according to the parsed feature information and the pre-stored rule configuration table;

[0077] Esper reads the target transaction data in the Cassandra database and analyzes and processes the target transaction data according to the risk detection rules.

[0078] In order to better introduce the risk detection solution in the above embodiments, the solution of this application is introduced as follows in combination with the actual process of the bank card transaction process:

[0079] Step 1: Write the obtained transaction data into the Kafka Message queue: Each message is an independent authorized transaction data.

[0080] Step 2: Parse the Kafka message data: Parse and decode the authorized transaction message, and convert the format of each feature field in the message (such as credit card number, customer ID number, transaction amount, acquirer number, merchant number of the transaction, transaction time, etc.) into the format data that can be processed by Esper.

[0081] Step 3: Generate risk detection rules according to the parsed feature information and the pre-stored rule configuration table: Generate derivative variables required for executing the rules according to the original feature field information in the message. For example, judge the city where the customer is from according to the first six digits of the customer ID number in the message, judge the city where the transaction is located according to the acquirer number, and judge whether the customer is a high-end customer according to the ID number, etc. These rule variables can be obtained by querying the built-in parameter table, white list, and gray list of the system.

[0082] Step 4: Store the processed formatted target transaction data in the Cassandra database: Persist the transaction data in the message into the Cassandra database.

[0083] Step 5: In the Cassandra query historical transaction link, query and prepare the card-related data for the rule judgment in the next step. Specifically, obtain the credit card number in the message, query and obtain the card historical transaction data from the Cassandra database, and at the same time query and obtain the long-term risk features related to the card (such as whether there have been overseas transactions on the card in the past year). The long-term risk features can be calculated and statistically analyzed by distributed offline computing components such as Facebook Presto at regular intervals, which will not be elaborated here.

[0084] Step 6: Esper reads the target transaction data in the Cassandra database and analyzes and processes the target transaction data according to the risk detection rules: In the memory of the program, use the Esper component for complex event processing, continuously and real-time analyze the event stream / message stream of the customer's card transactions, determine which transactions may have fraud risks, and send the transactions that trigger the rules as an alarm (Alert) to the next link KafkaAlertBolt, and ignore the transactions that do not trigger the rules.

[0085] Step 7: Send the risk warning information to the Kafka message system to trigger risk handling: Send the warning transactions that trigger the rules to another Topic in the Kafka message system to trigger subsequent system handling, such as card freezing, transaction amount limitation, etc.; or trigger the interaction between the system and the customer, such as SMS notification, WeChat transaction confirmation, intelligent voice outbound call, etc. Details are not elaborated here.

[0086] In the embodiment of the present application, a time window can be constructed in the Esper component. As mentioned above, the time window has an editable display interface; the time window can be used to write target transaction data and risk detection rules. In the field of financial transaction risk detection, if it is necessary to implement some conditional judgments, or rule judgments, on the current financial transaction events and the historical transaction data of the same card, customer, etc., using the unique SQL syntax provided by Esper, it can be converted into an SQL query on the data in the time window (table) in memory. By performing various subqueries, aggregations, etc. on the LastFact and DataWindow tables, the single transaction, frequency, and statistical rules for financial transactions can be realized. Examples of statistical rules are as follows:

[0087] (1) Single transaction rule, determine whether the current transaction meets certain conditions. For example, the RMB transaction amount of the current transaction is greater than 1000

[0088] (2) Frequency rule, the current transaction meets specific conditions, and the historical transactions meet certain other conditions. For example, the RMB transaction amount of the current transaction on the card is greater than 1000, and there is a transaction with an RMB transaction amount greater than 2000 within 5 minutes

[0089] (3) Statistical rule, the current transaction meets specific conditions, and the statistical value of the historical transactions meets a certain condition. For example, the current transaction is a successful consumption transaction and the cumulative successful transaction amount of the same card on the same day is greater than 100,000 RMB.

[0090] Based on Figure 1 the risk detection method provided by the embodiment shown, Figure 2 Figure shows a risk detection device provided by an embodiment of the present application. As Figure 2 shown, the device mainly includes: a 201 reading module, a 202 storage module, a 203 processing module, a 204 output module, a 205 judgment module, and a 206 warning module. Among them,

[0091] The 201 reading module is used to obtain the target transaction data of the target user;

[0092] The 202 storage module is used to store the obtained target transaction data of the target user in the Kafka message system;

[0093] The 202 reading module is further configured to read target transaction data in the Kafka message system based on a program of Apache Storm;

[0094] The 203 processing module is further configured to analyze and process the target transaction data based on a program of Apache Storm and an Esper complex event processing component;

[0095] The 204 output module is further configured to output an analysis result;

[0096] The 205 judgment module is configured to judge whether the analysis result conforms to a preset risk warning rule;

[0097] The 206 warning module is configured to initiate a risk warning.

[0098] In an alternative embodiment, the reading module extracts at least one feature information of the target transaction data; wherein the target transaction data at least includes the following feature information: target user identity information, target transaction card information, target transaction type, target transaction direction, target transaction time, target transaction geographical location, target transaction amount;

[0099] The apparatus further includes a data processing module, configured to divide the target transaction data into N shards according to the extracted at least one feature information;

[0100] The storage module is configured to store the N shards in the Kafka message system.

[0101] In an alternative embodiment, the storage module is configured to store the target transaction data of the N shards in a Cassandra database.

[0102] The data processing module, wherein the data processing module is configured to parse the feature information in the target transaction data of N shards and process it into format data that can be processed by Esper;

[0103] The storage module stores the processed format target transaction data in a Cassandra database;

[0104] The data processing module generates a risk detection rule according to the parsed feature information and a pre-stored rule configuration table;

[0105] Esper reads the target transaction data in the Cassandra database and analyzes and processes the target transaction data according to the risk detection rule.

[0106] The initiating of the risk warning includes: sending the risk warning information to the Kafka message system;

[0107] The Kafka message system sends risk handling messages to the system according to the risk warning information.

[0108] In an optional embodiment of the present application, the programs based on the Apache Storm and Esper complex event processing components respectively read the target data of N shards.

[0109] In an optional embodiment of the present application, the method further includes:

[0110] Build a time window in the Esper component; wherein the time window has an editable display interface; the time window can be used to write target transaction data and risk detection rules.

[0111] It can be understood that each of the above modules of the risk detection device in this embodiment has the function of implementing the corresponding steps of the method in the Figure 1 embodiment shown. This function can be implemented by hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above functions. The above modules can be software and / or hardware, and the above modules can be implemented separately or integrated by multiple modules. For the function descriptions of the above modules, reference can specifically be made to the corresponding descriptions of the method in the Figure 1 embodiment shown, which will not be elaborated here.

[0112] An embodiment of the present application provides an electronic device, including a processor and a memory;

[0113] The memory is used to store operation instructions;

[0114] The processor is used to execute the risk detection method provided in any implementation manner of the present application by calling the operation instructions.

[0115] As an example, Figure 3 shows a schematic structural diagram of an electronic device applicable to an embodiment of the present application, as Figure 3 shown. The electronic device 2000 includes: a processor 2001 and a memory 2003. Among them, the processor 2001 and the memory 2003 are connected, such as connected through a bus 2002. Optionally, the electronic device 2000 may further include a transceiver 2004. It should be noted that in practical applications, the transceiver 2004 is not limited to one, and the structure of the electronic device 2000 does not constitute a limitation to the embodiments of the present application.

[0116] Among them, the processor 2001 is applied to the embodiment of the present application to implement the method shown in the above method embodiment. The transceiver 2004 may include a receiver and a transmitter. The transceiver 2004 is applied to the embodiment of the present application to implement the function of communicating between the electronic device of the embodiment of the present application and other devices when executed.

[0117] The processor 2001 may be a CPU (Central Processing Unit), a general-purpose processor, a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It can implement or execute various exemplary logical blocks, modules, and circuits described in connection with the disclosure of the present application. The processor 2001 may also be a combination that implements computing functions, such as a combination of one or more microprocessors, a combination of a DSP and a microprocessor, etc.

[0118] The bus 2002 may include a path for transmitting information between the above components. The bus 2002 may be a PCI (Peripheral Component Interconnect) bus, an EISA (Extended Industry Standard Architecture) bus, or the like. The bus 2002 may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 3 only a thick line is used to represent it in the figure, but it does not mean that there is only one bus or one type of bus.

[0119] The memory 2003 may be a ROM (Read Only Memory) or other type of static storage device that can store static information and instructions, a RAM (Random Access Memory) or other type of dynamic storage device that can store information and instructions, or it may also be an EEPROM (Electrically Erasable Programmable Read Only Memory), a CD-ROM (Compact Disc Read Only Memory), or other optical disc storage, optical disc storage (including compact discs, laser discs, optical discs, digital versatile discs, Blu-ray discs, etc.), magnetic disk storage media, or any other medium that can be used to carry or store the desired program code in the form of instructions or data structures and can be accessed by a computer, but is not limited thereto.

[0120] Optionally, the memory 2003 is used to store the application program code for executing the solution of the present application, and is controlled by the processor 2001 to execute. The processor 2001 is used to execute the application program code stored in the memory 2003 to implement the risk detection method provided in any embodiment of the present application.

[0121] The electronic device provided in the embodiment of the present application is applicable to any embodiment of the above method, and will not be described in detail here.

[0122] The embodiment of the present application provides a computer-readable storage medium, on which a computer program is stored, and when the program is executed by a processor, it implements the risk detection method shown in the above method embodiment.

[0123] The computer-readable storage medium provided in the embodiment of the present application is applicable to any embodiment of the above method, and will not be described in detail here.

[0124] The risk detection solution disclosed in the embodiment of the present application stores the obtained target transaction data of the target user in the Kafka message system; reads the target transaction data in the Kafka message system through a program based on Apache Storm; analyzes and processes the target transaction data through a program based on Apache Storm and the Esper complex event processing component and outputs an analysis result; if the analysis result meets the preset risk warning rule, a risk warning is initiated. The risk detection solution provided in the embodiment of the present application realizes high availability of 7*24 hours, supports online horizontal expansion, provides business personnel with an efficient rule editing function, and supports historical transaction regression verification and query, and supports a data volume of tens of billions.

[0125] It should be understood that although the steps in the flowchart of the drawings are shown in sequence according to the indication of the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless there is a clear indication in this article, the execution of these steps has no strict order limit, and they can be executed in other orders. Moreover, at least a part of the steps in the flowchart of the drawings may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily executed at the same time, but can be executed at different times, and their execution order is not necessarily sequential, but can be executed alternately or alternately with at least a part of other steps or sub-steps or stages of other steps.

[0126] The above are only partial embodiments of the present invention. It should be pointed out that for those of ordinary skill in the art, without departing from the principle of the present invention, several improvements and refinements can be made, and these improvements and refinements should also be regarded as the protection scope of the present invention.

Claims

1. A risk detection method, characterized in that, the method includes: Storing the target transaction data of the target user obtained in the Kafka message system; Reading the target transaction data in the Kafka message system based on a program of Apache Storm; Analyzing and processing the target transaction data based on a program of Apache Storm and Esper complex event processing components and outputting an analysis result, wherein at least one characteristic information of the target transaction data is extracted, and the processed formatted target transaction data is stored in the Cassandra database; Generating a risk detection rule according to the parsed characteristic information and the pre-stored rule configuration table; If the analysis result meets the preset risk warning rule, starting a risk warning; The method further includes: Building a time window in the Esper component; wherein the time window has an editable display interface; The time window can be used to write the target transaction data and the risk detection rule.

2. The risk detection method according to claim 1, characterized in that, The storing the target transaction data of the target user obtained in the Kafka message system includes: Extracting at least one characteristic information of the target transaction data; wherein the target transaction data at least includes the following characteristic information: target user identity information, target transaction card information, target transaction type, target transaction direction, target transaction time, target transaction geographical location, target transaction amount; Dividing the target transaction data into N shards according to the at least one extracted characteristic information; Storing the N shards in the Kafka message system.

3. The risk detection method according to claim 2, characterized in that, Before analyzing and processing the target transaction data based on a program of Apache Storm and Esper complex event processing components, the method further includes: Storing the target transaction data of the N shards in the Cassandra database.

4. The risk detection method according to claim 3, characterized in that, The analyzing and processing the target transaction data based on a program of Apache Storm and Esper complex event processing components includes: Parsing the characteristic information in the target transaction data of N shards and processing it into formatted data that can be processed by Esper; Esper reads the target transaction data in the Cassandra database and analyzes and processes the target transaction data according to the risk detection rule.

5. The risk detection method according to claim 4, characterized in that, The starting a risk warning includes: Sending a risk warning message to the Kafka message system; The Kafka message system sends a risk disposal message to the system according to the risk warning message.

6. The risk detection method according to claim 5, characterized in that, The program based on Apache Storm and Esper complex event processing components reads the target data of N shards respectively.

7. A risk detection device, characterized in that, The device includes: a reading module, a storage module, a processing module, an output module, a judgment module, and an alarm module, where the reading module is configured to obtain target transaction data of a target user; the storage module is configured to store the obtained target transaction data of the target user in the Kafka message system; the reading module is further configured to read the target transaction data in the Kafka message system based on a program of Apache Storm, where at least one characteristic information of the target transaction data is extracted, and the processed formatted target transaction data is stored in the Cassandra database; the processing module is further configured to perform analysis and processing on the target transaction data based on a program of Apache Storm and an Esper complex event processing component, where a risk detection rule is generated according to the parsed characteristic information and a pre-stored rule configuration table; wherein, a time window is constructed in the Esper component; wherein the time window has an editable display interface; the time window can be used to write the target transaction data and the risk detection rule; the output module is further configured to output an analysis result; the judgment module is configured to judge whether the analysis result conforms to a preset risk alarm rule; the alarm module is configured to initiate a risk alarm.

8. An electronic device characterized in that it includes a processor and a memory; the memory is configured to store operation instructions; the processor is configured to execute the method according to any one of claims 1-6 by calling the operation instructions.

9. A computer-readable storage medium characterized in that a computer program is stored on the storage medium, and when the computer program is executed by a processor, the method according to any one of claims 1-6 is implemented.

Images