Abnormal transaction detection method, device, equipment and computer-readable storage medium

Abstract

The present invention discloses a method for detecting abnormal transactions, which relates to the field of financial technology. The method obtains the transaction type of the current transaction when detecting the transaction instruction of the current transaction, and determines the verification rule corresponding to the current transaction based on the transaction type; obtains the transaction parameters of the current transaction, and verifies the transaction parameters of the current transaction based on the verification rule and the transaction parameters; when the current transaction passes the transaction parameter verification, obtains the target account information to which the current transaction belongs, and determines whether the current transaction meets the user profile of the target user based on the target user tag in the target account information; if the current transaction does not meet the user profile of the target user, the target transaction is subjected to abnormal processing. The present invention sets corresponding verification standards for each user, improves the accuracy of identifying transaction anomalies, and solves the technical problem of low efficiency in identifying abnormal transactions.

Description

Technical Field

[0001] The present invention relates to the technical field of financial technology (Fintech), and in particular to a method, apparatus, device, and computer-readable storage medium for detecting abnormal transactions. Background Art

[0002] With the advancement of computer technology, an increasing number of technologies (such as big data, distributed systems, blockchain, and artificial intelligence) are being applied to the financial sector, leading to a gradual shift towards Fintech (financial technology). For example, large commercial banks currently open Type II and III bank accounts remotely, electronically, rather than face-to-face. Because Type II and III account operations involve a wide range of stakeholders (such as partners, conduits, issuing banks, and clearing organizations), the opening channels are diverse and the procedures are relatively simple. Consequently, these bank accounts are susceptible to system vulnerabilities, fraud by criminals, and the proliferation of "freeloaders," leading to problems during account opening and transactions. These problems include opening accounts with false information, opening accounts under false pretenses, binding accounts to non-Type I accounts, and account theft. Traditional methods for identifying abnormal transactions primarily focus on identifying and controlling anomalies during account opening, transactions, and card binding. These traditional abnormal transaction identification rules are primarily based on expert-based rules, typically developed through accumulated experience and existing regulatory regulations. These rules are rigid and have a single standard for identifying anomalies, resulting in low efficiency in identifying abnormal transactions. Summary of the Invention

[0003] The main purpose of the present invention is to propose a method, device, equipment and computer-readable storage medium for detecting abnormal transactions, aiming to solve the technical problem of low efficiency in abnormal transaction identification caused by the fixed traditional transaction identification rules and the single abnormal identification standard.

[0004] To achieve the above object, the present invention provides a method for detecting abnormal transactions, which comprises the following steps:

[0005] When detecting a transaction instruction of a current transaction, obtaining the transaction type of the current transaction, and determining a verification rule corresponding to the current transaction according to the transaction type;

[0006] Acquiring transaction parameters of the current transaction, and performing transaction parameter verification on the current transaction according to the verification rule and the transaction parameters;

[0007] When the current transaction passes the transaction parameter verification, obtaining target account information to which the current transaction belongs, and judging whether the current transaction meets the user profile of the target user based on the target user tag in the target account information;

[0008] If the current transaction does not conform to the user profile of the target user, an exception is processed for the target transaction.

[0009] Optionally, when the current transaction passes the transaction parameter verification, the step of obtaining target account information to which the current transaction belongs, and judging whether the current transaction meets the user profile of the target user based on the target user tag in the target account information specifically includes:

[0010] When the current transaction passes the transaction parameter verification, obtaining target account information to which the current transaction belongs, and determining target consumption information corresponding to the target user based on the target user tag in the target account information, wherein the target consumption information includes a target consumption type and / or a target consumption amount;

[0011] The current transaction information of the current transaction is compared with the target consumption information to determine whether the current transaction meets the user profile of the target user, wherein the current transaction information includes the current transaction type and / or the current transaction amount.

[0012] Optionally, if the current transaction does not conform to the user profile of the target user, the step of performing exception processing on the target transaction specifically includes:

[0013] If the current transaction does not match the user profile of the target user, the preset user verification rules are called by the preset decision engine to perform user identity verification on the current user conducting the current transaction to determine whether the current user is the target user;

[0014] If it is determined that the current user is not the target user, the current transaction is rejected, and a reminder message of not being the user is generated and displayed to perform an exception process on the target transaction.

[0015] Optionally, before the step of, when detecting the transaction instruction of the current transaction, obtaining the transaction type of the current transaction and determining the verification rule corresponding to the current transaction according to the transaction type, the method further includes:

[0016] If a large number of trading instructions are received, the large number of trading instructions are divided into batches according to the preset time interval, and the batched trading instructions are added to the processing queue in order of receipt time;

[0017] The computing engine sequentially encapsulates each batch transaction instruction in the processing queue into each distributed transaction data set, and performs abnormal transaction detection processing on each distributed transaction data set.

[0018] Optionally, after the step of obtaining the transaction parameters of the current transaction and verifying the transaction parameters of the current transaction according to the verification rule and the transaction parameters, the method further includes:

[0019] When the current transaction fails to pass the transaction parameter verification, the current transaction is rejected, and a reminder message indicating that the current transaction information is abnormal is generated and displayed, so as to promptly handle the abnormal current transaction.

[0020] Optionally, before the step of obtaining target account information to which the current transaction belongs and determining whether the current transaction meets the user profile of the target user based on the target user tag in the target account information when the current transaction passes the transaction parameter verification, the step further includes:

[0021] Clustering user information using a preset clustering algorithm, and collecting user information and historical transaction information of each clustered user;

[0022] According to the user information, the historical transaction information and the preset tag setting rules, a corresponding user tag is set for each user, a user portrait corresponding to each user is generated, and the user portrait corresponding to each user is saved offline for offline calling.

[0023] Optionally, the step of obtaining the transaction parameters of the current transaction and verifying the transaction parameters of the current transaction according to the verification rule and the transaction parameters specifically includes:

[0024] Obtaining transaction parameters of the current transaction and determining whether the verification rule exists in the cache;

[0025] If the verification rule does not exist in the cache area, the verification rule is obtained from the database, and transaction parameter verification is performed on the current transaction according to the verification rule and the transaction parameters.

[0026] Optionally, the abnormal transaction detection method further includes:

[0027] When a rule setting instruction triggered by a user operation is received, the rule configuration information in the rule setting instruction is obtained to add a new verification rule and / or modify a historical verification rule.

[0028] In addition, to achieve the above-mentioned purpose, the present invention further provides a device for detecting abnormal transactions, the device comprising:

[0029] a verification rule determination module, configured to, upon detecting a transaction instruction of a current transaction, obtain a transaction type of the current transaction and determine a verification rule corresponding to the current transaction based on the transaction type;

[0030] a transaction parameter verification module, configured to obtain the transaction parameters of the current transaction and verify the transaction parameters of the current transaction according to the verification rules and the transaction parameters;

[0031] A user profile verification module is configured to obtain target account information of the current transaction when the current transaction passes the transaction parameter verification, and determine whether the current transaction conforms to the user profile of the target user based on the target user tag in the target account information;

[0032] The abnormal transaction processing module is used to perform abnormal processing on the target transaction if the current transaction does not meet the user profile of the target user.

[0033] Optionally, the user portrait verification module is further used to:

[0034] When the current transaction passes the transaction parameter verification, obtaining target account information to which the current transaction belongs, and determining target consumption information corresponding to the target user based on the target user tag in the target account information, wherein the target consumption information includes a target consumption type and / or a target consumption amount;

[0035] The current transaction information of the current transaction is compared with the target consumption information to determine whether the current transaction meets the user profile of the target user, wherein the current transaction information includes the current transaction type and / or the current transaction amount.

[0036] Optionally, the abnormal transaction processing module is further configured to:

[0037] If the current transaction does not match the user profile of the target user, the preset user verification rules are called by the preset decision engine to perform user identity verification on the current user conducting the current transaction to determine whether the current user is the target user;

[0038] If it is determined that the current user is not the target user, the current transaction is rejected, and a reminder message of not being the user is generated and displayed to perform an exception process on the target transaction.

[0039] Optionally, the abnormal transaction detection device further includes:

[0040] A transaction instruction batching module is used to batch the received large number of transaction instructions according to a preset time interval, and add the batched transaction instructions to the processing queue in order of receipt time;

[0041] The transaction data set encapsulation module is used to encapsulate the batch transaction instructions in the processing queue into distributed transaction data sets in sequence through a computing engine, and perform abnormal transaction detection processing on the distributed transaction data sets respectively.

[0042] In addition, to achieve the above-mentioned purpose, the present invention also provides an abnormal transaction detection device, which includes: a memory, a processor, and an abnormal transaction detection program stored on the memory and runnable on the processor. When the abnormal transaction detection program is executed by the processor, the steps of the abnormal transaction detection method described above are implemented.

[0043] In addition, to achieve the above-mentioned purpose, the present invention also provides a computer-readable storage medium, on which a program for detecting abnormal transactions is stored. When the program for detecting abnormal transactions is executed by a processor, the steps of the abnormal transaction detection method described above are implemented.

[0044] When the present invention detects the transaction instruction of the current transaction, it obtains the transaction type of the current transaction and determines the verification rules corresponding to the current transaction based on the transaction type; obtains the transaction parameters of the current transaction and verifies the transaction parameters of the current transaction based on the verification rules and the transaction parameters; when the current transaction passes the transaction parameter verification, it obtains the target account information to which the current transaction belongs and determines whether the current transaction conforms to the user profile of the target user based on the target user tag in the target account information; if the current transaction does not conform to the user profile of the target user, the target transaction is subjected to exception processing. Through the above manner, the present invention sets different verification rules for different transaction types and can automatically match corresponding verification rules according to the transaction type to perform parameter verification on the current transaction parameters. Then, when the current parameter verification passes, the user portrait verification is further performed on the current transaction, and corresponding verification standards are set for each user to improve the accuracy of identifying transaction anomalies, thereby solving the technical problem of low efficiency in identifying abnormal transactions caused by the fixed traditional transaction identification rules and the single abnormal identification standard. BRIEF DESCRIPTION OF THE DRAWINGS

[0045] Figure 1 Schematic diagram of the device structure of the hardware operating environment involved in the embodiment of the present invention;

[0046] Figure 2 2 is a flow chart of the first embodiment of the abnormal transaction detection method of the present invention.

[0047] The purpose, features and advantages of the present invention will be further described with reference to the accompanying drawings and in conjunction with the embodiments. DETAILED DESCRIPTION

[0048] It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention.

[0049] like Figure 1 As shown, Figure 1 It is a schematic diagram of the device structure of the hardware operating environment involved in the embodiment of the present invention.

[0050] The abnormal transaction detection device in the embodiment of the present invention may be a PC or a server device, on which a Java virtual machine runs.

[0051] like Figure 1 As shown, the abnormal transaction detection device may include: a processor 1001, such as a CPU, a network interface 1004, a user interface 1003, a memory 1005, and a communication bus 1002. Among them, the communication bus 1002 is used to realize the connection and communication between these components. The user interface 1003 may include a display screen (Display), an input unit such as a keyboard (Keyboard), and the user interface 1003 may also include a standard wired interface and a wireless interface. The network interface 1004 may optionally include a standard wired interface and a wireless interface (such as a WI-FI interface). The memory 1005 may be a high-speed RAM memory, or a stable memory (non-volatile memory), such as a disk memory. The memory 1005 may also be a storage device independent of the aforementioned processor 1001.

[0052] Those skilled in the art will understand that Figure 1 The device structure shown in the figure does not constitute a limitation of the device, and may include more or fewer components than shown in the figure, or combine certain components, or arrange the components differently.

[0053] like Figure 1 As shown, the memory 1005 as a computer storage medium may include an operating system, a network communication module, a user interface module, and an abnormal transaction detection program.

[0054] exist Figure 1 In the device shown, the network interface 1004 is mainly used to connect to the backend server and communicate data with the backend server; the user interface 1003 is mainly used to connect to the client (user end) and communicate data with the client; and the processor 1001 can be used to call the abnormal transaction detection program stored in the memory 1005 and perform the operations in the following abnormal transaction detection method.

[0055] Based on the above hardware structure, an embodiment of a method for detecting abnormal transactions of the present invention is proposed.

[0056] Reference Figure 2 , Figure 2This is a flow chart of a first embodiment of a method for detecting abnormal transactions according to the present invention. The method includes:

[0057] Step S10: upon detecting a transaction instruction of a current transaction, obtaining the transaction type of the current transaction, and determining a verification rule corresponding to the current transaction according to the transaction type;

[0058] Currently, all existing bank accounts are opened remotely, electronically, rather than face-to-face. Class II and III bank accounts involve multiple roles (partners, channels, issuing banks, clearing organizations, etc.), are opened through diverse channels, and have simple procedures. These accounts are prone to system vulnerabilities, fraud, and a variety of scammers, resulting in risks for users during both card opening and transactions. Key issues currently encountered include opening accounts with false information, impersonating others, binding accounts to non-Class I accounts, and account theft. Therefore, abnormal transaction identification is necessary during the transaction process. Currently, the main method for identifying abnormal transactions is through pre-configured rules, which identify and control anomalies during account opening, transactions, and card binding. However, existing abnormal transaction identification rules are primarily based on expert rules, typically developed through accumulated experience and existing regulatory rules. While these rules offer advantages in terms of interpretability and targetedness, they also offer disadvantages in terms of inability to identify real-time and unknown risks. Furthermore, the rules are relatively rigid and coarse-grained, meaning that almost everyone follows the same set of rules, making it difficult to identify anomalies based on user profiles. In this embodiment, in order to solve the above problems, a method for detecting abnormal transactions is provided. According to the transaction type of the current transaction, a corresponding verification rule is determined, and then the transaction parameters of the current transaction are verified according to the corresponding verification rule. After the transaction parameters of the current transaction are normal, the transaction information of the current transaction is further verified with the user tag corresponding to the target account for user portrait verification, thereby realizing targeted abnormal transaction identification.

[0059] Specifically, when a transaction instruction is detected, the transaction type of the current transaction to be verified is obtained, and the corresponding verification rules are determined in the rule cache or rule database based on the transaction type to perform an exception check on the current transaction. The verification rules can be pre-set in the rule configuration console. Specifically, the verification rules can be set according to the transaction scenario, such as account opening transactions, consumption transactions, or card binding transactions, corresponding to different transaction types and corresponding transaction parameters, and corresponding verification rules are set.

[0060] Step S20: Acquire transaction parameters of the current transaction, and verify the transaction parameters of the current transaction according to the verification rule and the transaction parameters;

[0061] In this embodiment, transaction parameters corresponding to the current transaction are obtained based on the transaction type, and then transaction parameter verification is performed on the transaction parameters according to the corresponding transaction parameter verification rules. The transaction parameter verification includes determining whether the transaction parameters meet parameter conditions or identifying transaction anomalies by calculating relevant transaction indicators.

[0062] Step S30, when the current transaction passes the transaction parameter verification, obtaining the target account information to which the current transaction belongs, and judging whether the current transaction meets the user profile of the target user based on the target user tag in the target account information;

[0063] In this embodiment, when the transaction parameters of the current transaction pass the transaction parameter verification, the user profile verification is further performed on the current transaction. The target account information described in the current transaction is obtained, that is, the account information of the current transaction payment. And the target user tag pre-set in the target account information is obtained, and the user profile verification is performed on the current user performing the current transaction according to the target user tag. Specifically, the consumption type or consumption amount corresponding to the target account corresponding to the target account information can be determined according to the target user tag. For example, if the target user with the user tag "otaku" generally consumes electronic products or takeaway food, and there is no abnormality in the consumption amount and the number of consumptions, then it is judged that the current transaction does not meet the user profile of the target user. If the current transaction type is outdoor products, and the consumption amount exceeds the target user's historical consumption average or the number of consumptions exceeds the average, then it is judged that the current transaction does not meet the user profile of the target user.

[0064] Furthermore, the step S20 specifically includes:

[0065] Obtaining transaction parameters of the current transaction and determining whether the verification rule exists in the cache;

[0066] If the verification rule does not exist in the cache area, the verification rule is obtained from the database, and transaction parameter verification is performed on the current transaction according to the verification rule and the transaction parameters.

[0067] In this embodiment, in order to improve the detection efficiency of abnormal transactions, when a user is detected logging into the transaction system, the user profile corresponding to the target user and the verification rules corresponding to the transaction type are pre-loaded into Redis (cache area). When a call is needed, it is first read in Redis. If it does not exist in Redis, the database is accessed. Among them, Redis is an open source log-type, Key-Value cache database written in ANSI C language, supporting the network, memory-based and persistent, and can further provide APIs for access in multiple languages. In this embodiment, by loading the user profile and verification rules into the cache area, the verification can be extracted from the cache area when a call is needed, thereby avoiding the problem of all data being cached in the database, resulting in slow access speed, thereby improving the efficiency of abnormal transactions.

[0068] Furthermore, after step S20, the method further includes:

[0069] When the current transaction fails to pass the transaction parameter verification, the current transaction is rejected, and a reminder message indicating that the current transaction information is abnormal is generated and displayed, so as to promptly handle the abnormal current transaction.

[0070] Current abnormal transaction detection rules are not very timely and cannot meet the needs of real-time data analysis and real-time response to message events. As a result, once a problem occurs, abnormal transactions can only be detected after the fact. To address this issue, this embodiment directly rejects the current transaction when it is detected that the current transaction fails the transaction parameter verification, and generates and displays a reminder message indicating that the current transaction information is abnormal. Specifically, a corresponding reminder can be provided based on the specific abnormal transaction parameters, so that the abnormal current transaction can be handled promptly and the user is notified of the reason for the current transaction rejection.

[0071] Wherein, step S30 specifically includes:

[0072] When the current transaction passes the transaction parameter verification, obtaining target account information to which the current transaction belongs, and determining target consumption information corresponding to the target user based on the target user tag in the target account information, wherein the target consumption information includes a target consumption type and / or a target consumption amount;

[0073] The current transaction information of the current transaction is compared with the target consumption information to determine whether the current transaction meets the user profile of the target user, wherein the current transaction information includes the current transaction type and / or the current transaction amount.

[0074] In this embodiment, when the current transaction passes the transaction parameter verification, the target account information to which the current transaction belongs is obtained. Then, based on the target user tags associated with the target account information, such as "homebody" or "saving expert", the target consumption information corresponding to the target user is determined, including the target consumption type, i.e., the type of goods generally purchased, and the target consumption amount. The target consumption amount can be determined based on the daily consumption average, weekly consumption average, monthly consumption average, or maximum consumption amount. The current transaction type and current transaction amount in the current transaction information are obtained, and the target consumption type is compared with the current transaction type, and the target consumption amount is compared with the current transaction amount. Based on the target consumption information corresponding to the target user, it is verified whether the current transaction type and current transaction amount are consistent with the user consumption behavior of the target user.

[0075] Step S40: If the current transaction does not conform to the user profile of the target user, an exception is processed for the target transaction.

[0076] In this embodiment, if it is detected that the current transaction does not match the user profile of the target user, it means that the current user may not be the target user, that is, account theft may have occurred. Through corresponding verification rules, such as mobile phone number SMS verification, fingerprint recognition or face recognition, the target transaction is verified by the user, so that the target transaction is handled abnormally to avoid property loss of the user.

[0077] When the transaction instruction of the current transaction is detected, this embodiment obtains the transaction type of the current transaction and determines the verification rules corresponding to the current transaction based on the transaction type; obtains the transaction parameters of the current transaction and performs transaction parameter verification on the current transaction based on the verification rules and the transaction parameters; when the current transaction passes the transaction parameter verification, obtains the target account information to which the current transaction belongs, and determines whether the current transaction meets the user profile of the target user based on the target user tag in the target account information; if the current transaction does not meet the user profile of the target user, the target transaction is subjected to exception processing. Through the above-mentioned method, the present invention sets different verification rules for different transaction types, and can automatically match corresponding verification rules according to the transaction type to perform parameter verification on the current transaction parameters. Then, when the current parameter verification passes, the user profile verification is further performed on the current transaction, and corresponding verification standards are set for each user, thereby improving the accuracy of identifying transaction anomalies and solving the technical problem of low efficiency in identifying abnormal transactions caused by the fixed traditional transaction identification rules and the single abnormal identification standard.

[0078] Furthermore, based on the first embodiment of the method for detecting abnormal transactions of the present invention, a second embodiment of the method for detecting abnormal transactions of the present invention is proposed.

[0079] In this embodiment, the abnormal transaction detection method further includes:

[0080] When a rule setting instruction triggered by a user operation is received, the rule configuration information in the rule setting instruction is obtained to add a new verification rule and / or modify a historical verification rule.

[0081] In order to solve the problem that the current verification rule adjustments are based on post-data analysis or feedback from users, customer service, and partners, and the existing verification rules need to be modified through version releases, this implementation provides a rule configuration console to provide a verification rule configuration page so that users can add verification scenarios or verification rules through the console. Among them, the rule setting method can be to verify the parameters of various transaction elements of existing account transactions such as account opening / consumption / card binding / cash withdrawal, etc. The rules can also be expanded horizontally in the future, as follows, including but not limited to:

[0082] A. Account opening transactions can be set based on whether the account holder's age, identity, device number IP, ID card OCR return code, four-factor authentication results, anti-fraud results, online verification results, and other factors meet the conditions;

[0083] B. Consumption transactions can be set based on merchant type, transaction time, amount and other factors to see if they meet the conditions;

[0084] C. Card binding transactions can be set based on whether the authentication behavior before card binding (mobile phone verification SMS OTP (One-time Password, also known as dynamic password) or verification password), four-factor authentication results, type of bound card, and other factors meet the conditions.

[0085] It is also possible to further use the computing engine to quickly calculate the relevant indicators of the transaction to identify abnormal transactions, thereby performing transaction control and abnormal warning. Among them, the relevant indicators may include parameters such as the total transaction volume, transaction approval rate, transaction average or user cross-record; in order to achieve real-time and fast calculation, this embodiment adopts a fast and general computing engine Spark designed for large-scale data processing, which has the advantages of the distributed computing program framework Hadoop MapReduce and can process massive data. However, unlike MapReduce, the intermediate output results of the job can be stored in memory, so there is no need to read and write the result data from the distributed file system HDFS, and it can be used to build large-scale, low-latency data analysis applications; among them, the verification rules for calculating the relevant indicators of the transaction can refer to the following elements:

[0086] A. Total transaction volume: Set different values ​​for different time statistical windows (i.e. time intervals) to specify different exception return codes, as shown in the following table:

[0087] Total trading volume Hour (same period of previous day) day (last day) Week (last week) Increase 0-50% Return code: 0 Return code: 1 Return code: 2 Increase of 50-100% Return code: 3 Return code: 4 Return code: 5 Increase of more than 100% Return code: 6 Return code: 7 Return code: 8 0-50% reduction Return code: 9 Return code: 10 Return code: 11 50-100% reduction Return code: 12 Return code: 13 Return code: 14

[0088] B. Transaction success rate: Set different values ​​in different time statistical windows to specify different exception return codes, as shown in the following table:

[0089] Transaction success rate Hour (same period of previous day) day(last day) Week (last week) Increase 0-50% Return code: 15 Return code: 16 Return code: 17 Increase of 50-100% Return code: 18 Return code: 19 Return code: 20 Increase of more than 100% Return code: 21 Return code: 22 Return code: 23 0-50% reduction Return code: 24 Return code: 25 Return code: 26 50-100% reduction Return code: 27 Return code: 28 Return code: 29

[0090] C. Users analyze across records to specify different exception return codes, as shown in the following table:

[0091]

[0092] In other words, by monitoring the global transaction information of the trading platform, corresponding verification rules can be set according to different transaction types and transaction parameters, such as age, amount, transaction location, and frequency. For example:

[0093] A. Over a period of time, we observed that the average age of users opening accounts through a certain cooperative platform was over 60 years old, and all had the same address on their ID cards. This could be due to a "wool-pulling" scheme whereby a group of rural elderly people's ID cards were collected to open accounts in a unified manner, thereby taking advantage of the platform.

[0094] B. The amount of a transaction on a certain platform far exceeds the average transaction amount of the platform. This may indicate fraudulent transactions.

[0095] C. Analyze multiple records of the actor. For example, if the user's previous 100 transactions were conducted in Shenzhen, while this transaction was conducted in Beijing, and the time interval between the previous transaction was only 10 minutes, this may indicate that the trading account was hacked.

[0096] D. Someone attempts to trade multiple times in a row but fails to verify their password each time. This may be because the current user is not the real user.

[0097] You can also further set exception handling rules for abnormal transactions, as shown in the following table:

[0098]

[0099] In this example, by adding and modifying verification rules, defects that can only be modified after the fact are prevented. In addition, transaction detection is implemented in conjunction with the computing engine Spark, which improves the accuracy and efficiency of abnormal transaction sorting, better meeting the needs of banks and other financial institutions, thereby ensuring the normal operation of various businesses (loans, deposits, etc.) of banks and other financial institutions.

[0100] Furthermore, based on the first embodiment of the abnormal transaction detection method of the present invention, step S40 specifically includes:

[0101] If the current transaction does not match the user profile of the target user, the preset user verification rules are called by the preset decision engine to perform user identity verification on the current user conducting the current transaction to determine whether the current user is the target user;

[0102] If it is determined that the current user is not the target user, the current transaction is rejected, and a reminder message of not being the user is generated and displayed to perform an exception process on the target transaction.

[0103] In this embodiment, if the current transaction is determined not to match the target user's user profile, then the transaction behavior corresponding to the current transaction does not match the target user's corresponding user consumption behavior. A preset decision engine calls user verification rules in a cache or database, and authenticates the current user using these user verification rules, thereby improving the accuracy of authentication.

[0104] Furthermore, based on the first embodiment of the method for detecting abnormal transactions of the present invention, a third embodiment of the method for detecting abnormal transactions of the present invention is proposed.

[0105] In this embodiment, the abnormal transaction detection method before step S10 further includes:

[0106] If a large number of trading instructions are received, the large number of trading instructions are divided into batches according to the preset time interval, and the batched trading instructions are added to the processing queue in order of receipt time;

[0107] The computing engine sequentially encapsulates each batch transaction instruction in the processing queue into each distributed transaction data set, and performs abnormal transaction detection processing on each distributed transaction data set.

[0108] To process large amounts of transaction instruction data in real time, this embodiment uses the open-source stream processing platform Kafka cluster as the processing architecture. Originally developed by LinkedIn, Kafka cluster is a distributed, partitioned, multi-replicated, high-throughput publish-subscribe messaging system. Powered by ZooKeeper, a distributed application coordination service, its greatest feature is its ability to process large amounts of data in real time to meet diverse demand scenarios. Even on standard servers, it can process hundreds of thousands of messages per second, enabling low-latency collection and delivery of large amounts of event and log data. A Kafka cluster consists of several producers, processing servers, consumers, and a ZooKeeper cluster. Producers are clients that send messages to the Kafka cluster, while consumers retrieve messages from it. Processing servers are responsible for message processing and distribution, while ZooKeeper manages the dynamic joining and leaving of processing servers and consumers. All components are horizontally scalable. User transactions act as producers in the Kafka cluster, transmitting message events to the cluster and caching them according to message type. Based on preconfigured subscription rules, the Kafka cluster forwards data to Spark Streaming and the big data platform for real-time and offline computing. Spark Streaming is a framework built on Spark for processing stream data. Its basic principle is to break stream data into small time segments (a few seconds) and process these small segments in a manner similar to batch processing. In other words, Spark Streaming is a framework provided by Spark for real-time computing on big data. After acquiring data from the data source, complex algorithms can be processed using high-level functions such as map, reduce, join, and window. Finally, the processed results can be stored in a file system or database. Spark Streaming's internal processing mechanism is to receive real-time streaming data (such as a large number of transaction instructions) and split them into batches at regular intervals. The Spark engine then processes these batches to produce batches of processed transaction results. Each batch of data corresponds to an instance of a Resilient Distributed Dataset (RDD) in the Spark kernel. Therefore, the DStream corresponding to the streaming data can be viewed as a set of RDDs—that is, a DStream is a continuous sequence of RDDs. That is to say, after a large amount of transaction instruction stream data is divided into batches, it passes through a first-in-first-out queue, and then the Spark Engine takes out the batch data from the queue one by one, encapsulates the batch data into an RDD, and then performs an abnormal transaction detection process on each RDD.

[0109] It should be understood that in the process of transaction detection of massive big data by banks and other financial institutions, the distributed architecture composed of the above-mentioned Kafka cluster, Spark Streaming and big data platform realizes the efficient and accurate detection process of massive big data transactions.

[0110] Furthermore, before step S30, the method further includes:

[0111] Clustering user information using a preset clustering algorithm, and collecting user information and historical transaction information of each clustered user;

[0112] According to the user information, the historical transaction information and the preset tag setting rules, a corresponding user tag is set for each user, a user portrait corresponding to each user is generated, and the user portrait corresponding to each user is saved offline for offline calling.

[0113] To improve the accuracy of user profiles, in this embodiment, users are first clustered according to their user information type using a clustering algorithm. The clustering algorithm is set according to actual needs and is not limited here. Then, user information and historical transaction information corresponding to each clustered user are extracted, including historical transaction types and historical transaction amounts. Based on each user's consumption, corresponding labels are set for each user to label each user and generate a corresponding user profile for each user. Labeling can be based on preset label setting rules, such as setting user types based on the proportion of transaction types, or setting user spending power based on the amount of consumption. Alternatively, the user's historical transaction information and corresponding set labels are input into a model for model training. The user information and the user's corresponding transaction information are then input into the trained model to set labels for each user, thereby generating a corresponding user profile for each user. To meet the needs of real-time queries, each user's user profile is stored offline using Hbase. Hbase is a highly reliable, high-performance, column-oriented, and scalable distributed storage system that can process large data consisting of thousands of rows and columns using only ordinary hardware configurations.

[0114] The present invention also provides a device for detecting abnormal transactions. The device for detecting abnormal transactions includes:

[0115] a verification rule determination module, configured to, upon detecting a transaction instruction of a current transaction, obtain a transaction type of the current transaction and determine a verification rule corresponding to the current transaction based on the transaction type;

[0116] a transaction parameter verification module, configured to obtain the transaction parameters of the current transaction and verify the transaction parameters of the current transaction according to the verification rules and the transaction parameters;

[0117] A user profile verification module is configured to obtain target account information of the current transaction when the current transaction passes the transaction parameter verification, and determine whether the current transaction conforms to the user profile of the target user based on the target user tag in the target account information;

[0118] The abnormal transaction processing module is used to perform abnormal processing on the target transaction if the current transaction does not meet the user profile of the target user.

[0119] Furthermore, the user portrait verification module is also used to:

[0120] When the current transaction passes the transaction parameter verification, obtaining target account information to which the current transaction belongs, and determining target consumption information corresponding to the target user based on the target user tag in the target account information, wherein the target consumption information includes a target consumption type and / or a target consumption amount;

[0121] The current transaction information of the current transaction is compared with the target consumption information to determine whether the current transaction meets the user profile of the target user, wherein the current transaction information includes the current transaction type and / or the current transaction amount.

[0122] Furthermore, the abnormal transaction processing module is further configured to:

[0123] If the current transaction does not match the user profile of the target user, the preset user verification rules are called by the preset decision engine to perform user identity verification on the current user conducting the current transaction to determine whether the current user is the target user;

[0124] If it is determined that the current user is not the target user, the current transaction is rejected, and a reminder message of not being the user is generated and displayed to perform an exception process on the target transaction.

[0125] Furthermore, the abnormal transaction detection device further includes:

[0126] A transaction instruction batching module is used to batch the received large number of transaction instructions according to a preset time interval, and add the batched transaction instructions to the processing queue in order of receipt time;

[0127] The transaction data set encapsulation module is used to encapsulate the batch transaction instructions in the processing queue into distributed transaction data sets in sequence through a computing engine, and perform abnormal transaction detection processing on the distributed transaction data sets respectively.

[0128] Furthermore, the abnormal transaction detection device further includes:

[0129] The parameter abnormality reminder module is used to reject the current transaction when the current transaction fails to pass the transaction parameter verification, generate and display a reminder message of the abnormal current transaction information, and promptly handle the abnormal current transaction.

[0130] Furthermore, the abnormal transaction detection device further includes:

[0131] A user information clustering module is used to cluster user information using a preset clustering algorithm and collect user information and historical transaction information of each clustered user;

[0132] The user portrait generation module is used to set corresponding user tags for each user according to the user information, the historical transaction information and the preset tag setting rules, generate user portraits corresponding to each user, and save the user portraits corresponding to each user offline for offline call.

[0133] Furthermore, the transaction parameter verification module specifically includes:

[0134] Obtaining transaction parameters of the current transaction and determining whether the verification rule exists in the cache;

[0135] If the verification rule does not exist in the cache area, the verification rule is obtained from the database, and transaction parameter verification is performed on the current transaction according to the verification rule and the transaction parameters.

[0136] Furthermore, the abnormal transaction detection device further includes:

[0137] The verification rule configuration module is used to obtain the rule configuration information in the rule setting instruction when receiving the rule setting instruction triggered by the user operation, and add new verification rules and / or modify historical verification rules.

[0138] The methods executed by the above program modules can refer to the various embodiments of the abnormal transaction detection method of the present invention, and will not be described in detail here.

[0139] The present invention also provides a computer-readable storage medium.

[0140] The computer-readable storage medium of the present invention stores an abnormal transaction detection program, which implements the steps of the abnormal transaction detection method described above when executed by a processor.

[0141] The method implemented when the abnormal transaction detection program running on the processor is executed can refer to the various embodiments of the abnormal transaction detection method of the present invention, and will not be described in detail here.

[0142] It should be noted that, in this document, the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, article, or system comprising a series of elements includes not only those elements but also other elements not explicitly listed, or elements inherent to such process, method, article, or system. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of other identical elements in the process, method, article, or system comprising the element.

[0143] The serial numbers of the above embodiments of the present invention are for description only and do not represent the advantages or disadvantages of the embodiments.

[0144] Through the description of the above embodiments, those skilled in the art can clearly understand that the above embodiment methods can be implemented by means of software plus the necessary general hardware platform, and of course can also be implemented by hardware, but in many cases the former is a better embodiment. Based on this understanding, the technical solution of the present invention is essentially or the part that contributes to the prior art can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) as described above, and includes a number of instructions for enabling a terminal device (which can be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in each embodiment of the present invention.

[0145] The above are only preferred embodiments of the present invention and are not intended to limit the patent scope of the present invention. Any equivalent structure or equivalent process transformation made using the contents of the present invention description and drawings, or directly or indirectly applied in other related technical fields, are also included in the patent protection scope of the present invention.

Claims

1. A method for detecting abnormal transactions, characterized in that: The abnormal transaction detection method comprises the following steps: When detecting a transaction instruction of a current transaction, obtaining the transaction type of the current transaction, and determining a verification rule corresponding to the current transaction according to the transaction type; Acquiring transaction parameters of the current transaction, and performing transaction parameter verification on the current transaction according to the verification rule and the transaction parameters; Clustering user information using a preset clustering algorithm, and collecting user information and historical transaction information of each clustered user; According to the user information, the historical transaction information and the preset tag setting rules, a corresponding user tag is set for each user, a user profile corresponding to each user is generated, and the user profile corresponding to each user is saved offline for offline access; When the current transaction passes the transaction parameter verification, obtaining target account information to which the current transaction belongs, and determining target consumption information corresponding to the target user based on the target user tag in the target account information, wherein the target consumption information includes a target consumption type and / or a target consumption amount; Comparing the current transaction information of the current transaction with the target consumption information to determine whether the current transaction meets the user profile of the target user, wherein the current transaction information includes the current transaction type and / or the current transaction amount; If the current transaction does not match the user profile of the target user, perform exception processing on the target transaction; Upon receiving a rule setting instruction triggered by a user operation, the rule configuration information in the rule setting instruction is obtained to add new verification rules and / or modify historical verification rules. The rule setting method is to perform parameter verification on transaction elements of different transaction types. The transaction type includes at least one of the following existing account transactions: account opening, consumption and cash withdrawal. The transaction elements of the account opening transaction include the account holder's age, identity, device number IP, ID card OCR return code, four-factor authentication result, anti-fraud result and online verification result. The transaction elements of the consumption transaction include merchant type, transaction time and amount. The transaction elements of the card binding transaction include the authentication behavior before card binding, the four-factor authentication result and the type of bound card. Transaction anomalies are identified by calculating transaction-related indicators, including total transaction volume, transaction approval rate, transaction average, and user cross-records. Verification rules for calculating transaction-related indicators can be set by specifying different abnormal return codes by setting different values ​​in different time statistical windows and by specifying different abnormal return codes through cross-transaction analysis.

2. The method for detecting abnormal transactions according to claim 1, wherein: If the current transaction does not conform to the user profile of the target user, the step of performing exception processing on the target transaction specifically includes: If the current transaction does not match the user profile of the target user, the preset user verification rules are called by the preset decision engine to perform user identity verification on the current user conducting the current transaction to determine whether the current user is the target user; If it is determined that the current user is not the target user, the current transaction is rejected, and a reminder message of not being the user is generated and displayed to perform an exception process on the target transaction.

3. The abnormal transaction detection method according to claim 1, characterized in that: Before the step of obtaining the transaction type of the current transaction when detecting the transaction instruction of the current transaction and determining the verification rule corresponding to the current transaction according to the transaction type, the method further includes: If a large number of trading instructions are received, the large number of trading instructions are divided into batches according to the preset time interval, and the batched trading instructions are added to the processing queue in order of receipt time; The computing engine sequentially encapsulates each batch transaction instruction in the processing queue into each distributed transaction data set, and performs abnormal transaction detection processing on each distributed transaction data set.

4. The method for detecting abnormal transactions according to claim 1, wherein: After the step of obtaining the transaction parameters of the current transaction and verifying the transaction parameters of the current transaction according to the verification rule and the transaction parameters, the method further includes: When the current transaction fails to pass the transaction parameter verification, the current transaction is rejected, and a reminder message indicating that the current transaction information is abnormal is generated and displayed, so as to promptly handle the abnormal current transaction.

5. The method for detecting abnormal transactions according to claim 1, wherein: The step of obtaining the transaction parameters of the current transaction and verifying the transaction parameters of the current transaction according to the verification rule and the transaction parameters specifically includes: Obtaining transaction parameters of the current transaction and determining whether the verification rule exists in the cache; If the verification rule does not exist in the cache area, the verification rule is obtained from the database, and transaction parameter verification is performed on the current transaction according to the verification rule and the transaction parameters.

6. A device for detecting abnormal transactions, characterized in that: The abnormal transaction detection device includes: a verification rule determination module, configured to, upon detecting a transaction instruction of a current transaction, obtain a transaction type of the current transaction and determine a verification rule corresponding to the current transaction based on the transaction type; a transaction parameter verification module, configured to obtain the transaction parameters of the current transaction and verify the transaction parameters of the current transaction according to the verification rules and the transaction parameters; A user profile verification module is configured to obtain target account information of the current transaction when the current transaction passes the transaction parameter verification, and determine whether the current transaction conforms to the user profile of the target user based on the target user tag in the target account information; An abnormal transaction processing module, configured to perform abnormal processing on the target transaction if the current transaction does not conform to the user profile of the target user; The user profile verification module is further configured to: when the current transaction passes the transaction parameter verification, obtain the target account information to which the current transaction belongs, and determine the target consumption information corresponding to the target user based on the target user tag in the target account information, wherein the target consumption information includes the target consumption type and / or the target consumption amount; compare the current transaction information of the current transaction with the target consumption information to determine whether the current transaction conforms to the user profile of the target user, wherein the current transaction information includes the current transaction type and / or the current transaction amount; A verification rule configuration module is configured to, upon receiving a rule setting instruction triggered by a user operation, obtain rule configuration information in the rule setting instruction, add new verification rules, and / or modify historical verification rules. The rule setting method is to perform parameter verification on transaction elements of different transaction types. Transaction types include at least one of the following existing account transactions: account opening, consumption, and cash withdrawal. Transaction elements of account opening transactions include the account holder's age, identity, device number IP, ID card OCR return code, four-factor authentication result, anti-fraud result, and online verification result. Transaction elements of consumption transactions include merchant type, transaction time, and amount. Transaction elements of card binding transactions include authentication behavior before card binding, four-factor authentication result, and bound card type. The verification rule configuration module is also used to identify transaction anomalies by calculating relevant transaction indicators. The relevant transaction indicators include the total transaction volume, transaction approval rate, transaction average, and user cross-record. The verification rules for calculating the total transaction volume are set to specify different exception return codes by setting different values ​​through different time statistical windows. The verification rules for calculating the relevant transaction indicators are set in ways that include specifying different exception return codes by setting different values ​​through different time statistical windows and specifying different exception return codes through cross-transaction analysis.

7. The abnormal transaction detection device according to claim 6, characterized in that: The abnormal transaction processing module is further used to: If the current transaction does not match the user profile of the target user, the preset user verification rules are called by the preset decision engine to perform user identity verification on the current user conducting the current transaction to determine whether the current user is the target user; If it is determined that the current user is not the target user, the current transaction is rejected, and a reminder message of not being the user is generated and displayed to perform an exception process on the target transaction.

8. The abnormal transaction detection device according to claim 6, characterized in that: The abnormal transaction detection device further includes: A transaction instruction batching module is used to batch the received large number of transaction instructions according to a preset time interval, and add the batched transaction instructions to the processing queue in order of receipt time; The transaction data set encapsulation module is used to encapsulate the batch transaction instructions in the processing queue into distributed transaction data sets in sequence through a computing engine, and perform abnormal transaction detection processing on the distributed transaction data sets respectively.

9. An abnormal transaction detection device, characterized in that: The abnormal transaction detection device includes: a memory, a processor, and an abnormal transaction detection program stored in the memory and executable on the processor. When the abnormal transaction detection program is executed by the processor, the steps of the abnormal transaction detection method according to any one of claims 1 to 5 are implemented.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores an abnormal transaction detection program, and when the abnormal transaction detection program is executed by a processor, the steps of the abnormal transaction detection method according to any one of claims 1 to 5 are implemented.

Images