Payment transaction request processing method and device and storage medium

Through multi-dimensional data feature extraction and risk identification models, the problem of insufficient risk identification accuracy in payment transactions is solved, and accurate identification and dynamic prevention and control of abnormal transactions are achieved.

CN120672345APending Publication Date: 2025-09-19INDUSTRIAL AND COMMERCIAL BANK OF CHINA
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202511112356.9
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2025-08-08
Publication Date
2025-09-19

AI Technical Summary

Technical Problem

The accuracy of risk identification in existing payment transactions is low, especially the identification of abnormal transactions caused by accidental touch operations and noise. Existing solutions rely on single or a few dimensions of information, resulting in insufficient comprehensiveness and accuracy.

Method used

By obtaining device fingerprints, behavior sequences, user portraits, environmental information and transaction information, cross-dimensional feature extraction and vectorization processing are performed, risk identification models are used to predict risk probability values, and risk assessment is performed by combining multiple sub-models and aggregation factors. Control instructions are generated or transactions are allowed under triggering conditions.

Benefits of technology

It improves the accuracy of risk prevention and control in payment transactions, dynamically captures multi-dimensional behavioral patterns, reduces misjudgments, and enhances the ability to identify abnormal transactions.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN120672345A_ABST
    Figure CN120672345A_ABST
Patent Text Reader

Abstract

The invention discloses a payment transaction request processing method and device and a storage medium. Relates to the field of artificial intelligence, and the method comprises the steps that under the condition that authorization of a target user is obtained, original data involved in a target payment transaction request triggered by the target user is obtained, and the original data at least comprises a device fingerprint, a behavior sequence, a user portrait of the target user, environment information and transaction information; performing feature extraction according to the original data, and determining a target feature corresponding to the target user; the target features are input into a risk identification model, a risk probability value corresponding to the target features is predicted through the risk identification model, and the risk probability value is used for representing the abnormal risk of the target payment transaction related to the target payment transaction request; and processing the target payment transaction request according to the risk probability value. According to the invention, the problem of low risk prevention and control accuracy of payment transaction in the prior art is solved.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present application relates to the field of artificial intelligence, and more specifically, to a method, device, and storage medium for processing payment transaction requests. Background Art

[0002] With the popularization of digital payments, the processing of payment transaction requests has become increasingly important. It is not only related to the smooth progress of financial transactions, but also a key link in protecting the safety of users' property. Analyzing and capturing the risks in the payment transaction process and quickly identifying potential abnormal behaviors in massive transactions are crucial to the safety of users' funds.

[0003] Existing technologies for identifying risks in payment transactions mostly rely on static rules and thresholds. These rules rely on manual adjustment of rule thresholds, resulting in low accuracy for abnormal transactions (e.g., accidental touches caused by unlocking the phone in a pocket, screen malfunction, or voice assistant misunderstandings due to noise). Furthermore, existing payment risk control solutions often only consider a single or limited set of information when processing user transaction requests, such as transaction amount, transaction frequency, or IP address, resulting in low comprehensiveness and accuracy.

[0004] Currently, no effective solution has been proposed to address the problem of low accuracy in risk prevention and control of payment transactions in related technologies. Summary of the Invention

[0005] The main purpose of this application is to provide a method, device and storage medium for processing payment transaction requests to solve the problem of low accuracy in risk prevention and control of payment transactions in related technologies.

[0006] To achieve the above-mentioned objectives, according to one aspect of the present application, a method for processing a payment transaction request is provided. The method comprises: obtaining raw data related to a target payment transaction request triggered by a target user, with authorization from the target user, wherein the raw data includes at least a device fingerprint, a behavior sequence, a user profile of the target user, environmental information, and transaction information; performing feature extraction based on the raw data to determine a target feature corresponding to the target user; inputting the target feature into a risk identification model to predict a risk probability value corresponding to the target feature using the risk identification model, wherein the risk probability value is used to characterize the abnormal risk of the target payment transaction involved in the target payment transaction request; and processing the target payment transaction request based on the risk probability value.

[0007] Furthermore, feature extraction is performed based on the original data to determine the target features corresponding to the target users, including: using a sliding window to extract time series features in the original data; performing cross-dimensional analysis on the device fingerprint, behavior sequence, user portrait, environmental information and transaction information in the original data to obtain cross-dimensional composite features; determining discrete data in the original data, and vectorizing the discrete data to obtain text vectorized features; determining the target features based on the time series features, cross-dimensional composite features and text vectorized features.

[0008] Furthermore, the target features include at least time series features and non-time series features, and the target features are input into the risk identification model to use the risk identification model to predict the risk probability value corresponding to the target features, including: predicting the first risk probability data corresponding to the target features through the rule engine sub-model in the risk identification model; predicting the second risk probability data corresponding to the non-time series features through the preset machine learning sub-model in the risk identification model; predicting the third risk probability data corresponding to the time series features through the time series prediction sub-model in the risk identification model; and determining the risk probability value based on the first risk probability data, the second risk probability data and the third risk probability data.

[0009] Furthermore, determining the risk probability value based on the first risk probability data, the second risk probability data and the third risk probability data includes: obtaining preset evaluation indicators of the risk identification model, determining multiple aggregation factors corresponding to the first risk probability data, the second risk probability data and the third risk probability data based on the preset evaluation indicators; and aggregating the first risk probability data, the second risk probability data and the third risk probability data based on the multiple aggregation factors to obtain the risk probability value.

[0010] Furthermore, the first risk probability data, the second risk probability data and the third risk probability data are aggregated according to multiple aggregation factors to obtain a risk probability value, which includes: weighted summing the first risk probability data, the second risk probability data and the third risk probability data according to multiple aggregation factors to obtain a preliminary aggregation result; receiving preset decision parameters, and normalizing the preliminary aggregation result according to the predicted decision parameters to obtain a risk probability value.

[0011] Furthermore, processing the target payment transaction request based on the risk probability value includes: determining the risk interval corresponding to the risk probability value; determining the trigger condition corresponding to the risk interval based on the risk interval; matching the environmental information, transaction information and risk probability value in the trigger condition; if the matching result meets the trigger condition, generating a control instruction and using the control instruction to block the target payment transaction request; if the matching result does not meet the trigger condition, the target payment transaction request will be allowed to be executed.

[0012] Furthermore, after sending the control instruction to the payment gateway of the target user, the method also includes: receiving an additional verification request initiated by the target user; initiating additional verification of the target user based on the additional verification request; if the result of the additional verification is successful, re-determining the control instruction, and updating the risk identification model based on the result of the additional verification.

[0013] To achieve the above-mentioned purpose, according to another aspect of the present application, a device for processing a payment transaction request is provided. The device comprises: a data acquisition unit, configured to acquire, upon authorization by the target user, raw data related to a target payment transaction request triggered by the target user, wherein the raw data includes at least a device fingerprint, a behavior sequence, a user profile of the target user, environmental information, and transaction information; a feature extraction unit, configured to perform feature extraction based on the raw data to determine a target feature corresponding to the target user; a risk identification unit, configured to input the target feature into a risk identification model to predict a risk probability value corresponding to the target feature using the risk identification model, wherein the risk probability value is used to characterize the abnormal risk of the target payment transaction involved in the target payment transaction request; and a risk processing unit, configured to process the target payment transaction request based on the risk probability value.

[0014] Furthermore, the feature extraction unit includes: a first feature extraction module, which is used to extract time series features in the original data using a sliding window; a second feature extraction module, which is used to perform cross-dimensional analysis on the device fingerprint, behavior sequence, user portrait, environmental information and transaction information in the original data to obtain cross-dimensional composite features; a third feature extraction module, which is used to determine discrete data in the original data and vectorize the discrete data to obtain text vectorized features; a feature synthesis module, which is used to determine target features based on time series features, cross-dimensional composite features and text vectorized features.

[0015] Furthermore, the target features include at least time series features and non-time series features, and the risk identification unit includes: a first risk identification module, used to predict first risk probability data corresponding to the target features through a rule engine sub-model in the risk identification model; a second risk identification module, used to predict second risk probability data corresponding to the non-time series features through a preset machine learning sub-model in the risk identification model; a third risk identification module, used to predict third risk probability data corresponding to the time series features through a time series prediction sub-model in the risk identification model; and a risk data synthesis module, used to determine the risk probability value based on the first risk probability data, the second risk probability data and the third risk probability data.

[0016] Furthermore, the risk data synthesis module includes: a factor acquisition submodule, which is used to obtain preset evaluation indicators of the risk identification model, and determine multiple aggregation factors corresponding to the first risk probability data, the second risk probability data and the third risk probability data based on the preset evaluation indicators; a data aggregation submodule, which is used to aggregate the first risk probability data, the second risk probability data and the third risk probability data based on multiple aggregation factors to obtain a risk probability value.

[0017] Furthermore, the data aggregation submodule includes: a weighted summation component, which is used to perform weighted summation on the first risk probability data, the second risk probability data and the third risk probability data based on multiple aggregation factors to obtain a preliminary aggregation result; a normalization component, which is used to receive preset decision parameters and normalize the preliminary aggregation results based on the predicted decision parameters to obtain a risk probability value.

[0018] Furthermore, the risk processing unit includes: an interval determination module, which is used to determine the risk interval corresponding to the risk probability value; a condition determination module, which is used to determine the trigger condition corresponding to the risk interval based on the risk interval; a matching judgment module, which is used to match the environmental information, transaction information and risk probability value in the trigger condition. If the matching result meets the trigger condition, a control instruction is generated and the target payment transaction request is blocked using the control instruction. If the matching result does not meet the trigger condition, the target payment transaction request will be allowed to be executed.

[0019] Furthermore, the risk processing unit also includes: a request receiving module, which is used to receive an additional verification request initiated by the target user after sending a control instruction to the payment gateway of the target user; an additional verification module, which is used to start additional verification of the target user based on the additional verification request; a control modification module, which is used to re-determine the control instruction if the result of the additional verification is successful, and update the risk identification model based on the result of the additional verification.

[0020] According to another aspect of the present application, a computer-readable storage medium is provided, wherein the computer-readable storage medium includes a stored program, wherein when the program is executed, the device where the computer-readable storage medium is located is controlled to execute any method for processing a payment transaction request.

[0021] According to another aspect of the present application, an electronic device 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, and the one or more programs include a processing method for executing any one of the payment transaction requests.

[0022] According to another aspect of the present application, a computer program product is provided, comprising computer instructions, which, when executed by a processor, implement the steps of any one of the above-mentioned methods for processing a payment transaction request.

[0023] In an embodiment of the present application, by obtaining the authorization of the target user, obtaining the original data involved in the target payment transaction request triggered by the target user, wherein the original data includes at least the device fingerprint, behavior sequence, user portrait of the target user, environmental information and transaction information; performing feature extraction based on the original data to determine the target features corresponding to the target user; inputting the target features into the risk identification model to use the risk identification model to predict the risk probability value corresponding to the target features, wherein the risk probability value is used to characterize the abnormal risk of the target payment transaction involved in the target payment transaction request; processing the target payment transaction request based on the risk probability value, thereby solving the technical problem of low accuracy in risk prevention and control of payment transactions in the prior art.

[0024] By collecting multi-dimensional data such as device fingerprints, behavior sequences, user portraits, environmental information, and transaction information, comprehensive background information is provided for the target payment transaction request, avoiding the feature loss of existing technologies that rely on a single dimension for risk judgment. In addition, this application captures more complex behavior patterns in multi-dimensional raw data by establishing a risk identification model, thus achieving dynamic prediction of risks. The risk identification model is easy to continuously optimize model parameters based on data, thereby improving the accuracy of risk prevention and control of payment transactions. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] The accompanying drawings, which constitute part of this application, are intended to provide a further understanding of this application. The exemplary embodiments and descriptions of this application are intended to explain this application and do not constitute an improper limitation on this application. In the accompanying drawings:

[0026] Figure 1 A hardware structure block diagram of a computer terminal for implementing a method for processing a payment transaction request is shown;

[0027] Figure 2 is a flowchart of a method for processing a payment transaction request provided in an embodiment of the present application;

[0028] Figure 3 is a schematic diagram of a payment transaction request processing device provided in accordance with an embodiment of the present application;

[0029] Figure 4 This is a structural block diagram of an electronic device according to an embodiment of the present application. DETAILED DESCRIPTION

[0030] In order to enable those skilled in the art to better understand the present invention, the following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments in the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts should fall within the scope of protection of this application.

[0031] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequential order. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in a sequence other than those illustrated or described herein. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device comprising a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0032] First, some nouns or terms that appear in the description of the embodiments of the present application are subject to the following interpretations:

[0033] It should be noted that the collected information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data for display, data for analysis, etc.) involved in this application are information and data authorized by the user or fully authorized by all parties, and the collection, storage, use, processing, transmission, provision, disclosure and application of the relevant data comply with relevant laws, regulations and standards, take necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation portals for users to choose to authorize or refuse. For example, an interface is set up between this system and relevant users or institutions to provide users with corresponding operation portals for users to choose to agree or refuse the automated decision probability value; if the user chooses to refuse, the expert decision process will be entered.

[0034] Example 1

[0035] According to an embodiment of the present application, an embodiment of a method for processing a payment transaction request is also provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0036] The method embodiment provided in the first embodiment of the present application can be executed in a mobile terminal, a computer terminal or a similar computing device. Figure 1 The hardware structure block diagram of a computer terminal (or mobile device) for implementing a method for processing a payment transaction request is shown. Figure 1 As shown, the computer terminal 10 (or mobile device) may include one or more (illustrated as 102a, 102b, ..., 102n in the figure) processors 102 (the processor 102 may include but is not limited to a processing device such as a microprocessor MCU or a programmable logic device FPGA), a memory 104 for storing data, and a transmission device 106 for communication functions. In addition, it may also include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of the BUS bus), a network interface, a power supply and / or a camera. It will be understood by those skilled in the art that Figure 1 The structure shown is only for illustration and does not limit the structure of the above electronic device. Figure 1 More or fewer components than shown, or with Figure 1 Different configurations shown.

[0037] It should be noted that the one or more processors 102 and / or other data processing circuits described above may generally be referred to herein as "data processing circuitry". The data processing circuitry may be embodied in whole or in part as software, hardware, firmware, or any other combination thereof. In addition, the data processing circuitry may be a single independent processing module, or may be incorporated in whole or in part into any of the other components of the computer terminal 10 (or mobile device). As described in the embodiments of the present application, the data processing circuitry serves as a processor control (e.g., selection of a variable resistor terminal path connected to an interface).

[0038] Memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the method for processing payment transaction requests in the embodiments of the present application. Processor 102 executes the software programs and modules stored in memory 104 to perform various functional applications and data processing, thereby implementing the aforementioned method for processing payment transaction requests. Memory 104 may include high-speed random access memory (RAM) and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some examples, memory 104 may further include memory remotely located relative to processor 102, and such remote memory may be connected to computer terminal 10 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0039] The transmission device 106 is configured to receive or transmit data via a network. A specific example of the aforementioned network may include a wireless network provided by the communications provider of the computer terminal 10. In one embodiment, the transmission device 106 includes a network interface controller (NIC), which can be connected to other network devices via a base station to enable communication with the Internet. In another embodiment, the transmission device 106 may be a radio frequency (RF) module, which is configured to communicate with the Internet wirelessly.

[0040] The display may be, for example, a touch screen liquid crystal display (LCD) that enables a user to interact with a user interface of the computer terminal 10 (or mobile device).

[0041] Under the above operating environment, this application provides Figure 2 The payment transaction request processing method shown. Figure 2 This is a flowchart of a method for processing a payment transaction request according to Example 1 of the present application.

[0042] Step S201, when the target user is authorized, obtain the original data involved in the target payment transaction request triggered by the target user, wherein the original data at least includes the device fingerprint, behavior sequence, user profile of the target user, environmental information and transaction information.

[0043] Optionally, after the target payment transaction request is triggered, the original data can be captured in real time through an asynchronous message queue. The data in the original data involves multiple different data dimensions, and the data of the corresponding data dimensions can be collected through different channels.

[0044] For example, the device fingerprint can be obtained by collecting terminal parameters through the SDK. The device fingerprint may include the device ID, device IP address, device identification code, and screen resolution; the behavior sequence can be obtained by embedding points through the front-end JS. The behavior sequence may include operation speed data (for example, the frequency of mouse clicks), mouse movement trajectory (for example, the coordinate change vector of mouse movement), and page dwell time; the transaction information of the target user can be obtained by passing it through the payment gateway. The transaction information may include transaction amount data, payee ID, geographic location information, and timestamp data; environmental information may be obtained by calling the risk control API. The environmental information may include current IP threat intelligence data and proxy server identification; the user portrait of the target user may be obtained by querying the database. The user portrait may include transaction frequency, user device usage records, average monthly transaction amount, and number of login attempts.

[0045] Step S202: extract features based on the original data to determine target features corresponding to the target user.

[0046] Optionally, feature engineering can be used to extract features from the original data. For example, discrete features in the original data can be one-hot encoded, text features in the original data can be processed by removing stop words and word embedding, and continuous numerical features in the original data can be normalized. All processed features can be concatenated to obtain the target features.

[0047] In step S203, the target feature is input into the risk identification model to predict a risk probability value corresponding to the target feature using the risk identification model, wherein the risk probability value is used to characterize the abnormal risk of the target payment transaction involved in the target payment transaction request.

[0048] Optionally, the risk identification model can be trained using a random forest algorithm, a gradient boosting tree algorithm, or a long short-term memory neural network model. The input data of the risk identification model is the target feature, and the output data is a risk probability value corresponding to the target feature. The risk probability value is used to quantify the abnormal risk level of the target payment transaction. It is derived by analyzing the target feature using the risk identification model and represents the probability that the target payment transaction involved in the target payment transaction request is an abnormal transaction, given the payment transaction context of the original data.

[0049] Step S204: Process the target payment transaction request according to the risk probability value.

[0050] Optionally, the target payment transaction request may be processed in a manner corresponding to the risk probability value by determining the risk threshold value according to the size of the risk probability value.

[0051] For example, the risk threshold can be set to 0.8. When the risk probability value is 0.7, which is lower than the risk threshold, the target payment transaction request may be processed by allowing the transaction; when the risk probability value is 0.85, which is higher than the risk threshold, the target payment transaction request may be blocked to temporarily stop the progress of the target payment transaction.

[0052] To sum up, by collecting multi-dimensional data of device fingerprints, behavior sequences, user portraits, environmental information and transaction information, comprehensive background information is provided for the target payment transaction request, avoiding the feature loss of the existing technology that relies on only a single dimension for risk judgment. In addition, this application captures more complex behavior patterns in multi-dimensional raw data by establishing a risk identification model, realizes dynamic prediction of risks, and the risk identification model is easy to continuously optimize model parameters according to data, thereby improving the accuracy of risk prevention and control of payment transactions.

[0053] In order to improve the accuracy of risk identification, optionally, feature extraction is performed based on the original data to determine the target features corresponding to the target user, including: using a sliding window to extract time series features in the original data; performing cross-dimensional analysis on the device fingerprint, behavior sequence, user portrait, environmental information and transaction information in the original data to obtain cross-dimensional composite features; determining discrete data in the original data, and vectorizing the discrete data to obtain text vectorized features; determining the target features based on the time series features, cross-dimensional composite features and text vectorized features.

[0054] Optionally, time series data can be filtered from the raw data (for example, all operation speed data, page dwell time, mouse movement trajectory, transaction amount, and transaction frequency within a preset time period prior to the target payment transaction request) and extracted using a sliding window to obtain time series features. Cross-dimensional composite features are derived by correlating data from different dimensions. Cross-dimensional composite features represent deeper information and can help uncover complex relationships and potential risks that are difficult to detect using single-dimensional analysis. Composite features can be generated by pairwise correlation calculations across five different dimensions: device fingerprints, behavior sequences, user profiles, environmental information, and transaction information. For example, by calculating the ratio of the transaction amount in transaction information to the average monthly transaction amount in the user profile, composite features can reveal complex risk patterns and help improve the recognition accuracy of risk identification models. Pre-trained word embedding models can be used to convert discrete data (for example, payee ID, device IP address, etc.) into vectors to obtain text vectorized features. By concatenating time series features, cross-dimensional composite features, and text vectorized features, the target features can be obtained.

[0055] For example, suppose a target payment transaction request is received from user A, the transaction amount is x, the payee is a merchant that has never traded with the user, and the transaction occurs at 1 a.m. The sliding window is used to extract features from the time series data of user A before the transaction, such as the number of login attempts in the user profile within 15 minutes, the length of time the user stays on the page in the behavior sequence, etc. At the same time, the device identification code, device IP, screen resolution, etc. are obtained. The ratio of the transaction amount data of user A's target payment transaction request to the average monthly transaction amount is obtained, and the number of times the device IP in the device fingerprint appears in the user's device usage record in the user profile is obtained. The ratio and the number of times are used as cross-dimensional composite features, and discrete data such as the payee's IP and geographic location information are obtained and vectorized to obtain text vectorized features. The time series features, cross-dimensional composite features, and text vectorized features are spliced ​​together to obtain the target features.

[0056] In summary, the above feature extraction obtains comprehensive and accurate target features by extracting time series features, cross-dimensional composite features, and text vectorization features, providing high-quality input for the risk identification model, thereby improving the accuracy of risk identification.

[0057] In order to improve the accuracy of risk identification, optionally, the target features include at least time series features and non-time series features, and the target features are input into the risk identification model to use the risk identification model to predict the risk probability value corresponding to the target features, including: predicting the first risk probability data corresponding to the target features through the rule engine sub-model in the risk identification model; predicting the second risk probability data corresponding to the non-time series features through the preset machine learning sub-model in the risk identification model; predicting the third risk probability data corresponding to the time series features through the time series prediction sub-model in the risk identification model; and determining the risk probability value based on the first risk probability data, the second risk probability data and the third risk probability data.

[0058] Optionally, the rule engine sub-model can include multiple predefined high-risk patterns and first risk probability data corresponding to each predefined high-risk pattern. Based on this, the rule engine sub-model can quickly assess whether a transaction falls within a predefined high-risk pattern, such as whether the transaction amount exceeds five times the monthly average transaction amount or whether the payee ID is on a preset list. The rule engine sub-model can instantly provide the first risk probability data to quickly filter out obvious abnormal transactions. The pre-set machine learning sub-model uses a machine learning algorithm to learn patterns in the training dataset and analyze non-time series features to predict second risk probability data. This pre-set machine learning sub-model can capture nonlinear relationships that are difficult for the rule engine sub-model to identify. The time series prediction sub-model is used to predict third risk probability data based on time series features, capturing the continuity and temporal trends of operational behavior. The risk probability value is determined based on the first, second, and third risk probability data. The final risk probability value can be generated by taking a weighted average of the first, second, and third risk probability data.

[0059] In summary, the risk identification model composed of multiple sub-models can predict risks from multiple angles, obtain risk probability values ​​from comprehensive risk probability data from multiple angles, and improve the accuracy of risk identification.

[0060] In order to improve the accuracy of risk identification, optionally, determining the risk probability value based on the first risk probability data, the second risk probability data and the third risk probability data includes: obtaining preset evaluation indicators of the risk identification model, determining multiple aggregation factors corresponding to the first risk probability data, the second risk probability data and the third risk probability data based on the preset evaluation indicators; and aggregating the first risk probability data, the second risk probability data and the third risk probability data based on the multiple aggregation factors to obtain the risk probability value.

[0061] Optionally, the preset evaluation indicators may be AUC indicators, accuracy rates, recall rates, etc. Determining multiple aggregation factors based on the preset evaluation indicators may be determining the aggregation factors of the risk probability data corresponding to each sub-model in the risk identification model based on the preset evaluation indicators of the sub-model. For example, determining the first aggregation factor corresponding to the first risk probability data based on the preset evaluation indicators of the rule engine sub-model, determining the second aggregation factor corresponding to the second risk probability data based on the preset evaluation indicators of the preset machine learning sub-model, and determining the third aggregation factor corresponding to the third risk probability data based on the preset evaluation indicators of the time series prediction sub-model. Aggregating the first risk probability data, the second risk probability data, and the third risk probability data based on the multiple aggregation factors may be performed by taking the aggregation factors as weights and performing weighted summation on the first risk probability data, the second risk probability data, and the third risk probability data to obtain a risk probability value.

[0062] For example, for a certain target payment transaction request, the first risk probability data of the risk identification model is 0.6, the second risk probability data is 0.45, and the third risk probability data is 0.75. The AUC index of each sub-model in the risk identification model for the test data set is obtained. The AUC of the rule engine sub-model is 0.81, the AUC of the preset machine learning sub-model is 0.9, and the AUC of the time series prediction sub-model is 0.87. The AUC value can be mapped to the aggregation factor through linear regression (1 / 3 can be used as the linear coefficient) and normalization, and the first aggregation factor is 0.314, the second aggregation factor is 0.349, and the third aggregation factor is 0.337. By calculating 0.6*0.314+0.45*0.349+0.75*0.337, the risk probability value can be obtained as 0.608.

[0063] In summary, by determining the aggregation factor through preset evaluation indicators, different risk probability data can be aggregated based on multiple aggregation factors. The more accurate the sub-model prediction of the risk probability data will be, the greater the weight will be, and the risk probability value will be obtained, which improves the accuracy of risk identification.

[0064] In order to improve the accuracy of risk identification, optionally, the first risk probability data, the second risk probability data and the third risk probability data are aggregated according to multiple aggregation factors to obtain a risk probability value, which includes: weighted summing the first risk probability data, the second risk probability data and the third risk probability data according to multiple aggregation factors to obtain a preliminary aggregation result; receiving preset decision parameters, and normalizing the preliminary aggregation result according to the predicted decision parameters to obtain a risk probability value.

[0065] For example, the aggregation factor can be used as the weight of the corresponding risk probability data, the prediction results of each sub-model (i.e., the risk probability data) can be multiplied by the corresponding aggregation factor, and the products can be summed to obtain a preliminary aggregation result. The preset decision parameters can include a preset risk score, a median decision threshold, a slope coefficient, and a natural constant e. In this case, the normalization process can be to subtract the preset risk score from the preliminary aggregation result to obtain a first difference, obtain the inverse of the product of the slope coefficient and the first difference to obtain a first exponent, use the natural constant e as the base and the first exponent as the exponent to obtain a first power value, obtain the reciprocal of the sum of the first power value and 1, and use the reciprocal as the risk probability value.

[0066] In summary, the preliminary aggregation results were obtained by weighted summing multiple risk probability data based on multiple aggregation factors, and the risk probability value was obtained by normalizing the preliminary aggregation results, which improved the accuracy of risk identification.

[0067] In order to improve the accuracy of risk processing, optionally, processing the target payment transaction request based on the risk probability value includes: determining the risk interval corresponding to the risk probability value; determining the trigger condition corresponding to the risk interval based on the risk interval; matching the environmental information, transaction information and risk probability value in the trigger condition; if the matching result meets the trigger condition, generating a control instruction and using the control instruction to block the target payment transaction request; if the matching result does not meet the trigger condition, the target payment transaction request will be allowed to be executed.

[0068] Optionally, the trigger conditions and control instructions corresponding to the risk intervals can be determined based on a preset control instruction table. For example, the preset probability and interval relationship table can be as shown in the following table:

[0069]

[0070] After determining the risk interval corresponding to the risk probability value, obtain the trigger condition corresponding to the risk interval, and verify whether the environmental information, transaction information and risk probability value meet the trigger condition. If so, send the control instruction to the payment gateway of the target user.

[0071] In summary, by using the risk range of the risk probability value to match the trigger conditions and then generate control instructions, secondary verification is achieved, which avoids misjudgment of normal transactions and improves the accuracy of risk management.

[0072] In order to improve the accuracy of risk handling, optionally, after sending the control instruction to the payment gateway of the target user, the method also includes: receiving an additional verification request initiated by the target user; initiating additional verification of the target user based on the additional verification request; if the result of the additional verification is successful, re-determining the control instruction, and updating the risk identification model based on the result of the additional verification.

[0073] For example, after the payment gateway of the target user receives the control instruction, it can also choose whether to initiate a challenge verification, that is, an additional verification request. The additional verification can be the biometric identification of the mobile SDK (for example, liveness detection), or it can be the comparison of behavioral biometrics on the server side (for example, the pressure of the finger on the screen / the sliding trajectory of the finger on the screen). The result of the additional verification can be verification success, verification failure, or verification timeout. When the verification is successful, the control instruction can be modified to allow execution, and the log generated during the additional verification process can be saved. The data stream in the log is used as input data, and any value with a risk probability lower than 0.5 is used as output data to build a model correction data set, and the model correction data set is used to iteratively train the risk identification model.

[0074] The accuracy of risk prevention and control is improved through additional verification. At the same time, using the results of additional verification to update the risk identification model is conducive to improving the accuracy of the risk identification model, thereby improving the accuracy of risk treatment.

[0075] It should be noted that the steps shown in the flowcharts of the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and that, although a logical order is shown in the flowcharts, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0076] Example 2

[0077] The present application also provides a payment transaction request processing device. It should be noted that the payment transaction request processing device of the present application can be used to execute the payment transaction request processing method provided in the present application. The following describes the payment transaction request processing device provided in the present application.

[0078] According to an embodiment of the present application, a device for implementing the above-mentioned method for processing payment transaction requests is also provided. Figure 3 As shown, the device includes:

[0079] The data acquisition unit 301 is used to obtain the original data involved in the target payment transaction request triggered by the target user with the authorization of the target user, wherein the original data includes at least device fingerprint, behavior sequence, user profile of the target user, environmental information and transaction information.

[0080] The feature extraction unit 302 is used to extract features based on the original data and determine target features corresponding to the target user.

[0081] The risk identification unit 303 is configured to input the target feature into a risk identification model to predict a risk probability value corresponding to the target feature using the risk identification model, wherein the risk probability value is used to characterize the abnormal risk of the target payment transaction involved in the target payment transaction request.

[0082] The risk processing unit 304 is configured to process the target payment transaction request according to the risk probability value.

[0083] The payment transaction request processing device provided in the embodiment of the present application obtains, through a data acquisition unit 301, the raw data involved in the target payment transaction request triggered by the target user, with the authorization of the target user. The raw data includes at least a device fingerprint, a behavior sequence, a user profile of the target user, environmental information, and transaction information. The feature extraction unit 302 extracts features based on the raw data to determine the target features corresponding to the target user. The risk identification unit 303 inputs the target features into a risk identification model to predict a risk probability value corresponding to the target features using the risk identification model. The risk probability value is used to characterize the abnormal risk of the target payment transaction involved in the target payment transaction request. The risk processing unit 304 processes the target payment transaction request based on the risk probability value, thereby resolving the problem of low risk prevention and control accuracy of payment transactions in related technologies. This improves the accuracy of risk prevention and control of payment transactions.

[0084] Optionally, in the payment transaction request processing device provided in the embodiment of the present application, the feature extraction unit includes: a first feature extraction module, used to use a sliding window to extract time series features in the original data; a second feature extraction module, used to use the device fingerprint, behavior sequence, user portrait, environmental information and transaction information in the original data to perform cross-dimensional analysis to obtain cross-dimensional composite features; a third feature extraction module, used to determine discrete data in the original data and vectorize the discrete data to obtain text vectorized features; a feature synthesis module, used to determine the target features based on time series features, cross-dimensional composite features and text vectorized features.

[0085] Optionally, in the payment transaction request processing device provided in the embodiment of the present application, the target feature includes at least a time series feature and a non-time series feature, and the risk identification unit includes: a first risk identification module, used to predict the first risk probability data corresponding to the target feature through the rule engine sub-model in the risk identification model; a second risk identification module, used to predict the second risk probability data corresponding to the non-time series feature through the preset machine learning sub-model in the risk identification model; a third risk identification module, used to predict the third risk probability data corresponding to the time series feature through the time series prediction sub-model in the risk identification model; and a risk data synthesis module, used to determine the risk probability value based on the first risk probability data, the second risk probability data and the third risk probability data.

[0086] Optionally, in the payment transaction request processing device provided in the embodiment of the present application, the risk data synthesis module includes: a factor acquisition sub-module, used to obtain preset evaluation indicators of the risk identification model, and determine multiple aggregation factors corresponding to the first risk probability data, the second risk probability data and the third risk probability data based on the preset evaluation indicators; a data aggregation sub-module, used to aggregate the first risk probability data, the second risk probability data and the third risk probability data based on multiple aggregation factors to obtain a risk probability value.

[0087] Optionally, in the payment transaction request processing device provided in the embodiment of the present application, the data aggregation submodule includes: a weighted summation component, which is used to perform weighted summation on the first risk probability data, the second risk probability data and the third risk probability data based on multiple aggregation factors to obtain a preliminary aggregation result; a normalization component, which is used to receive preset decision parameters and normalize the preliminary aggregation result based on the predicted decision parameters to obtain a risk probability value.

[0088] Optionally, in the payment transaction request processing device provided in the embodiment of the present application, the risk processing unit includes: an interval determination module, used to determine the risk interval corresponding to the risk probability value; a condition determination module, used to determine the trigger condition corresponding to the risk interval based on the risk interval; a matching judgment module, used to match the environmental information, transaction information and risk probability value in the trigger condition; if the matching result meets the trigger condition, a control instruction is generated and the target payment transaction request is blocked using the control instruction; if the matching result does not meet the trigger condition, the target payment transaction request is allowed to be executed.

[0089] Optionally, in the payment transaction request processing device provided in the embodiment of the present application, the risk processing unit also includes: a request receiving module, which is used to receive an additional verification request initiated by the target user after sending a control instruction to the payment gateway of the target user; an additional verification module, which is used to start additional verification of the target user based on the additional verification request; and a control modification module, which is used to re-determine the control instruction if the result of the additional verification is successful, and update the risk identification model based on the result of the additional verification.

[0090] It should be noted here that the above-mentioned data acquisition unit 301, feature extraction unit 302, risk identification unit 303 and risk processing unit 304 correspond to steps S201 to S204 in Example 1. The instances and application scenarios implemented by the units and corresponding steps are the same, but are not limited to the contents disclosed in the above-mentioned Example 1.

[0091] It should be noted that the above-mentioned modules or units can be hardware components or software components stored in a memory (e.g., memory 104) and processed by one or more processors (e.g., processors 102a, 102b, ..., 102n). The above-mentioned modules can also be run as part of the device in the computer terminal 10 provided in Example 1.

[0092] Example 3

[0093] An embodiment of the present application may provide an electronic device, Figure 4 This is a structural block diagram of an electronic device according to an embodiment of the present application. Figure 4 As shown, the electronic device may include: one or more ( Figure 4 Only one is shown) processor 1002, memory 1004, storage controller, and peripheral interface, wherein the peripheral interface is connected to the radio frequency module, audio module and display.

[0094] Among them, the memory can be used to store software programs and modules, such as program instructions / modules corresponding to the methods and devices in the embodiments of the present application. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory, that is, implementing the above-mentioned method. The memory may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory may further include a memory remotely arranged relative to the processor, and these remote memories may be connected to the terminal via a network. Examples of the above-mentioned network include but are not limited to the Internet, an intranet, a local area network, a mobile communication network and a combination thereof.

[0095] The processor can call the information and application stored in the memory through the transmission device to perform the following steps: with the authorization of the target user, obtain the original data involved in the target payment transaction request triggered by the target user, wherein the original data includes at least the device fingerprint, behavior sequence, user portrait of the target user, environmental information and transaction information; perform feature extraction based on the original data to determine the target feature corresponding to the target user; input the target feature into the risk identification model to use the risk identification model to predict the risk probability value corresponding to the target feature, wherein the risk probability value is used to characterize the abnormal risk of the target payment transaction involved in the target payment transaction request; and process the target payment transaction request based on the risk probability value.

[0096] The processor can also call the information and applications stored in the memory through the transmission device to perform the following steps: use the sliding window to extract the time series features in the original data; perform cross-dimensional analysis on the device fingerprints, behavior sequences, user portraits, environmental information and transaction information in the original data to obtain cross-dimensional composite features; determine the discrete data in the original data, and vectorize the discrete data to obtain text vectorized features; determine the target features based on the time series features, cross-dimensional composite features and text vectorized features.

[0097] The processor can also call the information and application programs stored in the memory through the transmission device to perform the following steps: predict the first risk probability data corresponding to the target feature through the rule engine sub-model in the risk identification model; predict the second risk probability data corresponding to the non-time series feature through the preset machine learning sub-model in the risk identification model; predict the third risk probability data corresponding to the time series feature through the time series prediction sub-model in the risk identification model; determine the risk probability value based on the first risk probability data, the second risk probability data and the third risk probability data.

[0098] The processor can also call the information and application stored in the memory through the transmission device to perform the following steps: obtain the preset evaluation indicators of the risk identification model, determine multiple aggregation factors corresponding to the first risk probability data, the second risk probability data and the third risk probability data based on the preset evaluation indicators; aggregate the first risk probability data, the second risk probability data and the third risk probability data based on multiple aggregation factors to obtain a risk probability value.

[0099] The processor can also call the information and application programs stored in the memory through the transmission device to perform the following steps: weighted summing the first risk probability data, the second risk probability data and the third risk probability data according to multiple aggregation factors to obtain a preliminary aggregation result; receiving preset decision parameters, and normalizing the preliminary aggregation results according to the predicted decision parameters to obtain a risk probability value.

[0100] The processor can also call the information and application stored in the memory through the transmission device to perform the following steps: determine the risk interval corresponding to the risk probability value; determine the trigger condition corresponding to the risk interval based on the risk interval; match the environmental information, transaction information and risk probability value in the trigger condition. If the matching result meets the trigger condition, a control instruction is generated and the control instruction is used to block the target payment transaction request. If the matching result does not meet the trigger condition, the target payment transaction request will be allowed to be executed.

[0101] The processor can also call the information and applications stored in the memory through the transmission device to perform the following steps: receiving an additional verification request initiated by the target user; starting additional verification of the target user based on the additional verification request; if the result of the additional verification is successful, re-determining the control instructions, and updating the risk identification model based on the result of the additional verification.

[0102] An embodiment of the present application provides a solution for processing payment transaction requests. The solution obtains the original data involved in a target payment transaction request triggered by a target user, with authorization from the target user, wherein the original data includes at least a device fingerprint, a behavior sequence, a user profile of the target user, environmental information, and transaction information; performs feature extraction based on the original data to determine a target feature corresponding to the target user; inputs the target feature into a risk identification model to use the risk identification model to predict a risk probability value corresponding to the target feature, wherein the risk probability value is used to characterize the abnormal risk of the target payment transaction involved in the target payment transaction request; and processes the target payment transaction request based on the risk probability value, thereby solving the technical problem of low accuracy in risk prevention and control of payment transactions in the prior art.

[0103] It can be understood by those skilled in the art that Figure 4 The structure shown is for illustration only, and the electronic device may also be a smart phone, a tablet computer, a PDA, a mobile Internet device (MID), a PAD or other terminal device. Figure 4 It does not limit the structure of the above electronic device. For example, the electronic device may also include Figure 4 More or fewer components (such as network interfaces, display devices, etc.) shown in, or with Figure 4 Different configurations shown.

[0104] A person skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be completed by instructing the hardware related to the terminal device through a program, and the program can be stored in a computer-readable storage medium, which may include: a flash drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, etc.

[0105] Example 4

[0106] The embodiment of the present application further provides a storage medium. Optionally, in this embodiment, the storage medium can be used to store the program code executed by the payment transaction request processing method provided in the first embodiment.

[0107] Optionally, in this embodiment, the storage medium may be located in any computer terminal in a computer terminal group in a computer network, or in any mobile terminal in a mobile terminal group.

[0108] Optionally, in this embodiment, the computer-readable storage medium is configured to store program code for executing the following steps: obtaining original data involved in the target payment transaction request triggered by the target user with authorization from the target user, wherein the original data includes at least device fingerprint, behavior sequence, user portrait of the target user, environmental information and transaction information; performing feature extraction based on the original data to determine the target features corresponding to the target user; inputting the target features into a risk identification model to predict the risk probability value corresponding to the target features using the risk identification model, wherein the risk probability value is used to characterize the abnormal risk of the target payment transaction involved in the target payment transaction request; and processing the target payment transaction request based on the risk probability value.

[0109] Optionally, in this embodiment, the computer-readable storage medium is further configured to store program code for executing the following steps: extracting time series features from the original data using a sliding window; performing cross-dimensional analysis on device fingerprints, behavior sequences, user portraits, environmental information, and transaction information in the original data to obtain cross-dimensional composite features; determining discrete data in the original data, and vectorizing the discrete data to obtain text vectorized features; determining target features based on time series features, cross-dimensional composite features, and text vectorized features.

[0110] Optionally, in this embodiment, the computer-readable storage medium is also configured to store program code for executing the following steps: predicting first risk probability data corresponding to the target feature through a rule engine sub-model in the risk identification model; predicting second risk probability data corresponding to the non-time series feature through a preset machine learning sub-model in the risk identification model; predicting third risk probability data corresponding to the time series feature through a time series prediction sub-model in the risk identification model; and determining a risk probability value based on the first risk probability data, the second risk probability data, and the third risk probability data.

[0111] Optionally, in this embodiment, the computer-readable storage medium is also configured to store program code for executing the following steps: obtaining preset evaluation indicators of the risk identification model, determining multiple aggregation factors corresponding to the first risk probability data, the second risk probability data, and the third risk probability data based on the preset evaluation indicators; aggregating the first risk probability data, the second risk probability data, and the third risk probability data based on the multiple aggregation factors to obtain a risk probability value.

[0112] Optionally, in this embodiment, the computer-readable storage medium is also configured to store program code for executing the following steps: weighted summing the first risk probability data, the second risk probability data, and the third risk probability data based on multiple aggregation factors to obtain a preliminary aggregation result; receiving preset decision parameters, and normalizing the preliminary aggregation result based on the predicted decision parameters to obtain a risk probability value.

[0113] Optionally, in this embodiment, the computer-readable storage medium is further configured to store program code for executing the following steps: determining a risk interval corresponding to a risk probability value; determining a trigger condition corresponding to the risk interval based on the risk interval; matching environmental information, transaction information, and risk probability value in the trigger condition; if the result of the match meets the trigger condition, generating a control instruction and using the control instruction to block the target payment transaction request; if the result of the match does not meet the trigger condition, allowing the target payment transaction request to be executed.

[0114] Optionally, in this embodiment, the computer-readable storage medium is also configured to store program code for executing the following steps: receiving an additional verification request initiated by the target user; initiating additional verification of the target user based on the additional verification request; if the result of the additional verification is successful, re-determining the management and control instructions, and updating the risk identification model based on the result of the additional verification.

[0115] The present application also provides a computer program product, which, when executed on a data processing device, is suitable for executing the program steps of the method for processing a payment transaction request.

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

[0117] In the above embodiments of the present application, the description of each embodiment has its own focus. For parts that are not described in detail in a certain embodiment, please refer to the relevant description of other embodiments.

[0118] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. Among them, the device embodiments described above are only schematic. For example, the division of the units is only a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of units or modules, which can be electrical or other forms.

[0119] The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0120] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0121] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions for enabling a computer device (which can be a personal computer, a server or a network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk or an optical disk.

[0122] The above is only a preferred embodiment of the present application. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present application. These improvements and modifications should also be regarded as the scope of protection of the present application.

Claims

1. A method for processing a payment transaction request, characterized in that: include: Upon obtaining authorization from the target user, obtaining raw data related to the target payment transaction request triggered by the target user, wherein the raw data includes at least a device fingerprint, a behavior sequence, a user profile of the target user, environmental information, and transaction information; Extracting features based on the original data to determine target features corresponding to the target user; Inputting the target feature into a risk identification model to predict a risk probability value corresponding to the target feature using the risk identification model, wherein the risk probability value is used to characterize the abnormal risk of the target payment transaction involved in the target payment transaction request; The target payment transaction request is processed according to the risk probability value.

2. The method according to claim 1, characterized in that Extracting features based on the original data to determine target features corresponding to the target user includes: Extracting time series features from the original data using a sliding window; Performing cross-dimensional analysis on the device fingerprint, the behavior sequence, the user portrait, the environmental information, and the transaction information in the original data to obtain cross-dimensional composite features; Determining discrete data in the original data, and performing vectorization processing on the discrete data to obtain text vectorization features; The target feature is determined based on the time series feature, the cross-dimensional composite feature, and the text vectorization feature.

3. The method according to claim 1, characterized in that The target features include at least time series features and non-time series features. Inputting the target features into the risk identification model to use the risk identification model to predict the risk probability value corresponding to the target features includes: Predicting first risk probability data corresponding to the target feature through a rule engine sub-model in the risk identification model; Predicting second risk probability data corresponding to the non-time series feature through a preset machine learning sub-model in the risk identification model; Predicting third risk probability data corresponding to the time series feature using the time series prediction sub-model in the risk identification model; The risk probability value is determined according to the first risk probability data, the second risk probability data, and the third risk probability data.

4. The method according to claim 3, characterized in that Determining the risk probability value according to the first risk probability data, the second risk probability data, and the third risk probability data includes: Obtaining a preset evaluation indicator of the risk identification model, and determining a plurality of aggregation factors corresponding to the first risk probability data, the second risk probability data, and the third risk probability data based on the preset evaluation indicator; The first risk probability data, the second risk probability data, and the third risk probability data are aggregated according to the multiple aggregation factors to obtain the risk probability value.

5. The method according to claim 4, characterized in that Aggregating the first risk probability data, the second risk probability data, and the third risk probability data according to the multiple aggregation factors to obtain the risk probability value includes: performing a weighted summation on the first risk probability data, the second risk probability data, and the third risk probability data according to the multiple aggregation factors to obtain a preliminary aggregation result; Receive preset decision parameters, and normalize the preliminary aggregation results according to the predicted decision parameters to obtain the risk probability value.

6. The method according to claim 1, characterized in that Processing the target payment transaction request according to the risk probability value includes: determining a risk interval corresponding to the risk probability value; determining a trigger condition corresponding to the risk interval according to the risk interval; The environmental information, the transaction information and the risk probability value are matched in the trigger condition. If the matching result meets the trigger condition, a control instruction is generated and the target payment transaction request is blocked using the control instruction. If the matching result does not meet the trigger condition, the target payment transaction request is allowed to be executed.

7. The method according to claim 6, characterized in that After sending the control instruction to the payment gateway of the target user, the method further includes: Receiving an additional verification request initiated by the target user; Initiating additional verification of the target user according to the additional verification request; If the result of the additional verification is success, the control instruction is re-determined, and the risk identification model is updated according to the result of the additional verification.

8. A payment transaction request processing device, characterized in that: include: a data acquisition unit, configured to acquire, upon authorization by a target user, raw data related to a target payment transaction request triggered by the target user, wherein the raw data includes at least a device fingerprint, a behavior sequence, a user profile of the target user, environmental information, and transaction information; A feature extraction unit, configured to extract features based on the original data and determine target features corresponding to the target user; a risk identification unit, configured to input the target feature into a risk identification model, and use the risk identification model to predict a risk probability value corresponding to the target feature, wherein the risk probability value is used to characterize an abnormal risk of a target payment transaction involved in the target payment transaction request; A risk processing unit is used to process the target payment transaction request according to the risk probability value.

9. A computer-readable storage medium, characterized in that The computer-readable storage medium includes a stored executable program, wherein when the executable program is run, the device where the computer-readable storage medium is located is controlled to execute the method for processing a payment transaction request according to any one of claims 1 to 7.

10. An electronic device, characterized in that: include: a memory storing an executable program; A processor, configured to run the program, wherein the program, when running, executes the method for processing a payment transaction request according to any one of claims 1 to 7.

11. A computer program product comprising computer instructions, characterized in that When the computer instructions are executed by a processor, the steps of the method for processing a payment transaction request according to any one of claims 1 to 7 are implemented.