Fraud payment detection method and device, equipment and medium

Abstract

The invention relates to a fraud payment detection method and device, equipment and medium in the technical field of e-commerce, and the method comprises the steps: responding to a transaction payment event triggered by a user, and employing a local risk detection model to determine the real-time fraud risk degree of a payment order corresponding to the event; when the real-time fraud risk degree does not exceed a first preset threshold value or exceeds a second preset threshold value, the payment order is correspondingly confirmed to be a low-risk type order or a high-risk type order, and the second preset threshold value is greater than the first preset threshold value; when the payment order is not confirmed as the low-risk type order or the high-risk type order, adopting a third-party risk detection model to confirm that the payment order is the high-risk type order or the low-risk type order; and for the high-risk type order, pausing the transaction process, verifying the real identity of the user, and continuing the transaction process after the verification is passed. According to the invention, payment risk detection services of local and third parties can be reasonably scheduled, the payment security is ensured, and the detection cost of the third party is reduced.

Description

Technical Field

[0001] This application relates to the field of e-commerce technology, and in particular to a method for detecting fraudulent payments and the corresponding apparatus, computer equipment, and computer-readable storage medium. Background Technology

[0002] With the rapid development of internet technology and e-commerce, electronic payment has become an indispensable part of people's daily lives. However, while the convenience of payment transactions has greatly improved, various fraudulent payment behaviors have also become increasingly rampant, causing huge economic losses and reputational risks to merchants and payment platforms. Therefore, how to quickly and accurately detect and block fraudulent payment orders while ensuring that the transaction experience of legitimate users is not affected has become a core issue that urgently needs to be addressed in the field of payment security.

[0003] Traditional fraud detection solutions primarily rely on two types of methods: First, rule-based risk control systems, which use pre-defined, manually defined fraud rules (e.g., "single transaction amount exceeds a specific threshold," "multiple transactions initiated by the same device within a short period," "payment IP and delivery address are not from the same country") combined with static blacklists (e.g., lists of malicious IPs and problematic bank card numbers) to perform real-time detection of payment orders. This solution has advantages such as rapid deployment, simple logic, and strong interpretability, but it also has significant inherent drawbacks, including requiring substantial manual maintenance costs and limited ability to detect highly concealed fraud patterns.

[0004] Secondly, third-party risk control services can be utilized. These professional risk control vendors leverage cross-industry and cross-platform data to develop "black box" models based on machine learning / deep learning, applying their fraud pattern detection capabilities. This solution boasts advantages such as extensive data coverage and the ability to accurately detect multiple fraud patterns. However, it also has inherent drawbacks, primarily the need for substantial operational costs to support real-time processing of all payment orders.

[0005] Therefore, the industry urgently needs a fraud payment detection solution that can ensure high accuracy while taking into account cost, efficiency, and user experience. Summary of the Invention

[0006] The primary objective of this application is to address at least one of the aforementioned problems by providing a fraud payment detection method and corresponding apparatus, computer equipment, and computer program products.

[0007] To achieve the various objectives of this application, the following technical solution is adopted: A fraud payment detection method provided for one of the purposes of this application includes the following steps: In response to a user-triggered transaction payment event, a local risk detection model is used to determine the real-time fraud risk level of the payment order corresponding to the event. The local risk detection model is trained based on a risk order dataset, which includes multi-dimensional feature data corresponding to multiple historical payment orders and prior fraud risk levels corresponding to the risk type of the corresponding historical payment orders detected by a third-party risk detection model. When the real-time fraud risk level does not exceed the first preset threshold or exceeds the second preset threshold, the payment order is confirmed as a low-risk order or a high-risk order, and the second preset threshold is greater than the first preset threshold. When the payment order is not confirmed as a low-risk order or a high-risk order, the third-party risk detection model is used to confirm whether the payment order is a high-risk order or a low-risk order. For high-risk orders, the transaction process is suspended to verify the user's true identity. The transaction process resumes after the verification is successful.

[0008] On the other hand, a fraud payment detection device provided to meet one of the purposes of this application includes an event response module, a first order confirmation module, a second order confirmation module, and an order interception module. The event response module is used to respond to a user-triggered transaction payment event and uses a local risk detection model to determine the real-time fraud risk level of the payment order corresponding to the event. The local risk detection model is trained based on a risk order dataset, which includes multi-dimensional feature data corresponding to multiple historical payment orders and a priori fraud risk level corresponding to the risk type of the historical payment order detected by a third-party risk detection model. The first order confirmation module is used to confirm the payment order as a low-risk order or a high-risk order when the real-time fraud risk level does not exceed a first preset threshold or exceeds a second preset threshold, where the second preset threshold is greater than the first preset threshold. The second order confirmation module is used to confirm the payment order as a high-risk order or a low-risk order using the third-party risk detection model when the payment order is not confirmed as a low-risk order or a high-risk order. The order interception module is used to suspend the transaction process for high-risk orders, verify the user's true identity, and continue the transaction process after successful verification.

[0009] In another aspect, a computer device provided for one of the purposes of this application includes a central processing unit and a memory, the central processing unit being used to invoke and run a computer program stored in the memory to perform the steps of the fraud payment detection method described in this application.

[0010] In another aspect, a computer program product provided for another purpose of this application includes a computer program / instructions that, when executed by a processor, implement the steps of the method described in any embodiment of this application.

[0011] The technical solution of this application has many advantages, including but not limited to the following aspects: This application first uses a local risk detection model to conduct a preliminary fraud risk assessment of payment orders, and directly makes the corresponding risk judgment when the fraud risk level is clearly in the low-risk or high-risk range. Only when the situation is unclear will a third-party risk detection model be called for secondary confirmation. This effectively reduces the reliance on external risk control services, thereby significantly saving operating costs and avoiding the high costs incurred by calling third-party services for all orders. At the same time, it ensures the overall economic efficiency of the detection service provided by this application.

[0012] Secondly, the local risk detection model uses the multi-dimensional features of the platform's own historical orders as training material and the "prior fraud risk level" previously labeled by the third-party model as a supervision label. This allows the model to inherit the discrimination experience of the third-party fraud detection service without the need for manual rule writing, enabling fully localized deployment and real-time reasoning, thus ensuring the accuracy and confidence of the reasoning results.

[0013] In addition, measures such as suspending transactions and verifying user identities are taken for high-risk orders to ensure the controllability of high-risk transactions, intercept payment behavior of illegal users, and ensure that only verified legitimate users can complete payments for high-risk orders. Attached Figure Description

[0014] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, wherein: Figure 1 The network architecture of the e-commerce platform exemplified in this application; Figure 2 This is a flowchart illustrating a typical embodiment of the fraud payment detection method of this application; Figure 3 This is a schematic block diagram of the fraud payment detection device of this application; Figure 4 This is a schematic diagram of the structure of a computer device used in this application. Detailed Implementation

[0015] The embodiments of this application are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain this application, and should not be construed as limiting this application.

[0016] Those skilled in the art will understand that, unless specifically stated otherwise, the singular forms “a,” “an,” “the,” and “the” used herein may also include the plural forms. It should be further understood that the term “comprising” as used in this application means the presence of the stated features, integers, steps, operations, elements, and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof. It should be understood that when we say an element is “connected” or “coupled” to another element, it can be directly connected or coupled to the other element, or there may be intermediate elements. Furthermore, “connected” or “coupled” as used herein can include wireless connections or wireless coupling. The term “and / or” as used herein includes all or any units and all combinations of one or more associated listed items.

[0017] Those skilled in the art will understand that, unless otherwise defined, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains. It should also be understood that terms such as those defined in general dictionaries should be understood to have the same meaning as in the context of the prior art, and should not be interpreted in an idealized or overly formal sense unless specifically defined as herein.

[0018] like Figure 1 In the network architecture shown, the e-commerce platform 82 is deployed on the Internet to provide corresponding services to its users. Similarly, the devices 80 of the merchant users and the devices 81 of the consumer users of the e-commerce platform 82 are also connected to the Internet to use the services provided by the e-commerce platform.

[0019] An exemplary e-commerce platform 82 provides supply and demand matching of products and / or services to the general public through the Internet infrastructure. In e-commerce platform 82, products and / or services are provided as commodity information. For the sake of simplicity, the concepts of commodity and product are used in this application to refer to the products and / or services in e-commerce platform 82. Specifically, these may be physical products, digital products, tickets, service subscriptions, other offline services, etc.

[0020] In reality, various entities can access e-commerce platform 82 as users and utilize its online services to participate in the business activities facilitated by the platform. These entities can be natural persons, legal persons, or social organizations. Corresponding to the two types of entities in business activities—merchants and consumers—e-commerce platform 82 has two corresponding categories of users: merchant users and consumer users. Entities involved in the product distribution chain in business activities, including manufacturers, sellers, retailers, and logistics providers, can all use online services on e-commerce platform 82 as merchant users. Similarly, consumers in business activities, including actual or potential consumers, can use online services on e-commerce platform 82 as consumer users. In actual business activities, the same entity can operate as both a merchant user and a consumer user; this should be interpreted flexibly.

[0021] The infrastructure used to deploy the e-commerce platform 82 mainly includes the backend architecture and frontend devices. The backend architecture runs various online services through a service cluster, including middleware or frontend services for the platform, services for consumers, and services for merchants, to enrich and improve its service functions. The frontend devices mainly cover the terminal devices used by users as clients to access the e-commerce platform 82, including but not limited to various mobile terminals, personal computers, and point-of-sale devices. For example, merchant users can use their terminal device 80 to enter product information for their online stores or use the interfaces opened by the e-commerce platform to generate their product information; consumer users can use their terminal device 81 to access the webpage of the online store implemented by the e-commerce platform 82, trigger the shopping process by clicking the shopping button provided on the webpage, and call various online services provided by the e-commerce platform 82 during the shopping process to achieve the purpose of placing an order.

[0022] In some embodiments, the e-commerce platform 82 may be implemented via a processing facility including a processor and memory, which stores a set of instructions that, when executed, cause the e-commerce platform 82 to perform the e-commerce and support functions as described in this application. The processing facility may be part of a server, client, network infrastructure, mobile computing platform, cloud computing platform, fixed computing platform, or other computing platform, and may provide electronic components, merchant devices, payment gateways, application developers, marketing channels, transportation providers, customer devices, point-of-sale devices, etc., for the e-commerce platform 82.

[0023] E-commerce platform 82 can provide online services such as cloud computing services, Software as a Service (SaaS), Infrastructure as a Service (IaaS), Platform as a Service (PaaS), Desktop as a Service (DaaS), Hosted Software as a Service, Mobile Backend as a Service (MBaaS), and Information Technology Management as a Service (ITMaaS). In some embodiments, the various functional components of e-commerce platform 82 can be implemented to operate on various platforms and operating systems. For example, for an online store, its administrator user enjoys the same or similar functions regardless of whether it is on iOS, Android, HomonyOS, or a web page.

[0024] E-commerce platform 82 enables merchants to create their own independent websites to run their online stores. It provides merchants with corresponding business management engine instances, allowing them to establish, maintain, and operate one or more online stores across these independent websites. The business management engine instance can be used for content management, task automation, and data management for one or more online stores. It can be configured through interfaces or built-in components to support various specific business processes in the online store, supporting business activities. Independent websites are the infrastructure of e-commerce platform 82, which offers cross-border services. Merchants can maintain their online stores relatively independently and centrally based on these independent websites. Independent websites typically have dedicated domain names and storage space, and different independent websites are relatively independent. E-commerce platform 82 can provide standardized or customized technical support for a large number of independent websites, allowing merchants to customize a business management engine instance that suits their needs and use it to maintain one or more online stores.

[0025] Online stores can be configured and maintained in the backend by merchant users logging into their Business Management Engine instance as administrators. Supported by the various online services provided by the e-commerce platform 82's infrastructure, merchant users can configure various functions within their online stores and view various data as administrators. For example, merchant users can manage various aspects of their online stores, such as viewing recent online store activities, updating the online store's product catalog, managing orders, recent visit activity, and total order activity. Merchant users can also view more detailed information about their business and visitors to their online store by obtaining reports or metrics, such as displaying a sales summary of the merchant's overall business, specific sales and engagement data from promotional sales and marketing channels, etc.

[0026] E-commerce platforms 82 can provide communication facilities and associated merchant interfaces for electronic communication and marketing. For example, they can utilize electronic messaging aggregation facilities to collect and analyze communication interactions between merchants, consumers, merchant devices, customer devices, point-of-sale devices, etc., aggregating and analyzing communications to increase the potential for product sales. For instance, a consumer may have product-related questions, which could lead to a dialogue between the consumer and the merchant (or an automated processor-based agent representing the merchant), where the communication facilities handle the interaction and provide the merchant with analysis on how to increase the probability of a sale.

[0027] In some embodiments, applications suitable for installation on terminal devices can be provided to serve the access needs of different users, enabling various users to access the e-commerce platform 82 by running the application on their terminal devices. Examples include the merchant backend module of online stores within the e-commerce platform 82. During the process of conducting business activities through these functions, the e-commerce platform 82 can implement various functions related to business activities as middleware or online services and expose corresponding interfaces. Then, toolkits corresponding to the interface access functions are embedded into the application to achieve functional expansion and task completion. The business management engine can include a series of basic functions and expose these functions to online services and / or applications via APIs. Online services and applications use the corresponding functions by remotely calling the corresponding APIs.

[0028] With the support of various components of the Business Management Engine instance, E-commerce Platform 82 can provide online shopping functionality, enabling merchants to connect with customers in a flexible and transparent manner. Consumers can select items online, create orders, provide delivery addresses in the orders, and complete payment confirmation. Merchants can then review and complete or cancel orders.

[0029] The fraud payment detection method of this application can be programmed into a computer program product and deployed on a client or server. For example, in an exemplary application scenario of this application, it can be deployed on the server of an e-commerce customer service platform. In this way, the method can be executed by human-computer interaction with the process of the computer program product through a graphical user interface by accessing the interface opened after the computer program product is running.

[0030] Please see Figure 2 The fraud payment detection method of this application, in its typical embodiment, includes the following steps: Step S1100: In response to a user-triggered transaction payment event, a local risk detection model is used to determine the real-time fraud risk level of the payment order corresponding to the event. The local risk detection model is trained based on a risk order dataset, which includes multi-dimensional feature data corresponding to multiple historical payment orders and prior fraud risk levels corresponding to the risk type of the corresponding historical payment orders detected by a third-party risk detection model. In e-commerce platforms, when a user confirms payment on the front-end visual interface and triggers a transaction payment event, the event is captured by the e-commerce platform's back-end server. The server then retrieves the payment order generated by this payment and checks whether it belongs to a high-risk type of order, i.e. whether further control is needed to avoid unnecessary losses.

[0031] It is understandable that the local risk detection model is not a traditional, static risk control algorithm based on manual rules, but rather an inference model built using machine learning technology. It is "trained on a risk order dataset." The key feature of this dataset is its annotation information: "the prior fraud risk level corresponding to the risk type of historical payment orders detected by the third-party risk detection model." This means that during the model training phase, the advantages of third-party risk control services in terms of cross-platform data breadth and model professionalism are utilized. This is equivalent to leveraging the accurate and comprehensive detection capabilities of the third-party risk detection model as a discriminator in the field of fraud payment detection, using its detection results on historical payment orders as high-quality, non-manually detected supervisory labels. This allows the trained local risk detection model to learn the judgment logic and knowledge of the third-party risk detection model. Moreover, since it is deployed internally on the server, it does not require real-time invocation of the external service's third-party risk detection model for each order during actual use, thus achieving the migration and internalization of external professional capabilities into the internal system.

[0032] Therefore, the first step is to call the locally trained risk detection model deployed on the server, utilizing its pre-trained convergence detection capabilities to detect the payment order generated in this payment. Based on the relevant feature data required by the local risk detection model to infer the fraud risk of the order, this risk is presented as a probability value, quantifying the likelihood of fraud in the order. In some subsequent embodiments, the relevant feature data may be the multi-dimensional feature data of the payment order; in other embodiments, it may be the remaining feature data from the multi-dimensional feature data. Those skilled in the art can flexibly train the local risk detection model to convergence based on the risk order dataset, or they can follow the disclosure in the subsequent embodiments.

[0033] Step S1200: When the real-time fraud risk level does not exceed the first preset threshold or exceeds the second preset threshold, the payment order is confirmed to be a low-risk order or a high-risk order, and the second preset threshold is greater than the first preset threshold. The method maps the real-time fraud risk level output by the local risk detection model to discrete risk types, thereby triggering different subsequent processing logics. Specifically, the method sets two key thresholds: a first preset threshold and a second preset threshold, with the second preset threshold being larger than the first. This ensures the confidence level of determining low-risk and high-risk orders, thus dividing the order into three distinct decision intervals: when the risk level is not higher than the first preset threshold, it is identified as a "low-risk order"; when the risk level is not lower than the second preset threshold, it is identified as a "high-risk order"; and for orders with risk levels between the first and second preset thresholds, the risk is considered unclear, meaning the local risk detection model does not have the ability to accurately detect such payment orders and further processing is required. Those skilled in the art can flexibly configure these two thresholds according to the specific uses of the first and second preset thresholds disclosed herein, or configure them according to the configurations disclosed in subsequent embodiments.

[0034] Step S1300: When the payment order is not confirmed as a low-risk order or a high-risk order, the third-party risk detection model is used to confirm whether the payment order is a high-risk order or a low-risk order. For payment orders that cannot be confirmed by detection, a third-party detection model will be used as a fallback for verification. Specifically, a third-party risk detection model and its data access interface provided by the third-party detection service can be pre-deployed. By enabling the data access interface, the relevant data required for the third-party risk detection model to infer the risk type of the payment order can be obtained. The model can then use this data to infer whether the payment order belongs to a high-risk or low-risk category. In other words, if the inference indicates a high-risk order, it is equivalent to confirming that the payment order is high-risk; if the inference indicates a low-risk order, it is equivalent to confirming that the payment order is low-risk.

[0035] Step S1400: Suspend the transaction process for the high-risk type of order, verify the user's real identity, and continue the transaction process after the verification is successful.

[0036] When a payment order is confirmed to be a high-risk order, the transaction process is first suspended, followed by an initiation of user identity verification. This verification can be implemented in various ways. For example, the terminal can send a one-time SMS verification code to the user's registered mobile phone number, requiring the user to enter the code on the payment interface for verification; alternatively, the terminal can utilize the device's biometric functions, such as facial recognition or fingerprint recognition, to collect the user's biometric features and compare them with features registered in the system to confirm identity; furthermore, the user can be required to provide more detailed personal information, such as their ID card number, and the information can be verified against an authoritative database. Those skilled in the art can configure this verification operation as needed, ensuring that the user's true identity can be verified to guarantee payment security. Further, if the verification result indicates that the user is using their true identity to conduct the transaction, the verification is confirmed as successful; otherwise, the verification is confirmed as unsuccessful. After the user passes the identity verification, the transaction process automatically resumes, allowing the user to continue completing the order payment process, ensuring that legitimate transactions are not affected. If the user fails the identity verification, or if suspicious behavior is observed during the verification process, the transaction process is terminated to prevent potential fraud and thus protect the user's account and fund security.

[0037] When a payment order is confirmed to be a low-risk order, no verification is required, and the user can directly continue to complete the order payment process, eliminating unnecessary intervention steps.

[0038] As can be understood from the disclosure of this exemplary embodiment, this application contains many advantages, including but not limited to the following aspects: This application first uses a local risk detection model to conduct a preliminary fraud risk assessment of payment orders, and directly makes the corresponding risk judgment when the fraud risk level is clearly in the low-risk or high-risk range. Only when the situation is unclear will a third-party risk detection model be called for secondary confirmation. This effectively reduces the reliance on external risk control services, thereby significantly saving operating costs and avoiding the high costs incurred by calling third-party services for all orders. At the same time, it ensures the overall economic efficiency of the detection service provided by this application.

[0039] Secondly, the local risk detection model uses the multi-dimensional features of the platform's own historical orders as training material and the "prior fraud risk level" previously labeled by the third-party model as a supervision label. This allows the model to inherit the discrimination experience of the third-party fraud detection service without the need for manual rule writing, enabling fully localized deployment and real-time reasoning, thus ensuring the accuracy and confidence of the reasoning results.

[0040] In addition, measures such as suspending transactions and verifying user identities are taken for high-risk orders to ensure the controllability of high-risk transactions, intercept payment behavior of illegal users, and ensure that only verified legitimate users can complete payments for high-risk orders.

[0041] In a further embodiment, before step S1100, which responds to a user-triggered transaction payment event, the following steps are included: Step S1000: Obtain the risk order dataset. For each historical payment order in the dataset, take the multi-dimensional feature data corresponding to the historical payment order as a sample, and take the prior fraud risk level of the historical payment order as the supervision label of the sample. Multiple historical payment orders within a historical time range can be collected, and then feature engineering is used to determine the multidimensional feature data corresponding to each historical payment order. Furthermore, for each historical payment order, if the third-party risk detection model determines that the historical payment order belongs to a high-risk order type, the prior fraud risk level representing this risk type can be marked as 1; if the third-party risk detection model determines that the historical payment order belongs to a low-risk order type, the prior fraud risk level representing this risk type can be marked as 0. Each historical payment order is associated with its marked prior fraud risk level to form a risk order dataset. The historical time range can be configured as needed by those skilled in the art, for example: [January 1, 2024 to December 31, 2024] Therefore, for each sample, the prior fraud risk level of its corresponding historical payment order can be used as a supervision label and applied to the binary classification training task of the local risk detection model.

[0042] Multidimensional feature data includes feature data corresponding to multiple dimensions of the payment order. These dimensions include, but are not limited to, any and more of the following: The payment order includes the payment device fingerprint, payment behavior sequence (including all user behaviors occurring from browsing products to generating the payment order), payment credit card account, credit card billing country / city / address, credit card issuing bank, credit card billing email address, credit card billing mobile number, cardholder name, credit card expiration date, payment email address, payment mobile number, payment IP address, country / city of payment IP address, receiving mobile number, receiving email address, receiving name, whether the credit card billing country / city matches the corresponding payment IP country / city, whether the credit card billing country / city / address / mobile number matches the corresponding receiving country / city / address / mobile number, and whether the cardholder's name matches the receiving name. Name similarity, number of days since credit card expiration, order amount, currency, store / merchant, payment time, duration from order creation to payment, number of payment failures, number of password retries, number of card replacements, total number of products viewed in the payment sequence, cumulative duration of viewing products purchased by the user in the payment sequence, whether the user followed the product before purchasing it in the payment sequence, time since the user first viewed the product in the payment sequence, whether the user added the product to their cart before purchasing it in the payment sequence, whether the payment credit card account is on a blacklist, access IP / payment IP. Whether the user is on a blacklist, whether the credit card email / delivery email is on a blacklist, and whether the credit card billing phone number / delivery phone number is on a blacklist; in addition, the following data are also included: the characteristic data of the aforementioned credit card account, device fingerprint, payment email, and payment phone number, when used for multiple payment orders in the last x hours / y days, the corresponding number and amount of payment orders, the number and amount of failed payments, the number of stores purchased, the number of countries / cities / addresses of payment IPs, the number of payment device fingerprints, the number of countries / cities / addresses of delivery, the number of payment emails, the number of payment phone numbers, the number of delivery emails, and the number of delivery phone numbers, where x can be 1 / 3 / 6 / 12, and y can be 1 / 3 / 5 / 7 / 15. Those skilled in the art can also define these values ​​separately based on the platform's computing power and business experience.

[0043] Understandably, the multi-dimensional feature data corresponding to all high-risk type orders that fail verification and are confirmed at any time can be added to a blacklist.

[0044] It is understandable that the feature data for the corresponding dimension is a specific string, number, or boolean value. For example, if the dimension is: payment credit card account, its feature data is "547472...2880087"; if the dimension is: payment order amount, its feature data is "500"; if the dimension is: whether the credit card billing mobile number / receiving mobile number is on the blacklist, its feature data is "yes".

[0045] It is understandable that for each historical payment order, if the third-party risk detection model determines that the historical payment order belongs to a high-risk type, the prior fraud risk level representing this risk type can be labeled as 1; if the third-party risk detection model determines that the historical payment order belongs to a low-risk type, the prior fraud risk level representing this risk type can be labeled as 0. Therefore, for each sample, the prior fraud risk level of its corresponding historical payment order can be used as a supervision label for the binary classification training task of the local risk detection model.

[0046] Step S1001: Take a portion of the samples within the most recent historical period as prediction samples, divide the remaining samples into training samples, validation samples, and test samples according to a preset ratio, associate each type of sample with its supervision label, and construct the prediction set, validation set, training set, and test set accordingly.

[0047] The most recent historical period is relatively new compared to other periods within the historical time range. The specific duration of this period can be configured as needed by those skilled in the art. For example, 2 months would correspond to the most recent historical period as [November 1, 2024 to December 31, 2024].

[0048] The preset ratios used to divide the training, validation, and test samples can be configured as needed by those skilled in the art, for example, 7:1.5:1.5. This means that 70% of the remaining samples are divided into training samples, 15% into validation samples, and 15% into test samples. It can be seen that each sub-ratio in the preset ratio is the ratio of the number of samples of the corresponding class to the number of remaining samples.

[0049] This embodiment reveals the construction process of the prediction set, validation set, training set, and test set, laying the foundation for subsequent model training and evaluation.

[0050] In a further embodiment, after step S1001, which associates various types of samples with their supervision labels and constructs the prediction set, validation set, training set, and test set accordingly, the following steps are included: Step S2000: After training the local risk detection model for one cycle using the training set, evaluate the local risk detection model using the validation set to determine the validation performance metrics. In training a local risk detection model, the model is first trained for a full training cycle using the training set. A training cycle refers to the process by which the model learns all samples in the training set once. Immediately after training, the model performance for the current cycle is evaluated using the validation set, and validation performance metrics are calculated. Validation performance metrics are evaluation standards that quantify the model's performance on unseen data, such as AUC or F1 score, which can be configured as needed by those skilled in the art. Evaluation using the validation set allows monitoring of the model's generalization ability during training and prevents overfitting.

[0051] Step S2010: When the verification performance index exceeds the verification performance index of all previous periods, save the local risk detection model for this period and reset the current unoptimized cumulative rounds to zero. The unoptimized cumulative rounds are initialized to zero. When the validation performance metric exceeds that of all previous training epochs, save the local risk detection model for the current training epoch and reset the current unoptimized cumulative epochs to zero. The unoptimized cumulative epochs is a counter that records how many consecutive training epochs the model has not shown performance improvement. Initially, this counter is set to zero. Whenever the model achieves better performance on the validation set in the current training epoch than in all previous epochs, it indicates that the model is optimizing in the right direction. At this point, save the current model parameters and structure, as this may represent a better state of the model, and reset the unoptimized cumulative epochs to zero to restart counting potential performance plateaus.

[0052] Step S2020: When the verification performance index does not exceed the verification performance index of all previous cycles, increment the current unoptimized cumulative rounds by one, and determine whether the incremented unoptimized cumulative rounds exceed the tolerance limit. When the validation performance metric does not exceed the validation performance metric of all previous training epochs, the current cumulative unoptimized epochs are incremented by one. This indicates that the model's performance has not improved in the current training epoch, and it may have reached a local optimum or begun overfitting. At this point, it is necessary to determine whether the incremented cumulative unoptimized epochs exceed the tolerance cap. The tolerance cap is a predefined threshold used to determine the maximum number of epochs that can be allowed to continue training without improving model performance. For example, the tolerance cap can be set to 3 or 5, and those skilled in the art can configure it according to the complexity of the model training and the size of the data. If the cumulative unoptimized epochs exceed the tolerance cap, it means that the model can no longer achieve further performance improvement by continuing the current training strategy.

[0053] Step S2030: When the cumulative number of unoptimized rounds does not exceed the tolerance limit, iterate the above process; otherwise, call the test samples and their supervision labels that were not used for evaluation in the test set to evaluate the trained local risk detection model and determine the test performance indicators. As long as the unoptimized cumulative epochs do not exceed the tolerance cap, the entire process continues. During this process, the model continuously adjusts its parameters, attempting to find better feature representations and decision boundaries to optimize validation performance metrics. After each training epoch, the model performance is re-evaluated using the validation set, and the unoptimized cumulative epochs counter is updated. If, within some epoch within the tolerance cap, the model performance improves again, the unoptimized cumulative epochs are reset, and this process continues.

[0054] When the cumulative number of unoptimized epochs exceeds the tolerance limit, the unused test samples and their supervision labels from the test set are used to evaluate the trained local risk detection model and determine the test performance metrics. The test set is a third dataset completely independent of the training and validation sets, used for final performance evaluation after model training. The purpose of using the test set is to ensure that the model can generalize to previously unseen data, thus accurately reflecting its performance in real-world applications. Test performance metrics can also employ one or more standards, such as AUC or F1 score, which can be configured as needed by those skilled in the art. The model's performance on the test set is calculated by comparing it with the supervision labels of the test samples.

[0055] Step S2040: When the test performance index does not exceed the target performance index, update the tolerance upper limit value with a preset expansion value increment, and iterate the above process; otherwise, confirm that the saved local risk detection model has been trained to a convergent state, and use it to determine the real-time fraud risk level of payment orders.

[0056] When the test performance metric fails to reach the target performance metric, the tolerance cap is updated incrementally with a preset expansion value, and the entire process is repeated. The target performance metric is a pre-set expected value based on specific business needs, used to measure whether the test performance metric has been met. For example, in a payment scenario, the model's F1 score needs to reach 0.9. This can be configured as needed by those skilled in the art. The preset expansion value is a fixed increment used to increase the tolerance cap, allowing the model to continue exploring potential performance improvements over more training cycles. This can also be configured as needed. For example, the preset expansion value could be 2 or 3, meaning the tolerance cap increases by the corresponding value with each update. In this way, the model has the opportunity to break through the current performance bottleneck and continue exploring potentially better solutions.

[0057] When the test performance metrics reach or exceed the target performance metrics, it is confirmed that the saved local risk detection model has been trained to a convergent state and is used to determine the real-time fraud risk level of payment orders. Convergence means that the model parameters have stabilized, the training process has sufficiently optimized the model's performance, and the model can accurately predict the fraud risk level on new payment orders. At this point, the model can be deployed online for real-time risk assessment of each payment order, helping to identify potential fraudulent activities and protect users' account and fund security.

[0058] In this embodiment, by using the best performance of the validation set as the sole archiving standard, supplemented by an unoptimized round counter, the system can effectively stop the model from overfitting before it begins. Furthermore, the flexible strategy of "automatically increasing the tolerance limit if the test set fails to meet the standard" allows the model room to escape local optima, balancing training efficiency and global optimization capabilities. Compared to a fixed tolerance limit that might prematurely terminate the process and prevent the exploration of the optimal performance solution, this process can automatically find a relatively small number of training steps to achieve sufficient training even with limited computing power, reducing GPU time and energy costs while ensuring that the deployed model meets business performance standards, thus achieving dual optimization of "performance and resources."

[0059] In a further embodiment, after step S1001, which associates various samples with their supervision labels to construct a prediction set, validation set, training set, and test set, or after step S2040, which confirms that the saved local risk detection model has been trained to a convergent state to determine the real-time fraud risk level of payment orders, the following steps are included: Step S3000: Obtain the local risk detection model trained to convergence and the inference importance index of each feature data in the multi-dimensional feature data for the model; determine the test performance index of the model based on the test set. The local risk detection model here is a stable model that has undergone a series of training, validation, and testing processes, capable of accurately inferring the fraud risk level of payment orders. The multi-dimensional feature data contains numerous features related to payment orders, each with its corresponding inference importance metric, reflecting the magnitude of the feature's role in the model's inference process. The inference importance metric can be extracted using `feature_importance`, and those skilled in the art can also flexibly employ other algorithms to measure the inference importance of each feature in the multi-dimensional feature data. Test performance metrics, such as AUC or F1 score, are used to measure the model's performance on the test set and can be configured as needed by those skilled in the art.

[0060] Step S3010: In the training set, validation set, and test set, remove the feature data with the lowest inference importance index in each sample, retrain the local risk detection model to convergence based on the removed training set and validation set, and determine the performance index of the model in this round based on the removed test set. In the training, validation, and test sets, features with the lowest inference importance in each sample are removed. This is because features with low inference importance contribute little to the model's inference of payment order fraud risk. Removing these features simplifies the model, improves its efficiency, and may not significantly reduce its performance. For example, if a feature's inference importance is significantly lower than other features, and analysis shows its impact on fraud risk judgment is negligible, it can be removed. Based on the removed training and validation sets, the local risk detection model is retrained to convergence. This process is similar to the training process mentioned earlier, requiring continuous adjustment of model parameters and performance evaluation using the validation set until convergence. Finally, the model's performance metrics for this round are determined based on the removed test set to verify the model's performance after feature removal.

[0061] Step S3020: When the difference between the test performance index and the current round performance index does not exceed the tolerance value, return to the previous step to continue execution; otherwise, obtain the local risk detection model from the previous round to determine the real-time fraud risk level of the payment order.

[0062] The system determines whether the difference between the test performance metric and the current performance metric does not exceed the tolerance value. The tolerance value is a pre-defined threshold used to measure the allowable range of difference between the test performance metric and the current performance metric. If the difference does not exceed the tolerance value, it means that the model performance change after removing low-importance features is within an acceptable range. In this case, the system returns to its previous state and continues with further optimization or feature selection. Conversely, if the difference exceeds the tolerance value, it means that feature removal has had a significant negative impact on model performance. In this case, the previous round of local risk detection model—the model before feature removal—is retrieved to determine the real-time fraud risk level of payment orders, ensuring the accuracy of fraud detection. Essentially, by selecting and retraining model features, a model with better performance and efficiency is found to better adapt to actual fraud payment detection needs.

[0063] In this embodiment, by leveraging the feature importance of the converged model output, dimensions that contribute little to fraud detection are removed one by one. The model is then retrained using the removed data, and the performance degradation is compared. When the degradation is within the tolerance band, the simplified model is accepted. This closed loop allows e-commerce platforms to compress input features to fewer while maintaining detection accuracy, reducing inference latency and memory usage. This is particularly beneficial for millisecond-level real-time risk control during peak sales periods. Moreover, the removal process is entirely data-driven, avoiding blind spots caused by manual deletion and ensuring that each dimension removed is "verifiable and tolerable." The final delivery is a lighter, faster, and more cost-effective yet still accurate local model.

[0064] In a further embodiment, after step S1001, which associates various types of samples with their supervision labels and constructs the prediction set, validation set, training set, and test set accordingly, the following steps are included: Step S1002: Infer the predicted fraud risk level of each predicted sample in the prediction set from the local risk detection model that has been trained to a convergent state; The local risk detection model, trained to convergence, is invoked to infer the predicted fraud risk level of each sample in the prediction set. The key to this step is that the model has reached a stable state through training, validation, and testing, enabling it to accurately predict the fraud risk of payment orders. The predicted fraud risk level is a probability value within the range [0,1], used to quantify the likelihood of fraud in the payment order.

[0065] Those skilled in the art should understand that, for the local risk detection model trained to a convergent state obtained in steps S3000 to S3020 in a further embodiment, only the relevant feature data in the prediction samples in the prediction set can be selected according to the relevant feature data on which its reasoning is based, and then used to provide the model for reasoning.

[0066] Step S1003: For multiple measurable proportions with an increasing relationship, set a first fraud risk level corresponding to each measurable proportion, such that the proportion of the number of predicted samples in the sample subset with a preset fraud risk level less than the first fraud risk level to the total number of all samples in the prediction set is equal to the measurable proportion corresponding to the first fraud risk level. To set the first preset threshold, it is necessary to define a first fraud risk level corresponding to each of the multiple measurable proportions with an increasing relationship. Here, the measurable proportion refers to the percentage of samples in the prediction set whose predicted fraud risk level is less than the percentage corresponding to a single first fraud risk level. Each measurable proportion corresponds to a first fraud risk level, such that the proportion of samples with predicted fraud risk levels below that level to the total number of samples in the prediction set is equal to that measurable proportion. This allows the model to detect low-risk orders at different first fraud risk levels, corresponding to the proportions (i.e., measurable proportions) that it can detect. Multiple different measurable proportions, such as 10%, 20%, 30%, 40%, 50%, 60%, etc., can be further configured as needed based on the information disclosed herein.

[0067] A subset of samples corresponding to a single first fraud risk level includes predicted samples corresponding to each predicted fraud risk level that is less than the first fraud risk level.

[0068] Step S1004: For each first fraud risk level, based on the risk type represented by the supervision label of each predicted sample in the prediction set, statistically determine the proportion of false detections corresponding to the first fraud risk level. The proportion of false detections is the ratio between the number of predicted samples of high-risk type orders in the sample subset of the first fraud risk level and the number of predicted samples of high-risk type orders in the prediction set. For each defined first fraud risk level, the corresponding misclassification rate needs to be statistically determined based on the supervision labels of the samples in the prediction set. The misclassification rate is the ratio between the number of samples in the subset corresponding to the fraud risk level whose supervision labels represent high-risk orders and the number of samples in the prediction set whose supervision labels represent high-risk orders. This allows for the assessment of the model's misclassification of high-risk orders under different first fraud risk levels.

[0069] Step S1005: Select one of the multiple first fraud risk levels as the first preset threshold based on the total measurable proportion and the total false detection proportion.

[0070] The selection process here aims to find a balance point, ensuring a certain detection coverage while minimizing false positives. In one embodiment, the first fraud risk level corresponding to the largest proportion of detectable data and the proportion of false positives not exceeding the fault tolerance ratio (e.g., 2.8%, which can be configured as needed by those skilled in the art) is selected as the first preset threshold. In another embodiment, the first fraud risk level corresponding to the largest proportion of detectable data and zero proportion of false positives is selected as the first preset threshold.

[0071] In this embodiment, by using a three-stage threshold screening of "prediction set - measurable proportion - false positive proportion", the originally continuous fraud risk level is mapped to a low-risk range acceptable to the business. Its biggest advantage is "letting the numbers speak for themselves": by enumerating the proportion of orders that can be let through by the model under different thresholds (measurable proportion) and the high-risk orders mixed in (false positive proportion), operators can see at a glance "how many good orders were let through and how many bad orders were missed", thereby locking the first preset threshold at the sweet spot of "maximizing the number of orders allowed through and controlling the false positive and false negative rates". This quantitative method based on historical backtesting is more in line with the platform's own business distribution than the traditional manually set threshold, ensuring accuracy and interpretability.

[0072] In a further embodiment, after step S1005, selecting one of the multiple first fraud risk levels as the first preset threshold based on the measurable proportion and the false detection proportion, the following steps are included: Step S1006: Obtain multiple second fraud risk levels with an increasing relationship; determine the precision and recall corresponding to the second fraud risk level based on the risk type represented by the predicted fraud risk level exceeding the second fraud risk level and the risk type represented by the supervision label of each predicted sample in the prediction set. Multiple different second fraud risk levels, such as 0.05, 0.30, 0.35, 0.40, 0.45, 0.50, 0.51, 0.52, 0.53, 0.54, 0.55, etc., can be sorted by those skilled in the art, and then configured according to the multiple predicted fraud risk levels mainly distributed in the sorted sequence.

[0073] It can be understood that, for each second fraud risk level, a predicted sample whose fraud risk level exceeds that second fraud risk level indicates that the predicted risk type of the sample is a high-risk order. If the risk type represented by the supervision label of the predicted sample is a high-risk order, then the predicted sample is a true positive sample (TP); if the risk type represented by the supervision label of the predicted sample is a low-risk order, then the predicted sample is a false positive sample (FP). Furthermore, a predicted sample whose fraud risk level exceeds that second fraud risk level indicates that the predicted risk type of the sample is a low-risk order; if the risk type represented by the supervision label of the predicted sample is a high-risk order, then the predicted sample is a false positive sample (FN).

[0074] For each second fraud risk level, the precision is the proportion of the number of samples with supervisory labels representing high-risk orders in all predicted samples corresponding to all predicted fraud risk levels exceeding that second fraud risk level, i.e., the proportion = TP / (TP+FP); the recall is the ratio between the number of samples with supervisory labels representing high-risk orders (TP) in all predicted samples corresponding to all predicted fraud risk levels exceeding that second fraud risk level and the number of samples with supervisory labels representing high-risk orders (TP+FN) in the prediction set.

[0075] Step S1007: Filter out the second fraud risk level whose precision rate exceeds the precision rate of the online application, and use it as the second preset threshold.

[0076] The precision rate for online application is used to measure whether the precision rate is high enough to determine whether the application meets the online application standard, such as 90%. Those skilled in the art can configure it as needed based on the disclosure herein.

[0077] In this embodiment, by introducing a hard threshold of "precision rate ≥ online application precision rate" under the same backtesting framework, a second preset threshold is used for reverse screening. This ensures that the accuracy of any interval marked as "high risk" by the local model is not lower than the standard required by the business, thereby significantly reducing customer service complaints and GMV losses caused by "false positives". Since precision rate and recall rate are calculated simultaneously, the operator can intuitively weigh "accurate detection" and "complete detection", locking the high-risk threshold above the business's acceptable confidence level, providing a reliable basis for the subsequent "direct interception + identity verification" link.

[0078] In a further embodiment, before step S1300, which uses the third-party risk detection model to confirm whether the payment order is a high-risk or low-risk order, the following steps are included: Step S1201: Obtain at least one high-risk type order that has been detected and identified within the preset recent time period; The preset nearest time period is the duration closest to the current time. This duration can be configured as needed by those skilled in the art, provided that the timeliness and reliability of the order acquisition are ensured, for example, 2 hours.

[0079] This step is performed before the third-party risk detection model confirms whether the payment order is a low-risk or high-risk order, if the payment order is not confirmed as a low-risk or high-risk order.

[0080] Step S1202: When the payment order is associated with the same target dimension feature data as any of the high-risk type orders, the payment order is confirmed to be a high-risk type order. The target dimension includes at least one dimension determined based on a preset posterior strategy, which is used to improve the recall rate of the local risk detection model and is associated with the payment order.

[0081] In one embodiment, the preset posterior strategy refers to determining at least one dimension that can improve the recall rate of the local risk detection model and is associated with payment orders through recall experiments. Specifically, after step S1007, which filters out the second fraud risk level whose precision rate exceeds that of the online application as the second preset threshold, the following steps are included: Step S1008: Based on the multiple candidate dimensions selected by the preset fraud detection operation strategy, construct a corresponding set of multiple recall dimensions, each set of recall dimensions containing at least one candidate dimension. Fraud detection operational strategies are defined as patterns discovered by e-commerce platform operators during manual risk screening. These patterns manifest as follows: among multiple payment orders sharing similar characteristic data (e.g., specific payment email addresses and / or payment phone numbers and / or payment behavior sequences), if any one payment order is manually identified as a high-risk order, the remaining payment orders are also identified as high-risk. Therefore, the dimensions exhibiting this pattern are selected as candidate dimensions. Furthermore, each candidate dimension can independently constitute a recall dimension set, or it can form different recall dimension sets with any other candidate dimensions.

[0082] Step S1009: For each recall dimension set, select multiple recall prediction samples from the prediction set. Each recall prediction sample contains feature data of all candidate dimensions in the recall dimension set, and the prediction fraud risk of some recall prediction samples exceeds the second preset threshold, while the prediction fraud risk of other recall prediction samples does not exceed the second preset threshold. Step S1010: For each recalled prediction sample whose predicted fraud risk level does not exceed the second preset threshold, modify the predicted fraud risk level of the recalled prediction sample to exceed the second preset threshold. Step S1011: Re-determine the predicted fraud risk level exceeding the second preset threshold in the prediction set; and determine the recall rate corresponding to the recall dimension set based on the risk type represented by the predicted fraud risk level and the risk type represented by the supervision label of each predicted sample in the prediction set. The ratio between the number of samples (TP) representing high-risk type orders under supervisory labels and the number of samples (TP+FN) representing high-risk type orders under supervisory labels in the prediction set, which is the recall rate corresponding to the recall dimension set, is used as the recall rate for all predicted fraud risk levels that exceed the second fraud risk level again.

[0083] Step S1012: When the recall rate corresponding to the recall dimension set exceeds the recall rate of the local risk detection model, the candidate dimensions in the recall dimension set are confirmed as the target dimensions.

[0084] The recall rate of the local risk detection model, that is, the recall rate corresponding to the second fraud risk level, which is the second preset threshold.

[0085] At this point, it means that the recall rate has improved, so these alternative dimensions can be used as target dimensions.

[0086] In this embodiment, the "recall dimension" post-test strategy essentially transforms the operational experience discovered during manual screening—such as "same email address, same phone number, same behavior sequence must be linked"—into a quantifiable recall rate improvement experiment. By observing whether dimension feature data that conforms to operational experience can truly improve recall rate, the platform can use scientific experiments to screen out truly effective target dimensions. Once confirmed, any new online orders that hit the same dimension and have recently had high-risk orders can be immediately upgraded to high-risk locally without needing to call a third party. This allows for the recovery of high-risk orders that the local risk detection model could not detect while ensuring accuracy, achieving low-cost and accurate recall driven by a dual-engine approach of "local model + reliable rule post-test".

[0087] Please see Figure 3This fraud payment detection device, provided to meet one of the purposes of this application, is a functional embodiment of the fraud payment detection method of this application. On another note, this fraud payment detection device, also provided to meet one of the purposes of this application, includes an event response module 1100, a first order confirmation module 1200, a second order confirmation module 1300, and an order interception module 1400. The event response module 1100 is used to respond to user-triggered transaction payment events and uses a local risk detection model to determine the real-time fraud risk level of the payment order corresponding to the event. The local risk detection model is trained based on a risk order dataset, which includes multi-dimensional feature data corresponding to multiple historical payment orders and data generated by a third-party risk detection model. The system detects the prior fraud risk level corresponding to the risk type of the corresponding historical payment order; the first order confirmation module 1200 is used to confirm the payment order as a low-risk order or a high-risk order when the real-time fraud risk level does not exceed a first preset threshold or exceeds a second preset threshold, wherein the second preset threshold is greater than the first preset threshold; the second order confirmation module 1300 is used to confirm the payment order as a high-risk order or a low-risk order using the third-party risk detection model when the payment order is not confirmed as a low-risk order or a high-risk order; the order interception module 1400 is used to suspend the transaction process for the high-risk order, verify the user's real identity, and continue the transaction process after the verification is passed.

[0088] In a further embodiment, before the event response module 1100, there are: a dataset acquisition submodule, used to acquire a risk order dataset, corresponding to each historical payment order therein, using the multi-dimensional feature data corresponding to the historical payment order as a sample, and using the prior fraud risk degree of the historical payment order as the supervision label of the sample; and a multi-set construction submodule, used to use a portion of the samples within a preset recent historical period as prediction samples, divide the remaining samples into training samples, validation samples, and test samples according to a preset ratio, associate each type of sample with its supervision label, and construct a prediction set, validation set, training set, and test set accordingly.

[0089] In a further embodiment, after the multi-set construction submodule, the system includes: a first metric determination submodule, used to call the training set to train the local risk detection model for one cycle, and then call the validation set to evaluate the local risk detection model to determine a validation performance metric; a model saving submodule, used to save the local risk detection model for the current cycle and reset the current unoptimized cumulative rounds to zero when the validation performance metric exceeds the validation performance metrics of all previous cycles; and a cumulative judgment submodule, used to determine the current unoptimized cumulative rounds when the validation performance metric does not exceed the validation performance metrics of all previous cycles. The first submodule increments the number of rounds by one and determines whether the cumulative number of unoptimized rounds exceeds the tolerance limit. The second submodule determines the performance index by iterating the above process if the cumulative number of unoptimized rounds does not exceed the tolerance limit. Otherwise, it calls the test samples and their supervision labels that were not used for evaluation in the test set to evaluate the trained local risk detection model and determine the test performance index. The first submodule determines the performance index by updating the tolerance limit with a preset expansion value increment and iterating the above process if the test performance index does not exceed the target performance index. Otherwise, it confirms that the saved local risk detection model has been trained to a convergent state and is used to determine the real-time fraud risk level of the payment order.

[0090] In a further embodiment, after the multi-set construction submodule or the model determination submodule, the following steps are included: a third indicator determination submodule, used to obtain the local risk detection model trained to convergence and the inference importance index of each feature data in the multi-dimensional feature data for the model, and determine the test performance index of the model based on the test set; a feature elimination submodule, used to eliminate the feature data with the lowest inference importance index in each sample in the training set, validation set, and test set, retrain the local risk detection model to convergence based on the eliminated training set and validation set, and determine the current round performance index of the model based on the eliminated test set; and a second model determination submodule, used to return to the previous step and continue execution when the difference between the test performance index and the current round performance index does not exceed the tolerance value; otherwise, obtain the local risk detection model of the previous round to determine the real-time fraud risk level of the payment order.

[0091] In a further embodiment, after the multi-set construction submodule, the system includes: a model inference submodule, used to infer the predicted fraud risk level of each predicted sample in the prediction set from a local risk detection model trained to a converged state; a measurable setting submodule, used to set a first fraud risk level corresponding to each measurable proportion with an increasing relationship, such that the proportion of predicted samples in a sample subset with a preset fraud risk level less than the first fraud risk level is equal to the proportion of measurable proportions corresponding to the first fraud risk level; a false detection determination submodule, used to statistically determine the false detection proportion corresponding to each first fraud risk level based on the risk type represented by the supervision label of each predicted sample in the prediction set, wherein the false detection proportion is the ratio between the number of predicted samples in the sample subset of the first fraud risk level that belong to the high-risk type and the number of predicted samples in the prediction set that belong to the high-risk type; and a threshold selection submodule, used to select one of the multiple first fraud risk levels as a first preset threshold based on the measurable proportion and the false detection proportion.

[0092] In a further embodiment, after the threshold selection submodule, the module includes: an indicator determination submodule, used to obtain multiple second fraud risk levels with an increasing relationship, and determine the precision and recall corresponding to the second fraud risk level based on the risk type represented by the predicted fraud risk level exceeding the second fraud risk level and the risk type represented by the supervision label of each predicted sample in the prediction set; and a threshold filtering submodule, used to filter out the second fraud risk levels whose precision exceeds the precision of the online application as the second preset threshold.

[0093] In a further embodiment, before the second order confirmation module 1300, there are: an order acquisition submodule, used to acquire at least one high-risk type order that has been detected and determined within a preset recent time period; and an order confirmation submodule, used to confirm that the payment order is a high-risk type order when the payment order is associated with feature data of the same target dimension as any of the high-risk type orders, wherein the target dimension includes at least one dimension determined based on a preset posterior strategy, used to improve the recall rate of the local risk detection model and associated with the payment order.

[0094] To address the aforementioned technical problems, embodiments of this application also provide computer equipment. For example... Figure 4The diagram shows the internal structure of a computer device. The computer device includes a processor, a computer-readable storage medium, a memory, and a network interface connected via a system bus. The computer-readable storage medium stores an operating system, a database, and computer-readable instructions. The database may store a sequence of control information. When the computer-readable instructions are executed by the processor, the processor can implement a fraud payment detection method. The processor of the computer device provides computing and control capabilities to support the operation of the entire computer device. The memory of the computer device may store computer-readable instructions. When these computer-readable instructions are executed by the processor, the processor can execute the fraud payment detection method of this application. The network interface of the computer device is used for communication with a terminal. Those skilled in the art will understand that… Figure 4 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0095] In this embodiment, the processor is used to execute... Figure 3 The system contains the specific functions of each module and its sub-modules. The memory stores the program code and various data required to execute these modules or sub-modules. The network interface is used for data transmission between the user terminal and the server. In this embodiment, the memory stores the program code and data required to execute all modules / sub-modules in the fraud payment detection device of this application. The server can call the server's program code and data to execute the functions of all sub-modules.

[0096] This application also provides a storage medium storing computer-readable instructions, which, when executed by one or more processors, cause the one or more processors to perform the steps of the fraud payment detection method of any embodiment of this application.

[0097] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments of this application can be implemented by a computer program instructing related hardware. This computer program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the methods described above. The aforementioned storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0098] In summary, this application can reasonably allocate local and third-party payment risk detection services to ensure payment security and reduce third-party detection costs.

[0099] Those skilled in the art will understand that the steps, measures, and solutions in the various operations, methods, and processes discussed in this application can be alternated, modified, combined, or deleted. Furthermore, other steps, measures, and solutions in the various operations, methods, and processes discussed in this application can also be alternated, modified, rearranged, decomposed, combined, or deleted. Furthermore, steps, measures, and solutions in the prior art that are similar to those in the open-source operations, methods, and processes of this application can also be alternated, modified, rearranged, decomposed, combined, or deleted.

[0100] The above description is only a partial embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method of fraud payment detection, the method comprising: The method comprises the following steps: In response to a transaction payment event triggered by a user, determining a real-time fraud risk degree of a payment order corresponding to the event by using a local risk detection model, wherein the local risk detection model is trained based on a risk order data set comprising multi-dimensional feature data corresponding to a plurality of historical payment orders and a prior fraud risk degree labeled by a third-party risk detection model according to a risk type of the corresponding historical payment orders; When the real-time fraud risk degree does not exceed a first preset threshold or exceeds a second preset threshold, it is determined that the payment order is a low-risk type order or a high-risk type order, and the second preset threshold is greater than the first preset threshold; When the payment order is not determined to be a low-risk type order or a high-risk type order, the third-party risk detection model is used to determine that the payment order is a high-risk type order or a low-risk type order; For the high-risk type order, the transaction process is suspended, the real identity of the user is verified, and the transaction process is continued after the verification is passed.

2. The fraudulent payment detection method of claim 1, wherein, Before responding to a transaction payment event triggered by a user, the following steps are included: Obtain a risk order data set, and for each historical payment order in the risk order data set, use the multi-dimensional feature data corresponding to the historical payment order as a sample and use the prior fraud risk degree of the historical payment order as a supervised label of the sample; Part of the samples in a preset recent historical period are used as prediction samples, and the remaining samples are divided into training samples, validation samples and test samples according to a preset ratio, and each type of sample is associated with its supervised label, and a prediction set, a validation set, a training set and a test set are constructed accordingly.

3. The fraudulent payment detection method of claim 2, wherein, After associating each type of sample with its supervised label and constructing a prediction set, a validation set, a training set and a test set accordingly, the following steps are included: After calling the training set to train the local risk detection model for one cycle, calling the validation set to evaluate the local risk detection model and determining a validation performance indicator; When the validation performance indicator exceeds all previous cycle validation performance indicators, saving the local risk detection model of the current cycle and resetting the current unoptimized cumulative round to zero, wherein the unoptimized cumulative round is initialized to zero; When the validation performance indicator does not exceed all previous cycle validation performance indicators, the current unoptimized cumulative round is increased by one, and it is determined whether the increased unoptimized cumulative round exceeds a tolerance upper limit value; When the unoptimized cumulative round does not exceed the tolerance upper limit value, iterating the above process; Otherwise, calling part of the test samples in the test set and their supervised labels which are not used for evaluation to evaluate the trained local risk detection model and determine a test performance indicator; When the test performance indicator does not exceed a target performance indicator, updating the tolerance upper limit value by a preset expansion value, and iterating the above process; Otherwise, it is determined that the saved local risk detection model is trained to a convergent state and is used to determine a real-time fraud risk degree of a payment order.

4. The fraudulent payment detection method of claim 2 or 3, wherein, After associating various samples with their supervision labels, corresponding prediction set, validation set, training set, and test set are constructed, or after confirming that the saved local risk detection model is trained to a converged state for determining the real-time fraud risk degree of a payment order, the following steps are included: Obtain the local risk detection model trained to a converged state and the inference importance index of each feature data in the multi-dimensional feature data to the model, and determine the test performance index of the model based on the test set; In the training set, validation set, and test set, remove the feature data with the lowest inference importance index in each sample, retrain the local risk detection model to a converged state based on the training set and validation set after removal, and determine the performance index of the model in this round based on the test set after removal; When the difference between the test performance index and the performance index in this round does not exceed the tolerance value, return to the previous step for continuous execution; Otherwise, obtain the local risk detection model in the previous round for determining the real-time fraud risk degree of a payment order.

5. The fraudulent payment detection method of claim 2, wherein, After associating various samples with their supervision labels, corresponding prediction set, validation set, training set, and test set are constructed, and the following steps are included: Infer the predicted fraud risk degree of each prediction sample in the prediction set by the local risk detection model trained to a converged state; Set the first fraud risk degree corresponding to each measurable total proportion with an increasing relationship, so that the proportion of the number of prediction samples in the sample subset with a preset fraud risk degree to the total number of all samples in the prediction set is equal to the measurable total proportion corresponding to the first fraud risk degree; For each first fraud risk degree, according to the risk type represented by the supervision label of each prediction sample in the prediction set, determine the false detection total proportion corresponding to the first fraud risk degree, which is the ratio between the number of prediction samples in the sample subset with the first fraud risk degree and the number of prediction samples in the prediction set that belong to high-risk type orders; Select one of the first fraud risk degrees as the first preset threshold according to the measurable total proportion and the false detection total proportion.

6. The fraudulent payment detection method of claim 5, wherein, After selecting one of the first fraud risk degrees as the first preset threshold according to the measurable total proportion and the false detection total proportion, the following steps are included: Obtain a plurality of second fraud risk degrees with an increasing relationship, and determine the precision and recall corresponding to the second fraud risk degree according to the risk type represented by the prediction fraud risk degree exceeding the second fraud risk degree and the risk type represented by the supervision label of each prediction sample in the prediction set; Screen out the second fraud risk degree with a precision rate exceeding the online application precision rate as the second preset threshold.

7. The fraudulent payment detection method of claim 1, wherein, Before confirming that the payment order is a high-risk type order or a low-risk type order by using the third-party risk detection model, the following steps are included: Obtain at least one high-risk type order that has been detected and determined in a preset recent period; confirm the payment order as a high-risk type order when the payment order is associated with feature data of the same target dimension of any of the high-risk type orders, the target dimension including at least one dimension determined based on a preset posterior strategy for improving a recall rate of the local risk detection model and associated with payment orders.

8. A fraudulent payment detection apparatus characterized by comprising: The method comprises: an event response module configured to respond to a transaction payment event triggered by a user, determine a real-time fraud risk degree of a payment order corresponding to the event by using a local risk detection model, the local risk detection model being trained based on a risk order data set, the risk order data set including multi-dimensional feature data corresponding to a plurality of historical payment orders and a prior fraud risk degree annotated by a third-party risk detection model according to a risk type of the corresponding historical payment orders; a first order confirmation module configured to correspondingly confirm the payment order as a low-risk type order or a high-risk type order when the real-time fraud risk degree does not exceed a first preset threshold or exceeds a second preset threshold, the second preset threshold being greater than the first preset threshold; a second order confirmation module configured to confirm the payment order as a high-risk type order or a low-risk type order by using the third-party risk detection model when the payment order is not confirmed as a low-risk type order or a high-risk type order; an order interception module configured to suspend a transaction process for the high-risk type order, verify a real identity of the user, and continue the transaction process after the verification is passed.

9. A computer device comprising a central processing unit and a memory, characterized in that The central processor is configured to call and run a computer program stored in the memory to perform the steps of the method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer program is stored in the form of computer readable instructions and is implemented according to the method of any one of claims 1 to 7. When the computer program is called and run by a computer, the steps included in the corresponding method are performed.

Images