Anti-fraud processing method and device, computer program product and anti-fraud system

Abstract

The invention provides an anti-fraud processing method and device, a computer program product and an anti-fraud system.The method comprises the steps that under the condition that a transaction request is obtained, service identification and in-event fraud identification are conducted on the transaction request, and a service identification result and an in-event identification result are obtained; refusing the transaction request under the condition that at least one of the business identification result characterizing that the verification is not passed and the in-event identification result characterizing that the verification is not passed is satisfied; executing the transaction request under the condition that the business identification result characterization passes the verification and the in-event identification result characterization passes the verification; and storing the transaction request obtained this time, the business identification result corresponding to the transaction request and the in-event identification result corresponding to the transaction request, and performing post-event fraud identification on all the first historical transaction requests in the first historical time period to obtain a post-event identification result. According to the method, the problem that anti-fraud identification is static and poor in flexibility in the prior art is solved.

Description

Technical Field

[0001] This application relates to the field of financial technology, and more specifically, to an anti-fraud processing method, an anti-fraud processing device, a computer program product, and an anti-fraud system. Background Technology

[0002] With the widespread adoption of electronic payments and online banking, the digitalization of financial transactions is constantly increasing, and fraudulent activities are evolving accordingly, becoming a major challenge for the financial industry. Traditional anti-fraud technologies largely rely on rule-based systems and relatively simple statistical models. For example, rule-based systems use predefined rule sets to detect abnormal behavior in transactions, such as frequent large transactions or transactions conducted at abnormal times. Statistical models, on the other hand, are typically trained using historical data to identify transaction patterns that match the characteristics of fraudulent behavior. However, existing anti-fraud identification methods are static and lack flexibility. Summary of the Invention

[0003] The main objective of this application is to provide an anti-fraud processing method, an anti-fraud processing device, a computer program product, and an anti-fraud system, so as to at least solve the problem that the anti-fraud identification in the prior art is static and lacks flexibility.

[0004] To achieve the above objectives, according to one aspect of this application, an anti-fraud processing method is provided, comprising: upon receiving a transaction request, performing business identification and in-process fraud identification on the transaction request to obtain a business identification result and an in-process identification result, wherein the business identification result represents the result of verifying whether the transaction request conforms to business logic, and the in-process identification result represents the result of verifying whether the transaction request has a fraud risk; if at least one of the business identification result and the in-process identification result is satisfied, rejecting the transaction request; if both the business identification result and the in-process identification result are satisfied, executing the transaction request; storing the obtained transaction request, the corresponding business identification result, and the corresponding in-process identification result, and performing post-fraud identification on all first historical transaction requests within a first historical time period to obtain a post-identification result, wherein the post-identification result represents the result of verifying whether all first historical transaction requests within the first historical time period have a fraud risk, and wherein the post-identification result is used to analyze whether historical transactions have undetected fraudulent behavior and optimize anti-fraud strategies.

[0005] According to another aspect of this application, an anti-fraud processing apparatus is provided, comprising: an identification unit, configured to, upon receiving a transaction request, perform business identification and in-process fraud identification on the transaction request to obtain a business identification result and an in-process identification result, wherein the business identification result represents the result of verifying whether the transaction request conforms to business logic, and the in-process identification result represents the result of verifying whether the transaction request has a fraud risk; a rejection unit, configured to reject the transaction request if at least one of the business identification result and the in-process identification result satisfy the condition; an execution unit, configured to execute the transaction request if both the business identification result and the in-process identification result satisfy the condition; and a first processing unit, configured to store the currently obtained transaction request, the business identification result corresponding to the transaction request, and the in-process identification result corresponding to the transaction request, and perform post-fraud identification on all first historical transaction requests within a first historical time period to obtain a post-identification result, wherein the post-identification result represents the result of verifying whether all first historical transaction requests within the first historical time period have a fraud risk, and wherein the post-identification result is used to analyze whether historical transactions have fraudulent behaviors that have not been detected in a timely manner, and to optimize anti-fraud strategies.

[0006] According to another aspect of this application, a computer program product is provided, comprising a computer program that, when executed by a processor, implements the steps of any of the aforementioned anti-fraud processing methods.

[0007] According to another aspect of this application, an anti-fraud system is provided, comprising: one or more processors, a memory, and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the one or more processors, the one or more programs including a processing method for performing any of the aforementioned anti-fraud methods.

[0008] By applying the technical solution of this application, business identification and in-process fraud identification are initiated simultaneously upon receiving a transaction request. This parallel processing mechanism reduces the total time spent on transaction processing while ensuring that the business logic and fraud risks of the transaction are assessed in a timely manner. The anti-fraud identification process is divided into two stages: in-process anti-fraud identification and post-process fraud identification. In-process anti-fraud identification is initiated immediately when a transaction request occurs to quickly determine whether the transaction is high-risk, while post-process fraud identification is performed after the transaction is completed, through in-depth analysis of historical transaction data. This allows for fraud behavior identification at different stages, making the identification behavior more dynamic and improving the flexibility of identification. Attached Figure Description

[0009] The accompanying drawings, which form part of this application, are used to provide a further understanding of this application. The illustrative embodiments and descriptions of this application are used to explain this application and do not constitute an undue limitation of this application. In the drawings:

[0010] Figure 1 A hardware structure block diagram of a mobile terminal performing an anti-fraud processing method according to an embodiment of this application is shown.

[0011] Figure 2 A flowchart illustrating an anti-fraud processing method according to an embodiment of this application is shown.

[0012] Figure 3 A schematic diagram of the overall technical solution is shown;

[0013] Figure 4 This diagram illustrates the sequential processing of traditional business logic components and real-time anti-fraud components.

[0014] Figure 5 This diagram illustrates the parallel processing of the business logic component and the real-time anti-fraud component.

[0015] Figure 6 A schematic diagram of the real-time anti-fraud component is shown;

[0016] Figure 7 A schematic diagram of the anti-fraud timeout control module is shown;

[0017] Figure 8 A schematic diagram of the anti-fraud timeout control process is shown;

[0018] Figure 9 A schematic diagram of asynchronous MQ data acquisition is shown;

[0019] Figure 10 A schematic diagram of the post-fraud prevention component is shown;

[0020] Figure 11 This diagram illustrates how the post-event anti-fraud component updates the in-event anti-fraud component in response to feedback.

[0021] Figure 12 A structural block diagram of an anti-fraud processing apparatus provided according to an embodiment of this application is shown.

[0022] The above figures include the following reference numerals:

[0023] 102. Processor; 104. Memory; 106. Transmission device; 108. Input / output device. Detailed Implementation

[0024] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. This application will now be described in detail with reference to the accompanying drawings and embodiments.

[0025] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0026] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate for the embodiments of this application described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0027] For ease of description, the following explains some of the nouns or terms used in the embodiments of this application:

[0028] (1) Anti-fraud: A mechanism to detect and block potential fraudulent activities during user transactions or business request execution.

[0029] (2) MQ (Message Queues): An asynchronous communication technology used to decouple system components and achieve efficient data transmission.

[0030] (3) Dynamic configuration platform (such as Apollo): A platform that supports real-time updates of system configuration parameters, used to dynamically adjust anti-fraud strategies.

[0031] (4) Rule Engine: A component embedded in an application designed to separate business decisions from application code and write business decisions using predefined semantic modules. It automates business processes by accepting data input, interpreting business rules, and making business decisions based on those rules.

[0032] (5) Blacklist and whitelist mechanism: Two control rules, "precise access" and "proactive interception", are used. The whitelist only allows specific objects to pass, while the blacklist directly blocks known risk objects. Precise control is achieved by dividing objects into "allowed" or "prohibited" categories. This is a strategy to intercept high-risk users or transactions.

[0033] (6) Deep Learning: Specifically refers to machine learning based on deep neural network models and methods. It has been developed based on statistical machine learning, artificial neural network and other algorithm models, combined with the development of big data and computing power in the modern era. The most important technical feature of deep learning is its ability to automatically extract features. The extracted features are also called deep features or deep feature representations. Compared with manually designed features, deep features have stronger representation capabilities and are more robust.

[0034] (7) LSTM model: A special type of recurrent neural network (RNN) that can learn and remember long-term dependencies. LSTM solves the vanishing gradient problem encountered by traditional RNNs when processing long sequence data by introducing gating mechanisms. These gating mechanisms include forget gates, input gates, and output gates, which can control the flow of information, thereby enabling the network to learn long-term dependencies.

[0035] (8) Redis: An open-source, high-performance key-value store database that provides various data structures for storing data, such as strings, hashes, lists, sets, and sorted sets. Redis stores data in memory to provide fast read and write access and can persist data to disk asynchronously. It supports replication, Lua scripts, transaction processing, different levels of persistence options, and interfaces for various client languages. Redis is widely used in caching, message queues, short-term data storage, and high-performance applications.

[0036] Existing bank anti-fraud technologies have the following problems:

[0037] 1) The contradiction between model complexity and real-time performance: High-precision models (such as deep learning) require long computation times and cannot be directly embedded in real-time transaction links, resulting in increased interface latency.

[0038] 2) Limitations of single-stage processing: Existing solutions focus on in-process detection without combining in-depth post-event analysis, making it difficult to optimize strategies using historical data.

[0039] 3) Lack of dynamic adjustment capability: Anti-fraud rules are fixed in the code and cannot be updated in real time with thresholds, model parameters and blacklists and whitelists.

[0040] Existing technical solutions generally have the following limitations:

[0041] 1) The contradiction between model complexity and real-time performance: High-precision models (such as deep learning) require a long time to compute, making it difficult to directly embed them into the real-time transaction chain. At the same time, the lack of a timeout circuit breaker mechanism poses a risk to the performance of the transaction interface.

[0042] 2) The value of historical data has not been fully explored: Real-time detection relies only on the data requested at present and lacks in-depth analysis of users' long-term behavior.

[0043] 3) Lagging strategy updates: Model optimization relies on offline training and cannot be quickly fed back to the real-time detection stage.

[0044] As described in the background section, existing anti-fraud identification methods are static and lack flexibility. To address these issues, embodiments of this application provide an anti-fraud processing method, an anti-fraud processing device, a computer program product, and an anti-fraud system.

[0045] This solution aims to address the aforementioned issues by combining real-time anti-fraud detection during the event with asynchronous anti-fraud analysis after the event, thereby achieving an efficient, low-latency, and dynamically configurable anti-fraud processing method.

[0046] The technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention.

[0047] The methods and embodiments provided in this application can be executed on a mobile terminal, computer terminal, or similar computing device. Taking running on a mobile terminal as an example, Figure 1 This is a hardware structure block diagram of a mobile terminal for an anti-fraud processing method according to an embodiment of the present invention. Figure 1 As shown, a mobile terminal may include one or more ( Figure 1 Only one is shown in the diagram. A processor 102 (which may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.) and a memory 104 for storing data are also shown. The mobile terminal may further include a transmission device 106 for communication functions and an input / output device 108. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the mobile terminal described above. For example, the mobile terminal may also include components that are more... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0048] The memory 104 can be used to store computer programs, such as application software programs and modules, like the computer program corresponding to the anti-fraud processing method in this embodiment of the invention. The processor 102 executes various functional applications and data processing by running the computer program stored in the memory 104, thereby implementing the above-described method. The memory 104 may include high-speed random access memory and non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the mobile terminal via a network. Examples of the aforementioned networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof. The transmission device 106 is used to receive or send data via a network. Specific examples of the aforementioned networks may include wireless networks provided by the mobile terminal's communication provider. In one example, the transmission device 106 includes a network interface controller (NIC), which can be connected to other network devices via a base station to communicate with the Internet. In one example, the transmission device 106 may be a radio frequency (RF) module, which is used to communicate with the Internet wirelessly.

[0049] This embodiment provides an anti-fraud processing method that runs on a mobile terminal, computer terminal, or similar computing device. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Also, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0050] Figure 2 This is a flowchart illustrating an anti-fraud processing method according to an embodiment of this application. Figure 2 As shown, the method includes the following steps:

[0051] Step S201: Upon receiving a transaction request, perform business identification and in-process fraud identification on the transaction request to obtain business identification results and in-process identification results. The business identification results represent the result of verifying whether the transaction request conforms to business logic, and the in-process identification results represent the result of verifying whether the transaction request has fraud risk.

[0052] Specifically, when the system receives a transaction request, it immediately initiates two parallel processes: business identification and real-time fraud detection. Business identification checks whether the transaction logic is reasonable, such as whether the account status, transaction amount, transaction time, and location are compliant. Real-time fraud detection, on the other hand, uses lightweight models such as small neural networks based on real-time data to quickly assess transaction risks, ensuring the immediate security of the transaction and the accuracy of the business logic.

[0053] In the above embodiments, by parallelizing the execution of business identification and in-process fraud identification, transaction processing time is significantly shortened and transaction processing efficiency is improved. Parallel processing avoids the serial bottleneck of transaction processing, enabling transaction requests to be fully evaluated in the shortest possible time, thereby achieving efficient transaction processing.

[0054] Step S202: If at least one of the above-mentioned business identification result representations fails verification and the above-mentioned in-process identification result representations fails verification is satisfied, the above-mentioned transaction request is rejected.

[0055] Specifically, if a transaction fails verification at either the business identification or in-process fraud identification stage, the system will immediately reject the transaction request to avoid potential fraud losses or transaction violations.

[0056] In the above embodiments, the immediate rejection mechanism can effectively prevent fraudulent transactions, significantly reduce the incidence of fraud incidents, and improve transaction security. Fraudulent or irregular transactions often require immediate response. Through an immediate verification failure feedback mechanism, fraudulent activities can be intercepted before they cause actual losses, thereby protecting the assets of banks and users.

[0057] Step S203: If both the above-mentioned business identification result representation and the above-mentioned in-process identification result representation are verified, execute the above-mentioned transaction request.

[0058] Specifically, when a transaction request passes both business identification and in-process fraud identification, ensuring that the transaction conforms to business logic and does not pose an immediate risk of fraud, the system will allow the transaction to continue.

[0059] The above embodiments achieve smooth transaction processing, improve user experience, and ensure transaction security. The dual authentication mechanism, while guaranteeing transaction security, avoids unnecessary obstacles to normal transactions, balancing security and user experience. This allows legitimate transactions to be completed quickly and enhances user trust in the banking system.

[0060] Step S204: Store the transaction request obtained this time, the business identification result corresponding to the transaction request, and the in-process identification result corresponding to the transaction request. Perform post-event fraud identification on all first historical transaction requests within the first historical time period to obtain post-event identification results. The post-event identification results represent the results of verifying whether there is a fraud risk in all first historical transaction requests within the first historical time period. The post-event identification results are used to analyze whether there are fraudulent behaviors in historical transactions that have not been detected in time and to optimize anti-fraud strategies.

[0061] Specifically, after a transaction is completed, the system automatically records and stores the transaction request, business identification results, and in-process fraud identification results, providing data support for future analysis and strategy optimization. The system also periodically (e.g., every night) performs in-depth analysis on all historical transaction data within the first historical time period (e.g., the past 30 days), using sophisticated deep learning models such as LSTM for post-event fraud identification to uncover potential fraudulent activities.

[0062] In the above embodiments, complex fraud patterns in historical transactions are identified through post-event deep analysis, and anti-fraud strategies are optimized, thereby improving the intelligence and robustness of the anti-fraud system and reducing the false negative rate of fraud events. Post-event identification utilizes the powerful analytical capabilities of deep learning models, which can learn deeper patterns and correlations from historical data. Even complex fraudulent behaviors that were not detected during the event identification process can be accurately identified in post-event identification. The feedback mechanism updates the strategies and model parameters of the event identification process, forming a strategy optimization closed loop and continuously improving fraud detection capabilities.

[0063] In this embodiment, business identification and in-process fraud identification are initiated simultaneously upon receiving a transaction request. This parallel processing mechanism reduces the total transaction processing time while ensuring that the business logic and fraud risks of the transaction are assessed in a timely manner. The anti-fraud identification process is divided into two stages: in-process anti-fraud identification and post-process fraud identification. In-process anti-fraud identification is initiated immediately when a transaction request occurs to quickly determine whether the transaction is high-risk, while post-process fraud identification is performed after the transaction is completed, through in-depth analysis of historical transaction data. This allows for fraud behavior identification at different stages, making the identification behavior more dynamic and improving the flexibility of identification.

[0064] The technical background of this solution is that current bank anti-fraud technology mainly focuses on real-time detection during the event, and improves detection speed and accuracy by optimizing AI models (such as neural networks and stream processing technology).

[0065] This solution proposes a phased framework for anti-fraud during and after the event, with the core elements as follows:

[0066] 1. Parallel execution architecture: Business logic and anti-fraud components are processed in parallel, reducing the total time consumption of the interface.

[0067] 2. In-process and post-process phased handling framework:

[0068] 1) Anti-fraud phase during the transaction: Run a lightweight model to quickly intercept high-risk requests and ensure low transaction latency.

[0069] 2) Post-fraud prevention stage: Collect data through asynchronous MQ pipelines and run complex models (such as depth graph networks) to deeply explore fraud patterns.

[0070] 3. Dynamic rule engine: Supports real-time adjustment of anti-fraud rules, with multi-dimensional rule set configurations at the switch level, transaction channel level, transaction type level, and transaction amount level.

[0071] 4. Blacklists and whitelists: Blacklist and whitelist rules are enforced first, directly blocking known high-risk entities and reducing the consumption of subsequent detection resources.

[0072] 5. Timeout Circuit Breaker Mechanism: A timeout detection mechanism is introduced during the transaction phase, with dynamic threshold configuration to avoid model delays affecting transaction performance and ensure system performance.

[0073] 6. Asynchronous Data Pipeline: Real-time data collection and in-depth post-event analysis are linked through MQ.

[0074] 7. Build a closed loop for strategy optimization: Feed back the post-event anti-fraud analysis results to the in-event anti-fraud detection module and dynamically update the blacklist, whitelist and model parameters.

[0075] The overall technical solution of this plan is as follows: Figure 3 As shown, when a user initiates a transaction request, the system simultaneously triggers the business component and the real-time anti-fraud component to execute in parallel. The real-time anti-fraud component performs rule engine-level control and merchant or user-level blacklist / whitelist control. If a fraudulent user is identified, the anti-fraud processing ends; otherwise, a lightweight anti-fraud model is used for fraud identification, and control is determined based on the identification results. If the business component finishes execution but the real-time anti-fraud component has not, the anti-fraud timeout component will process the transaction according to the configuration policy (reject / allow) of the Apollo dynamic configuration platform. Finally, the transaction information is collected to the big data platform asynchronously via MQ. Afterward, the anti-fraud component uses the big data platform data and a deep learning model to mine fraud patterns, feeding the analysis results back to the real-time anti-fraud component to dynamically update the blacklist / whitelist and model parameters, completing the anti-fraud strategy optimization loop.

[0076] When a user initiates a transaction request, the system simultaneously triggers the business components and the real-time anti-fraud components to execute in parallel. Figure 4 In traditional business processes, business logic and real-time fraud prevention are executed sequentially. Figure 5 This solution parallelizes the processing of anti-fraud and business logic components during the process, reducing interface latency and improving the efficiency of user request processing.

[0077] In the specific implementation process, the above-mentioned transaction requests are subjected to in-process fraud identification to obtain in-process identification results, including: performing rule identification on the above-mentioned transaction requests to obtain rule identification results, wherein the rule identification includes verifying whether the transaction channel of the above-mentioned transaction request complies with the rules, verifying whether the transaction type of the above-mentioned transaction request complies with the rules, and verifying whether the transaction amount of the above-mentioned transaction request does not require one or more of the supervision; identifying the list to which the users of the above-mentioned transaction requests belong to, to obtain list identification results, wherein the list identification results represent the result of verifying whether the user belongs to the whitelist; obtaining a first model, wherein the first model is one of the SVM model, decision tree model, and random forest model; and forming a first training set by combining the second historical transaction requests and the corresponding first risk labels, and using the above... The first model is trained using the first training set to obtain a first risk identification model, wherein the first risk label is the historical first risk probability corresponding to the second historical transaction request in the first training set; the transaction request is input into the first risk identification model to obtain the first risk probability corresponding to the transaction request; if the rule identification result representation passes verification, the list identification result representation passes verification, and the first risk probability is less than or equal to a first preset risk threshold, the in-process identification result is determined to be verified; if at least one of the rule identification result representation passing verification, the list identification result representation passing verification, and the first risk probability being less than or equal to the first preset risk threshold is not met, the in-process identification result is determined to be unverified.

[0078] In this solution, rule recognition can quickly filter out obviously non-compliant transactions, significantly reducing the burden of subsequent fraud detection and improving overall processing efficiency. The list recognition mechanism significantly enhances the ability to manage known risky users in real time, while providing a smoother transaction experience for high-quality users. The model can effectively distinguish between normal transactions and potentially fraudulent transactions, improving the accuracy of fraud detection. Dynamically adjusted risk probability thresholds can adapt to different business scenarios, improving the flexibility of fraud detection. Through a triple verification process, transaction security is greatly guaranteed, and the accuracy of fraud detection is significantly improved. This multi-layered verification mechanism can more comprehensively assess transaction risks; even if a single verification step is insufficient to fully determine the security of a transaction, combining multiple verification strategies can form an effective defense against fraudulent activities.

[0079] like Figure 6As shown, the real-time anti-fraud component mainly consists of three parts: a rule engine, merchant-level or user-level blacklists and whitelists, and a lightweight anti-fraud model. Engine rules are stored in Apollo, separated from business logic, allowing business personnel to directly adjust strategies without developer intervention. The parameters of the lightweight anti-fraud model are also stored in Apollo, and new rules and model parameters are dynamically applied directly through the Apollo dynamic configuration platform.

[0080] 1) Rule Engine. The rule engine parses the rule set configured on the Apollo dynamic configuration platform and executes corresponding actions based on the input data. For example:

[0081] a) Whether to enable anti-fraud rules can control the enabling and disabling of anti-fraud functions. If disabled, only business logic is processed and no anti-fraud control is performed.

[0082] b) Transaction channel restriction rules enable special control over different channels;

[0083] c) Transaction type restriction rules, which can control or not control the type of specified transactions. For example, inquiry, repayment or transfer confirmation transactions do not need to be controlled.

[0084] The transaction amount limit rule can control transactions that exceed the configured minimum amount. For example, only transactions with a transaction amount exceeding 100 will be controlled.

[0085] Lightweight anti-fraud model. During the transaction phase, a lightweight model (such as a small neural network) is used for rapid detection, improving processing speed and reducing interface response time. Specifically, the lightweight model takes as input features the transaction amount, device fingerprint, and historical behavior score. Its structure is a 3-layer neural network, and it outputs a risk probability to determine whether the transaction is fraudulent.

[0086] In some embodiments, after performing business identification and in-process fraud identification on the transaction request, the method further includes: extracting the timestamp at which business identification and in-process fraud identification begin to obtain a first timestamp; if the business identification result has been obtained but the in-process identification result has not yet been obtained, extracting the current timestamp to obtain a second timestamp; if the difference between the second timestamp and the first timestamp is greater than a preset time threshold, determining a timeout identification, and processing the transaction request according to a preset strategy, wherein the preset strategy represents rejecting the transaction request or approving the transaction request.

[0087] In this solution, recording the first timestamp allows for precise tracking of the identification process's time consumption, providing a benchmark for timeout detection. Real-time capture of the second timestamp enables dynamic monitoring of the time spent on fraud identification during the transaction, helping to promptly detect and handle potential timeouts. The timeout control mechanism ensures the immediacy of transactions and the stability of system performance.

[0088] Anti-fraud timeout control module, such as Figure 7 As shown, after a user initiates a request, the system simultaneously enters the "In-Process Anti-Fraud Component" and the "Business Logic Component"; the results from the two components are aggregated into the "Anti-Fraud Timeout Control Component," and finally, the "End Request Processing" is executed, and the result is returned to the user.

[0089] Figure 8 This is the anti-fraud timeout control flowchart. First, it checks if the "anti-fraud timeout control component" has finished executing. If "yes," it directly proceeds to the "is it a fraudulent transaction?" judgment. If "no," it continues to judge whether the "execution time has exceeded the timeout period." If it hasn't timed out: it waits for the in-process anti-fraud component to reach its timeout period, then judges whether "execution ended before timeout." If "yes," it proceeds to the "is it a fraudulent transaction?" judgment. If "no," it follows the Apollo configuration's "timeout clearance?" judgment: clearance ends the process; otherwise, timeout is rejected. If it has already timed out, it similarly follows the Apollo configuration's "timeout clearance?" judgment. If it is determined to be a fraudulent transaction, it executes "cancel rejection - end processing"; otherwise, it executes "clear - end processing."

[0090] The anti-fraud timeout detection module monitors the execution time of the anti-fraud component. If a timeout occurs, the transaction is processed according to the configuration policy (reject / allow) of the Apollo dynamic configuration platform. The specific implementation is as follows:

[0091] 1) The business logic component and the real-time anti-fraud component start executing in parallel using multiple threads simultaneously, and record the current start time T1;

[0092] 2) After the business logic component completes execution, obtain the execution status of the in-process anti-fraud component thread. If the execution is complete, reject or allow the process according to the execution result of the in-process anti-fraud component.

[0093] If the process does not complete, retrieve the timeout threshold for the in-process anti-fraud component of the Apollo dynamic configuration platform. The execution time for in-process anti-fraud measures Δt = current time T2 - in-process anti-fraud start time T1, and the remaining waiting time. =Timeout threshold - Execution time Δt;

[0094] a) If the execution time Δt > the timeout threshold, the transaction will be processed according to the configuration strategy (reject / allow) of the Apollo dynamic configuration platform;

[0095] b) If the execution time Δt <= the timeout threshold, the in-process anti-fraud task will continue to wait for the remaining waiting time. If the task is not completed within the waiting time, the transaction will be processed according to the configuration policy (reject / allow) of the Apollo dynamic configuration platform; otherwise, if the task is completed within the waiting time, the in-process anti-fraud execution component will either reject or allow the transaction.

[0096] In the specific implementation process, after identifying the list to which the user of the above transaction request belongs and obtaining the list identification result, the above method further includes: if the list identification result indicates that the user is on the whitelist, obtaining the user's level information, wherein the level information includes ordinary level and important level, and ordinary level is lower than important level; if the level information is important level, and if the rule identification result indicates that the verification failed and / or the first risk probability is greater than the first preset risk threshold, determining that the above in-process identification result is verified.

[0097] This solution differentiates user levels, enabling tailored anti-fraud strategies for different user groups and optimizing user experience. Special handling for high-priority users increases the flexibility of the anti-fraud system, enhances their transaction experience, and reduces false alarm rates.

[0098] Merchant-level or user-level blacklists and whitelists. User-level blacklists can accurately block high-risk individuals, while merchant-level blacklists can directly restrict transactions with merchants prone to fraud. Whitelist mechanisms, on the other hand, can provide exemptions for high-quality users and merchants (e.g., VIP users can be allowed to proceed even if certain rules are triggered).

[0099] In some embodiments, the transaction request is subjected to business identification to obtain a business identification result, including: determining whether the transaction request meets preset conditions, wherein the preset conditions include at least the transfer amount being greater than the deposit amount and / or both parties' accounts being frozen; if the transaction request meets the preset conditions, the business identification result is determined to be unverified; if the transaction request does not meet the preset conditions, the business identification result is determined to be verified.

[0100] This solution ensures the rationality of transaction request business logic and the legitimacy of both parties' accounts through pre-defined condition checks, preventing transaction problems caused by business logic errors or abnormal account status. Real-time business logic verification significantly reduces the transaction failure rate due to business logic errors, while simultaneously safeguarding the financial security of the banking system. Transaction requests with reasonable business logic can quickly pass verification and proceed to the next stage of processing, improving transaction processing efficiency and user experience.

[0101] In the specific implementation process, post-event fraud identification is performed on all first historical transaction requests within the first historical time period to obtain the aforementioned post-event identification result. This includes: obtaining a second model, wherein the second model is one of an SVM model, a decision tree model, a random forest model, or an LSTM model; forming a second training set by combining the third historical transaction request and its corresponding second risk label, and training the second model using the second training set to obtain a second risk identification model, wherein the second risk label is the historical second risk probability corresponding to the third historical transaction request in the second training set, and the third historical transaction request is a historical transaction request within the second historical time period; inputting the first historical transaction request into the second risk identification model to obtain the second risk probability corresponding to the first historical transaction request; if the second risk probability is less than or equal to a second preset risk threshold, determining that the post-event identification result is verified; if the second risk probability is greater than the second preset risk threshold, determining that the post-event identification result is not verified.

[0102] This solution utilizes deep learning models for post-transaction fraud analysis, enabling in-depth analysis of complex patterns in historical transactions and improving the accuracy of fraud detection. Through training with historical transaction data, the second risk identification model learns more complex risk characteristics, enhancing its ability to identify potential fraudulent activities. Re-evaluating the first set of historical transaction requests reveals hidden fraudulent activities, optimizing the fraud identification strategy. The setting of a second preset risk threshold effectively identifies high-risk transactions, reducing the false negative rate of fraudulent activities.

[0103] After the transaction is completed, transaction data, user behavior, and anti-fraud results are asynchronously sent to the big data platform via MQ. The real-time anti-fraud component only needs to perform lightweight detection, quickly return results, and collect data to the big data platform via asynchronous MQ. The non-synchronous method further avoids blocking the current request, improves the interface processing speed, and the collected data is the basis for the anti-fraud component to execute complex model training after the transaction is completed.

[0104] Asynchronous MQ data acquisition, such as Figure 9 As shown, after a user initiates a request, the request is simultaneously processed by the "In-Process Rules Component" and the "Business Logic Component". The results from the two components are aggregated into the "Anti-Fraud Real-Time Control Component", and then synchronized to the "Big Data Platform" through the "Asynchronous MQ Collector", ultimately completing the "Result Request Processing".

[0105] Post-event anti-fraud components such as Figure 10As shown, after a user initiates a request, it is processed by both the "In-Process Rules Component" and the "Business Logic Component". The results of the two components are aggregated into the "Anti-Fraud Real-Time Control Component", and then synchronized to the "Big Data Platform" via the "Asynchronous MQ Collector". This platform is used to complete the current process of "Result Request Processing" and is also sent to the "Post-Event Anti-Fraud Component" for reviewing historical data and optimizing anti-fraud strategies.

[0106] The post-fraud anti-fraud component combines historical data and uses deep learning models (such as LSTM and graph neural networks) to uncover fraud patterns.

[0107] The post-event anti-fraud component feeds back the analysis results to the real-time anti-fraud component, dynamically updating the blacklists, whitelists, and model parameters. Specifically, it uses an LSTM model to analyze a user's transaction timeline characteristics over three months to identify abnormal patterns (such as sudden increases in transaction frequency). High-risk user IDs are written to a database blacklist and flushed to Redis, and model parameter updates are pushed to the real-time component via Apollo.

[0108] Post-event anti-fraud component feedback and update in-event anti-fraud component, such as Figure 11 As shown, a user request simultaneously enters both the "In-Process Anti-Fraud Component" and the "Business Logic Component"; the results from both are aggregated into the "Real-Time Anti-Fraud Control Component," and subsequently synchronized to the "Big Data Platform" via "Asynchronous MQ Data Acquisition," ultimately completing the "End Request Processing"; the Big Data Platform then sends the data to the "Post-Process Anti-Fraud Component," which generates optimization strategies through post-mortem analysis and synchronizes them to the "In-Process Anti-Fraud Component" via "Feedback Updates," continuously improving real-time risk control capabilities.

[0109] In some embodiments, after inputting the first historical transaction request into the second risk identification model to obtain the second risk probability corresponding to the first historical transaction request, the method further includes: if the user of the first historical transaction request is on the blacklist and the second risk probability is less than or equal to the second preset risk threshold, adjusting the user from the blacklist to the whitelist; if the user of the first historical transaction request is on the whitelist and the second risk probability is greater than the second preset risk threshold, adjusting the user from the whitelist to the blacklist.

[0110] This solution utilizes a dynamic adjustment mechanism to promptly correct misjudgments of low-risk users, restoring their normal transaction privileges and enhancing user experience. Simultaneously, it reduces the rate of misjudgments by banks regarding high-risk users. Through dynamic monitoring and adjustments, potential fraudulent activities can be identified in a timely manner, protecting the funds of the bank and other users and mitigating losses from fraudulent events.

[0111] In addition to the above, this solution also includes context-aware intelligent threshold adjustment. It introduces context-aware technology to dynamically adjust risk assessment thresholds based on the specific context of the transaction (such as time, location, transaction type, device type, etc.). Machine learning algorithms (such as SVM, random forest, or deep learning) are used to analyze fraud behavior patterns in different contexts, constructing a context-risk model. Based on real-time contextual information of the user's transaction (such as GPS location, transaction time, device fingerprint, etc.), the first and second preset risk thresholds are dynamically adjusted. The specific steps are as follows:

[0112] 1. Data Collection and Preprocessing:

[0113] Collect contextual data: Collect real-time contextual information of users during transactions, including but not limited to GPS location data, transaction time, device fingerprint, transaction type, historical behavior data, etc.

[0114] Data cleaning and integration: Clean the collected data, remove invalid or redundant information, and integrate it into a unified format to facilitate subsequent analysis.

[0115] 2. Construct a scenario-risk model:

[0116] Feature engineering: Design features based on contextual data, such as transaction time cycle features (weekdays / weekends, daytime / nighttime), geographical location features (user's usual location, uncommon transaction locations), device type features, etc.

[0117] Model training: Context-risk models are built using machine learning algorithms such as SVM, random forest, or deep learning. Training data includes historical transaction data and labeled fraud / non-fraud, as well as specific contextual information for each transaction.

[0118] Model testing and optimization: The model's performance is evaluated using a test set, and the model is tuned based on metrics such as accuracy and recall to determine the final context-aware model.

[0119] 3. Real-time contextual information analysis:

[0120] Real-time context acquisition: When a transaction occurs, the system acquires contextual information related to the transaction in real time, such as the time, location, and device used in the current transaction.

[0121] Context feature analysis: Real-time context information is transformed into context features and input into the context-risk model for analysis.

[0122] 4. Dynamic threshold adjustment:

[0123] Threshold baseline setting: Initially set a first preset risk threshold and a second preset risk threshold. These two thresholds are used for in-process anti-fraud detection and post-process anti-fraud identification, respectively.

[0124] Context-aware adjustment: The above thresholds are dynamically adjusted based on the output of the context-risk model. For example, if a transaction occurs near the user's usual location and a common device is used, the model predicts a lower risk, so the first preset risk threshold can be appropriately lowered to relax the fraud detection standard and improve the user's transaction experience. Conversely, if a transaction occurs in an uncommon location or with an infrequently used device, the model predicts a higher risk, so the second preset risk threshold is increased to strengthen the strictness of post-transaction fraud identification.

[0125] Threshold adjustment strategy: Develop a threshold adjustment strategy, such as automatically adjusting the threshold based on the percentile of the risk score, or manually setting the threshold adjustment range according to the fraud rate in a specific situation.

[0126] 5. Integration and Deployment:

[0127] Threshold Adjustment Integration: Integrate the dynamic threshold adjustment mechanism into the existing anti-fraud system to ensure seamless integration with the in-process anti-fraud detection and post-process anti-fraud identification processes.

[0128] System optimization and testing: Optimize the entire system to ensure that context-aware intelligent threshold adjustments do not significantly increase system latency or resource consumption. Conduct multiple rounds of testing to verify anti-fraud performance under different scenarios.

[0129] 6. Monitoring and Feedback:

[0130] System monitoring: Establish a system monitoring mechanism to continuously monitor the performance of the context-aware model, check whether threshold adjustments have effectively reduced the false positive rate, and ensure system security.

[0131] Feedback mechanism: Based on the results of system monitoring, the scenario-risk model is updated regularly to adapt to constantly changing fraud patterns and user behaviors.

[0132] The above solution improves the contextual adaptability of anti-fraud strategies, making threshold adjustments more aligned with actual risk situations and reducing false positive rates. It ensures the consistency and reliability of the anti-fraud system across different scenarios, enhancing the overall security of the system.

[0133] In addition to the above, this solution also includes a blockchain-based anti-fraud sharing mechanism. It utilizes blockchain technology to build an anti-fraud information sharing platform, enabling real-time sharing and verification of risk information among different financial institutions. Technical solution: Establish a blockchain-based anti-fraud consortium chain, where financial institutions can upload and query user risk information. Smart contracts are used to automatically execute anti-fraud rules, ensuring data security and privacy. Specific steps are as follows:

[0134] 1. Building an anti-fraud consortium blockchain:

[0135] Consortium blockchain design: Select a suitable blockchain framework (such as Hyperledger Fabric, Corda) to design an anti-fraud consortium blockchain to ensure the privacy and security of on-chain transactions.

[0136] Consortium Node Invitation: Financial institutions are invited to join the consortium blockchain as nodes. Each node is responsible for uploading and verifying risk information and has the right to query shared data on the chain.

[0137] Consensus mechanism selection: Based on the characteristics of the consortium blockchain, select an appropriate consensus mechanism (such as Raft, PBFT) to ensure data consistency and transaction efficiency.

[0138] 2. Smart Contract Development and Deployment:

[0139] Smart contract design: Develop smart contract code, define the rules for uploading, querying, and verifying anti-fraud information, as well as data access permissions.

[0140] Rule setting: Set anti-fraud rules in smart contracts, including user behavior analysis, transaction pattern recognition, risk scoring algorithms, etc., to ensure that all nodes comply with unified anti-fraud standards.

[0141] Automatic execution mechanism: Smart contracts automatically execute the upload and verification process without human intervention, improving the timeliness and consistency of information processing.

[0142] 3. Risk Information Upload:

[0143] Standardized risk information: User risk information uploaded by financial institutions must be preprocessed and comply with the data format and privacy protection standards for on-chain storage.

[0144] Upload process: Financial institutions submit risk information (such as blacklisted users, abnormal transaction records, etc.) to the blockchain through smart contracts. Each upload transaction generates a blockchain hash value to ensure the immutability and transparency of the information.

[0145] 4. Risk Information Inquiry:

[0146] Access control: Financial institutions have the right to query on-chain risk information, but they must follow the access rules set by the smart contract. For example, they can only query risk data related to their own business.

[0147] Real-time query technology: Develop real-time query technology to enable financial institutions to quickly access the latest risk information on the blockchain and improve the speed of risk control decisions.

[0148] 5. Risk information verification and updating:

[0149] Data verification: The smart contract verifies the uploaded risk information to ensure the accuracy and validity of the data and prevent the upload of malicious or erroneous data.

[0150] Risk update mechanism: When new risk information is uploaded, the smart contract automatically updates the shared database, and all nodes can immediately obtain the latest risk information, realizing dynamic updates of risk information.

[0151] 6. Integration and Application:

[0152] System Integration: Integrate the blockchain anti-fraud information sharing platform with the anti-fraud systems of various financial institutions to ensure seamless real-time information sharing.

[0153] Application Example: When a user initiates a cross-institutional transaction, the system not only performs local anti-fraud checks but also queries the blockchain platform to check the user's cross-institutional risk information and whether the transaction triggers on-chain smart contract anti-fraud rules. If there are related high-risk records on the chain, the system will enhance the strictness of local anti-fraud checks; otherwise, it will maintain normal detection standards.

[0154] 7. Monitoring and Optimization:

[0155] Monitoring Mechanism: Establish a consortium blockchain monitoring mechanism to continuously monitor the integrity of on-chain data and the execution of smart contracts, preventing any abnormal or illegal activities.

[0156] Rule optimization: Based on the effectiveness of on-chain information sharing and feedback, the anti-fraud rules in smart contracts are regularly optimized to adapt to constantly changing fraud behavior patterns.

[0157] The aforementioned solution enhances the overall scope of the anti-fraud system through cross-institutional risk information sharing, effectively addressing cross-platform fraud. Automated execution of smart contracts simplifies the sharing process, improves information processing speed and transparency, and reduces response time to fraud incidents.

[0158] This solution is a fraud prevention method based on in-process and post-process analysis, the key aspects of which are as follows:

[0159] 1. Parallel execution architecture: Business logic and anti-fraud components are processed in parallel, reducing the total time consumption of the interface.

[0160] 2. In-process and Post-processing Staged Framework: A lightweight model is used in the in-process stage to improve the efficiency of anti-fraud processing. In the post-processing stage, a complex model is run to deeply explore fraud patterns, and the analysis results are fed back to the in-process anti-fraud component module to dynamically update its model parameters, realizing a closed loop of strategy optimization in both the in-process and post-processing stages.

[0161] 3. Dynamic rule engine: Supports real-time adjustment of anti-fraud rules, with multi-dimensional rule set configurations at the switch level, transaction channel level, transaction type level, and transaction amount level.

[0162] 4. Blacklists and whitelists: Blacklist and whitelist rules are enforced first, directly blocking known high-risk entities and reducing the consumption of subsequent detection resources.

[0163] 5. Timeout circuit breaker mechanism: Dynamic threshold and strategy configuration to ensure system performance.

[0164] 6. Asynchronous Data Pipeline: Real-time data collection and in-depth post-event analysis are linked through MQ.

[0165] The main advantages of this solution are:

[0166] 1. Efficiency Improvement: Parallel processing reduces interface latency; a phased processing framework for in-process and post-processing, and a lightweight in-process model improve anti-fraud processing speed; blacklist and whitelist rules are executed first, directly blocking known high-risk entities, reducing subsequent detection resource consumption, and improving anti-fraud processing speed.

[0167] 2. Enhanced robustness: The timeout circuit breaker mechanism prevents transaction blockage caused by anti-fraud component failure.

[0168] 3. Strategy optimization closed loop: a phased processing framework of in-process and post-process, with post-process analysis results fed back to the in-process stage in real time to improve the accuracy of fraud identification.

[0169] 4. Flexible and scalable: Engine rules support multi-dimensional configuration and real-time adjustment to adapt to different business scenarios.

[0170] The following alternative solutions can still be adopted to achieve the same inventive objective for the technical solution of this invention:

[0171] 1. Message queue alternative: Message queue processing systems such as Kafka can be used to replace MQ to achieve higher throughput asynchronous data transmission.

[0172] 2. Parallel component implementation: Multithreaded or distributed computing frameworks (such as Flink) can be used to replace process-level parallelism.

[0173] 3. Dynamic configuration tools: Use ZooKeeper or Nacos instead of Apollo.

[0174] This application also provides an anti-fraud processing device. It should be noted that the anti-fraud processing device of this application can be used to execute the anti-fraud processing method provided in this application. This device is used to implement the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can refer to a combination of software and / or hardware that implements a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0175] The following describes the anti-fraud processing apparatus provided in the embodiments of this application.

[0176] Figure 12 This is a structural block diagram of an anti-fraud processing apparatus according to an embodiment of this application. Figure 12 As shown, the device includes:

[0177] The identification unit 10 is used to perform business identification and in-process fraud identification on the transaction request when a transaction request is obtained, and to obtain business identification results and in-process identification results. The business identification results represent the result of verifying whether the transaction request conforms to business logic, and the in-process identification results represent the result of verifying whether the transaction request has fraud risk.

[0178] The rejection unit 20 is used to reject the transaction request if at least one of the above-mentioned business identification result representation failure verification and the above-mentioned in-process identification result representation failure verification is satisfied.

[0179] Execution unit 30 is used to execute the transaction request if both the above-mentioned business identification result characterization and the above-mentioned in-process identification result characterization are verified.

[0180] The first processing unit 40 is used to store the transaction request obtained this time, the business identification result corresponding to the transaction request, and the in-process identification result corresponding to the transaction request, and to perform post-fraud identification on all first historical transaction requests within the first historical time period to obtain post-identification results. The post-identification results represent the result of verifying whether there is a fraud risk in all first historical transaction requests within the first historical time period. The post-identification results are used to analyze whether there are fraudulent behaviors in historical transactions that have not been detected in time, and to optimize anti-fraud strategies.

[0181] In this embodiment, business identification and in-process fraud identification are initiated simultaneously upon receiving a transaction request. This parallel processing mechanism reduces the total transaction processing time while ensuring that the business logic and fraud risks of the transaction are assessed in a timely manner. The anti-fraud identification process is divided into two stages: in-process anti-fraud identification and post-process fraud identification. In-process anti-fraud identification is initiated immediately when a transaction request occurs to quickly determine whether the transaction is high-risk, while post-process fraud identification is performed after the transaction is completed, through in-depth analysis of historical transaction data. This allows for fraud behavior identification at different stages, making the identification behavior more dynamic and improving the flexibility of identification.

[0182] In the specific implementation process, the identification unit includes a first identification module, a second identification module, a first acquisition module, a first training module, a first processing module, a first determination module, and a second determination module. The first identification module is used to perform rule identification on the transaction request to obtain a rule identification result. The rule identification includes verifying whether the transaction channel of the transaction request complies with the rules, verifying whether the transaction type of the transaction request complies with the rules, and verifying whether the transaction amount of the transaction request does not require supervision, or one or more of these criteria. The second identification module is used to identify the list to which the user of the transaction request belongs to, to obtain a list identification result. The list identification result represents the result of verifying whether the user belongs to the whitelist. The first acquisition module is used to acquire a first model, which is one of the SVM model, decision tree model, and random forest model. The first training module is used to train the second historical transaction request and the corresponding first... A risk label constitutes a first training set. The first model is trained using the first training set to obtain a first risk identification model. The first risk label is the historical first risk probability corresponding to the second historical transaction request in the first training set. A first processing module is used to input the transaction request into the first risk identification model to obtain the first risk probability corresponding to the transaction request. A first determining module is used to determine that the in-process identification result is verified if the rule identification result representation is verified, the list identification result representation is verified, and the first risk probability is less than or equal to a first preset risk threshold. A second determining module is used to determine that the in-process identification result is not verified if at least one of the rule identification result representation, the list identification result representation, and the first risk probability is less than or equal to the first preset risk threshold is not met.

[0183] In this solution, rule recognition can quickly filter out obviously non-compliant transactions, significantly reducing the burden of subsequent fraud detection and improving overall processing efficiency. The list recognition mechanism significantly enhances the ability to manage known risky users in real time, while providing a smoother transaction experience for high-quality users. The model can effectively distinguish between normal transactions and potentially fraudulent transactions, improving the accuracy of fraud detection. Dynamically adjusted risk probability thresholds can adapt to different business scenarios, improving the flexibility of fraud detection. Through a triple verification process, transaction security is greatly guaranteed, and the accuracy of fraud detection is significantly improved. This multi-layered verification mechanism can more comprehensively assess transaction risks; even if a single verification step is insufficient to fully determine the security of a transaction, combining multiple verification strategies can form an effective defense against fraudulent activities.

[0184] In some embodiments, the above-described apparatus further includes a first extraction unit, a second extraction unit, and a second processing unit. The first extraction unit is used to extract the timestamp at the start of business identification and in-process fraud identification after performing business identification and in-process fraud identification on the transaction request, thereby obtaining a first timestamp. The second extraction unit is used to extract the current timestamp when the business identification result has been obtained but the in-process identification result has not yet been obtained, thereby obtaining a second timestamp. The second processing unit is used to determine timeout identification when the difference between the second timestamp and the first timestamp is greater than a preset time threshold, and to process the transaction request according to a preset strategy, wherein the preset strategy represents rejecting the transaction request or approving the transaction request.

[0185] In this solution, recording the first timestamp allows for precise tracking of the identification process's time consumption, providing a benchmark for timeout detection. Real-time capture of the second timestamp enables dynamic monitoring of the time spent on fraud identification during the transaction, helping to promptly detect and handle potential timeouts. The timeout control mechanism ensures the immediacy of transactions and the stability of system performance.

[0186] In the specific implementation process, the above-mentioned device further includes an acquisition unit and a determination unit. The acquisition unit is used to identify the list to which the user of the above-mentioned transaction request belongs, and after obtaining the list identification result, if the list identification result indicates that the user is on the whitelist, acquire the user's level information, wherein the level information includes ordinary level and important level, and ordinary level is lower than important level; the determination unit is used to determine that the above-mentioned in-process identification result is verified as passed if the level information is important level, if the rule identification result indicates that the verification is not passed and / or the first risk probability is greater than the first preset risk threshold.

[0187] This solution differentiates user levels, enabling tailored anti-fraud strategies for different user groups and optimizing user experience. Special handling for high-priority users increases the flexibility of the anti-fraud system, enhances their transaction experience, and reduces false alarm rates.

[0188] In some embodiments, the identification unit includes a third determining module, a fourth determining module, and a fifth determining module. The third determining module is used to determine whether the transaction request meets preset conditions, wherein the preset conditions include at least the transfer amount being greater than the deposit amount and / or both parties' accounts being frozen. The fourth determining module is used to determine that the business identification result is not verified if the transaction request meets the preset conditions. The fifth determining module is used to determine that the business identification result is verified if the transaction request does not meet the preset conditions.

[0189] This solution ensures the rationality of transaction request business logic and the legitimacy of both parties' accounts through pre-defined condition checks, preventing transaction problems caused by business logic errors or abnormal account status. Real-time business logic verification significantly reduces the transaction failure rate due to business logic errors, while simultaneously safeguarding the financial security of the banking system. Transaction requests with reasonable business logic can quickly pass verification and proceed to the next stage of processing, improving transaction processing efficiency and user experience.

[0190] In the specific implementation process, the first processing unit includes a second acquisition module, a second training module, a second processing module, a sixth determination module, and a seventh determination module. The second acquisition module is used to acquire a second model, wherein the second model is one of an SVM model, a decision tree model, a random forest model, and an LSTM model. The second training module is used to form a second training set by combining the third historical transaction request and the corresponding second risk label, and to train the second model using the second training set to obtain a second risk identification model, wherein the second risk label is the historical second risk probability corresponding to the third historical transaction request in the second training set, and the third historical transaction request is a historical transaction request in a second historical time period. The second processing module is used to input the first historical transaction request into the second risk identification model to obtain the second risk probability corresponding to the first historical transaction request. The sixth determination module is used to determine that the post-event identification result is verified if the second risk probability is less than or equal to a second preset risk threshold. The seventh determination module is used to determine that the post-event identification result is not verified if the second risk probability is greater than the second preset risk threshold.

[0191] This solution utilizes deep learning models for post-transaction fraud analysis, enabling in-depth analysis of complex patterns in historical transactions and improving the accuracy of fraud detection. Through training with historical transaction data, the second risk identification model learns more complex risk characteristics, enhancing its ability to identify potential fraudulent activities. Re-evaluating the first set of historical transaction requests reveals hidden fraudulent activities, optimizing the fraud identification strategy. The setting of a second preset risk threshold effectively identifies high-risk transactions, reducing the false negative rate of fraudulent activities.

[0192] In some embodiments, the above-described apparatus further includes a first adjustment unit and a second adjustment unit. The first adjustment unit is used to adjust the user from the blacklist to the whitelist after inputting the first historical transaction request into the second risk identification model to obtain the second risk probability corresponding to the first historical transaction request, if the user of the first historical transaction request is on the blacklist and the second risk probability is less than or equal to the second preset risk threshold. The second adjustment unit is used to adjust the user from the whitelist to the blacklist if the user of the first historical transaction request is on the whitelist and the second risk probability is greater than the second preset risk threshold.

[0193] This solution utilizes a dynamic adjustment mechanism to promptly correct misjudgments of low-risk users, restoring their normal transaction privileges and enhancing user experience. Simultaneously, it reduces the rate of misjudgments by banks regarding high-risk users. Through dynamic monitoring and adjustments, potential fraudulent activities can be identified in a timely manner, protecting the funds of the bank and other users and mitigating losses from fraudulent events.

[0194] The aforementioned anti-fraud processing device includes a processor and a memory. The identification unit, rejection unit, execution unit, and first processing unit are all stored as program units in the memory, and the processor executes the program units stored in the memory to achieve the corresponding functions. All of the above modules are located in the same processor; alternatively, the modules may be located in different processors in any combination.

[0195] The processor contains a kernel, which retrieves the corresponding program units from memory. One or more kernels can be configured, and adjusting kernel parameters can address the problem of static and inflexible anti-fraud detection in existing technologies.

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

[0197] This invention provides a computer-readable storage medium including a stored program, wherein, when the program is executed, it controls the device where the computer-readable storage medium is located to perform the anti-fraud processing method.

[0198] This invention provides a processor for running a program, wherein the program executes the anti-fraud processing method described above.

[0199] This invention provides a device including a processor, a memory, and a program stored in the memory and executable on the processor. When the processor executes the program, it implements at least the steps of an anti-fraud processing method. The device described herein may be a server, PC, PAD, mobile phone, etc.

[0200] This application also provides a computer program product that, when executed on a data processing device, is adapted to execute a program that initializes a processing method step with at least anti-fraud measures.

[0201] This application also provides an anti-fraud system, comprising: one or more processors, a memory, and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the one or more processors, and the one or more programs include processing methods for performing any of the above-described anti-fraud methods.

[0202] It is obvious to those skilled in the art that the modules or steps of the present invention described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. They can be implemented using computer-executable program code, and thus can be stored in a storage device for execution by a computing device. In some cases, the steps shown or described can be performed in a different order than those described herein, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, the present invention is not limited to any particular combination of hardware and software.

[0203] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0204] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0205] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0206] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0207] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

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

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

[0210] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0211] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0212] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A method for preventing fraud, characterized in that, include: Upon receiving a transaction request, the transaction request is subjected to business identification and in-process fraud identification to obtain business identification results and in-process identification results. The business identification results represent the result of verifying whether the transaction request conforms to business logic, and the in-process identification results represent the result of verifying whether the transaction request has fraud risk. If at least one of the following conditions is met: the business identification result fails verification and the in-process identification result fails verification, the transaction request will be rejected. If both the business identification result representation and the in-process identification result representation are verified, the transaction request is executed. The transaction request, the business identification result corresponding to the transaction request, and the in-process identification result corresponding to the transaction request are stored. Post-event fraud identification is performed on all first historical transaction requests within the first historical time period to obtain post-event identification results. The post-event identification results represent the results of verifying whether there is a fraud risk in all first historical transaction requests within the first historical time period. The post-event identification results are used to analyze whether there are fraudulent behaviors in historical transactions that have not been detected in time and to optimize anti-fraud strategies.

2. The method according to claim 1, characterized in that, Perform real-time fraud detection on the transaction request to obtain the real-time detection result, including: The transaction request is subjected to rule identification to obtain rule identification results. The rule identification includes verifying whether the transaction channel of the transaction request complies with the rules, verifying whether the transaction type of the transaction request complies with the rules, and verifying whether the transaction amount of the transaction request does not require supervision in one or more of the following aspects: The list to which the user of the transaction request belongs is identified to obtain a list identification result, wherein the list identification result represents the result of verifying whether the user belongs to the whitelist; Obtain the first model, wherein the first model is one of the SVM model, decision tree model, and random forest model; The second historical transaction request and the corresponding first risk label are combined to form a first training set. The first model is trained using the first training set to obtain a first risk identification model. The first risk label is the historical first risk probability corresponding to the second historical transaction request in the first training set. The transaction request is input into the first risk identification model to obtain the first risk probability corresponding to the transaction request; If the rule identification result characterization is verified, the list identification result characterization is verified, and the first risk probability is less than or equal to the first preset risk threshold, the in-process identification result is determined to be verified. If at least one of the following conditions is not met: the rule identification result indicates that ...

3. The method according to claim 2, characterized in that, After performing business identification and in-process fraud identification on the transaction request, the method further includes: Extract the timestamps at the start of business identification and in-process fraud identification to obtain the first timestamp; If the business identification result has been obtained but the in-process identification result has not yet been obtained, extract the current timestamp to obtain the second timestamp; If the difference between the second timestamp and the first timestamp is greater than a preset time threshold, a timeout is identified, and the transaction request is processed according to a preset strategy, wherein the preset strategy indicates whether to reject the transaction request or to approve the transaction request.

4. The method according to claim 2, characterized in that, After identifying the list of users to which the transaction request belongs and obtaining the list identification result, the method further includes: When the list identification result indicates that the user is in the whitelist, the user's level information is obtained, wherein the level information includes ordinary level and important level, and ordinary level is lower than important level; If the level information is of an important level, and if the rule identification result indicates that the verification has failed and / or the first risk probability is greater than the first preset risk threshold, the in-process identification result is determined to be verified.

5. The method according to claim 1, characterized in that, The transaction request is subjected to business identification to obtain the business identification result, including: Determine whether the transaction request meets preset conditions, wherein the preset conditions include at least the transfer amount being greater than the deposit amount and / or both parties' accounts being frozen; If the transaction request meets the preset conditions, the business identification result is determined to be unverified. If the transaction request does not meet the preset conditions, the business identification result is determined to be verified.

6. The method according to claim 1, characterized in that, Post-event fraud identification is performed on all first-historical transaction requests within the first historical time period to obtain the post-event identification results, including: Obtain a second model, wherein the second model is one of the following: SVM model, decision tree model, random forest model, and LSTM model; The third historical transaction request and the corresponding second risk label are combined to form a second training set. The second model is trained using the second training set to obtain a second risk identification model. The second risk label is the historical second risk probability corresponding to the third historical transaction request in the second training set, and the third historical transaction request is a historical transaction request in the second historical time period. The first historical transaction request is input into the second risk identification model to obtain the second risk probability corresponding to the first historical transaction request; If the second risk probability is less than or equal to the second preset risk threshold, the post-identification result is determined to be verified. If the second risk probability is greater than the second preset risk threshold, the post-identification result is determined to be that the verification failed.

7. The method according to claim 6, characterized in that, After inputting the first historical transaction request into the second risk identification model to obtain the second risk probability corresponding to the first historical transaction request, the method further includes: If the user making the first historical transaction request is on the blacklist and the second risk probability is less than or equal to the second preset risk threshold, the user will be moved from the blacklist to the whitelist. If the user making the first historical transaction request is on the whitelist and the second risk probability is greater than the second preset risk threshold, the user will be moved from the whitelist to the blacklist.

8. An anti-fraud processing device, characterized in that, include: The identification unit is used to perform business identification and in-process fraud identification on the transaction request when a transaction request is obtained, and to obtain business identification results and in-process identification results. The business identification results represent the result of verifying whether the transaction request conforms to business logic, and the in-process identification results represent the result of verifying whether the transaction request has fraud risk. The rejection unit is configured to reject the transaction request if at least one of the following conditions is met: the business identification result representation fails verification and the in-process identification result representation fails verification. An execution unit is configured to execute the transaction request if both the business identification result representation and the in-process identification result representation are verified. The first processing unit is used to store the transaction request obtained this time, the business identification result corresponding to the transaction request, and the in-process identification result corresponding to the transaction request, and to perform post-fraud identification on all first historical transaction requests within the first historical time period to obtain post-identification results. The post-identification results represent the result of verifying whether there is a fraud risk in all first historical transaction requests within the first historical time period. The post-identification results are used to analyze whether there are fraudulent behaviors in historical transactions that have not been detected in time, and to optimize anti-fraud strategies.

9. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the anti-fraud processing method according to any one of claims 1 to 7.

10. An anti-fraud system, characterized in that, include: One or more processors, a memory, and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the one or more processors, the one or more programs including a processing method for performing the anti-fraud method according to any one of claims 1 to 7.

Images