Method for generating payment risk identification model, payment risk identification method and device

Abstract

The embodiment of the specification discloses a payment risk identification model generation method, comprising the following steps: acquiring a first training sample and setting a first label, wherein the first training sample is a payment event in a preset different payment scenario; setting a classifier for each payment scenario, training the classifier based on the first training sample and the first label; selecting at least one payment scenario, taking the training sample of the payment scenario as a second training sample; inputting the second training sample into the classifier of the payment scenario, taking the obtained prediction result as a second label; based on the second training sample and the second label, the other classifiers are integrated and trained; and the trained classifiers are integrated into the payment risk identification model. Accordingly, the specification also discloses a payment risk identification method and device.

Description

Technical Field

[0001] This invention relates to the field of artificial intelligence technology, and in particular to a method for generating a payment risk identification model, a payment risk identification method, and an apparatus. Background Technology

[0002] To ensure fund security, risk identification is often required during online payments, typically necessitating the development of different models and risk control measures for different scenarios. However, there are numerous payment scenarios involved, with specific transactions often corresponding to different scenarios, and the underlying event logic and data distribution vary significantly. Adopting a scenario-specific modeling approach for risk identification is extremely costly. Summary of the Invention

[0003] This specification describes one or more embodiments of a method for generating a payment risk identification model, a payment risk identification method and apparatus, which can be adapted to risk identification problems in different payment scenarios and achieve green risk control.

[0004] According to the first aspect, a method for generating a payment risk identification model is provided, including:

[0005] Obtain a first training sample and set a first label. The first training sample consists of payment events under different preset payment scenarios.

[0006] A classifier is set up for each payment scenario, and the classifier is trained based on the first training sample and the first label;

[0007] Select at least one payment scenario and use the training samples of that payment scenario as the second training samples; input the second training samples into the classifier of that payment scenario and use the obtained prediction results as the second label; perform ensemble training on other classifiers based on the second training samples and the second label;

[0008] The trained classifiers are integrated into the payment risk identification model.

[0009] As an optional implementation of the method described in the first aspect, training the classifier based on the first training sample and the first label specifically includes:

[0010] The first training sample is input into the feature extraction network to obtain the first sample features;

[0011] The first sample features are input into the classifier to obtain the first prediction result;

[0012] Based on the first prediction result and the first label, a first loss function is determined;

[0013] The classifier is updated based on the first loss function.

[0014] As an optional implementation of the method described in the first aspect, ensemble training of other classifiers is performed based on the second training samples and the second label, specifically including:

[0015] The second training sample is input into the feature extraction network to obtain the features of the second sample;

[0016] The second sample features are input into the other classifiers respectively to obtain the second prediction result;

[0017] Based on the second prediction results of the other classifiers, determine the ensemble prediction results of the other classifiers;

[0018] Based on the ensemble prediction results of the other classifiers and the second label, a second loss function is determined;

[0019] The other classifiers are updated based on the second loss function.

[0020] As an optional implementation of the method described in the first aspect, before integrating the classifier into the payment risk identification model, it further includes:

[0021] Obtain the third training sample in the target payment scenario;

[0022] In the payment scenarios, the payment scenario whose sample distribution is closest to the target payment scenario is selected;

[0023] The third training sample is input into the classifier for this payment scenario, and the resulting prediction is used as the third label.

[0024] Based on the third training sample and the third label, the classifiers for the different payment scenarios are integrated and trained.

[0025] Specifically, based on the third training samples and the third label, the classifiers for the different payment scenarios are integrated and trained, including:

[0026] The third training sample is input into the feature extraction network to obtain the features of the third sample;

[0027] The third sample features are input into the classifiers for the different payment scenarios to obtain the third prediction result;

[0028] Based on the third prediction results of the classifiers for the different payment scenarios, the integrated prediction result is determined;

[0029] Based on the integrated prediction results and the third label, a third loss function is determined;

[0030] The classifiers for the different payment scenarios are updated based on the third loss function.

[0031] Specifically, the feature extraction network includes:

[0032] The representation layer is used to project the input payment event onto the feature space and perform semantic alignment to obtain a first feature vector;

[0033] The processing layer is used to perform feature extraction and feature interaction at different depths on the first feature vector to obtain the second feature vector.

[0034] The combination layer is used to concatenate the second feature vector to obtain the third feature vector.

[0035] According to the second aspect, a payment risk identification method is provided, including:

[0036] Retrieve the payment event to be identified;

[0037] The payment event is input into the payment risk identification model; the payment risk identification model is generated using any of the above-mentioned methods for generating payment risk identification models.

[0038] Based on the prediction results of each classifier in the payment model, the risk outcome of the payment event is determined.

[0039] According to the third aspect, an apparatus for generating a payment risk identification model is provided, comprising:

[0040] The first data acquisition module is configured to acquire a first training sample and a first label, wherein the first training sample is a payment event under a preset different payment scenario;

[0041] The first processing module is configured to set up a classifier for each payment scenario and train the classifier based on the first training sample and the first label.

[0042] The second processing module is configured to select at least one payment scenario, use the training samples of the payment scenario as the second training samples; input the second training samples into the classifier of the payment scenario, use the obtained prediction results as the second label; and perform integrated training on other classifiers based on the second training samples and the second label.

[0043] The generation module is configured to integrate the trained classifier into the payment risk identification model.

[0044] As an optional implementation of the method described in the third aspect, the apparatus further includes a feature extraction module configured to input training samples into a feature extraction network to obtain sample features.

[0045] Specifically, the feature extraction network includes:

[0046] The representation layer is used to project the input payment event onto the feature space and perform semantic alignment to obtain a first feature vector;

[0047] The processing layer is used to perform feature extraction and feature interaction at different depths on the first feature vector to obtain the second feature vector.

[0048] The combination layer is used to concatenate the second feature vector to obtain the third feature vector.

[0049] As an optional implementation of the method described in the third aspect, the first data acquisition module is further configured to acquire a third training sample under the target payment scenario; the device further includes a third processing module.

[0050] The third processing module is configured to select the payment scenario whose sample distribution is closest to that of the target payment scenario; input the third training sample into the classifier of the payment scenario, and use the obtained prediction result as the third label; and perform integrated training on the classifiers of the different payment scenarios based on the third training sample and the third label.

[0051] According to the fourth aspect, a payment risk identification device is provided, comprising:

[0052] The second data acquisition module is configured to acquire payment events to be identified;

[0053] The risk identification module is configured to input the payment event into the payment risk identification model, and determine the risk outcome of the payment event based on the prediction results of each classifier in the payment model; the payment risk identification model is generated using any of the above-mentioned payment risk identification model generation methods.

[0054] According to a fifth aspect, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements any of the above-described methods for generating payment risk identification models.

[0055] According to a sixth aspect, an electronic device is provided, comprising:

[0056] One or more processors; and

[0057] A memory associated with the one or more processors, the memory being used to store program instructions that, when read and executed by the one or more processors, perform any of the steps of the above-described method for generating a payment risk identification model.

[0058] According to a seventh aspect, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the payment risk identification method as described above.

[0059] According to the eighth aspect, an electronic device is provided, comprising:

[0060] One or more processors; and

[0061] A memory associated with the one or more processors, the memory being used to store program instructions that, when read and executed by the one or more processors, perform the steps of the payment risk identification method as described above.

[0062] The payment risk identification model generation method provided by one or more embodiments of this specification can improve the risk identification accuracy in each payment scenario by training classifiers for each payment scenario individually. For each classifier, cross-scenario knowledge transfer can be achieved through ensemble learning of the corresponding payment scenario by other classifiers, fully learning common and specific knowledge between scenarios to improve the generalization ability of the obtained payment risk identification model and solve the domain generalization problem. In addition, for the target payment scenario, selecting the closest known payment scenario as the label and ensemble training classifiers for other payment scenarios can solve the domain adaptation problem. The payment risk identification model obtained above has high accuracy, identification efficiency, reusability, and a wide range of applications, and can be applied to the payment risk identification method provided in the embodiments of this specification.

[0063] The payment risk identification model generation apparatus and payment risk identification apparatus provided in one or more embodiments of this specification also have the above-mentioned beneficial effects. Attached Figure Description

[0064] To more clearly illustrate the technical solutions in one or more embodiments of this specification or in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0065] Figure 1 This is a flowchart illustrating a method for generating a payment risk identification model, provided for one or more embodiments of this specification.

[0066] Figure 2 An exemplary flowchart of the payment risk identification model provided in one or more embodiments of this specification is shown in a scenario.

[0067] Figure 3 The data format of a payment event in one or more embodiments of this specification is shown as an example.

[0068] Figure 4 This is a flowchart illustrating a payment risk identification method provided for one or more embodiments of this specification.

[0069] Figure 5 This specification provides a structural block diagram of a payment risk identification model generation device according to one or more embodiments.

[0070] Figure 6 This specification provides a structural block diagram of a payment risk identification device according to one or more embodiments.

[0071] Figure 7 This is a schematic diagram of a payment risk identification system provided for one or more embodiments of this specification.

[0072] Figure 8 This is a schematic diagram of another payment risk identification system provided in one or more embodiments of this specification.

[0073] Figure 9 This is a structural diagram of an electronic device provided for one or more embodiments of this specification. Detailed Implementation

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

[0075] To facilitate understanding of the solutions in this specification, some technical terms involved in the embodiments of this specification will be explained below.

[0076] (1) Fund risk: refers to behaviors that threaten the security of funds during the transaction payment process, including but not limited to theft, fraud, etc.

[0077] (2) Green Risk Management: ESG (Environmental, Social, and Governance) is a comprehensive assessment method for enterprises, aiming to measure their performance in environmental, social, and governance aspects, thereby providing information about their sustainability and risks. In the context of ESG, the purpose of green risk management is to prevent resource waste and promote sustainable economic, social, and environmental development.

[0078] (3) Domain Adaptation (DA): Domain adaptation addresses the problem that, due to the unique properties of different domains, the same model may perform differently in different real-world applications. It aims to solve the problem of decreased generalization performance caused by differences between the data source domain and the target domain. In domain adaptation, data from both the source and target domains are used to train the model. However, the distribution differences between the source and target domains mean that a model trained on the target domain may not generalize well to new data distributions. Therefore, domain adaptation methods are designed to handle target domains where the data distribution is perceptible during training, but the label distribution is not. It adapts knowledge from the source domain to the target domain scenario to improve the model's generalization performance.

[0079] (4) Domain Generalization (DG): The problem of domain generalization research is to learn a model with strong generalization ability from several data source domains with different data distributions, so as to achieve better results on unknown test sets. It can be used to handle domains where the data distribution and label distribution are not perceptible during the training phase. For example, the concept of domain can be simply mapped to the payment scenario. If we have data from scenario a, scenario b, scenario c, scenario d, and scenario e, and use these as the training set, then the goal of model optimization is not only to achieve better results in the above 5 scenarios, but also to meet sufficient generalization, so that the trained model can also be adapted to the data distribution of the newly emerging scenario x.

[0080] (5) Ensemble Learning: A machine learning concept that combines multiple individual models to achieve better predictive performance than a single model. Ensemble learning can improve the predictive power and robustness of a model, reduce the risk of overfitting, and can be applied to a variety of different machine learning tasks.

[0081] Currently, online payment has become the mainstream transaction method, involving a very wide user base. To protect users' funds, transaction platforms need to conduct risk analysis during each transaction. Typically, the risks involved in a single transaction include, but are not limited to, theft, fraud, etc. In practical applications, a single transaction often corresponds to different payment scenarios, and the underlying event logic and data distribution vary significantly.

[0082] Traditional data modeling involves creating different models for different payment scenarios and then implementing risk control measures separately. In contrast, ESG-advocated green risk control tends to use a more universal model that can effectively identify risks across various payment scenarios. This replaces the previous approach of creating separate models for each sub-scenario, preventing resource waste and achieving the goals of green risk control.

[0083] In different payment scenarios, the marginal probability distribution P(X) and conditional probability distribution P(Y|X) of the data differ. The concept of a domain can be simply mapped to a payment scenario. Some typical examples are transfers to accounts, transfers to cards, online app transactions involving physical goods, and instant transfers to external payment platforms. The data distribution and label distribution of these domains can be perceived during the training phase of the payment risk identification model. However, in actual green risk control, there are also domains where the data distribution and label distribution are imperceptible during the training phase, which can be addressed through domain generalization; domains where the data distribution is known during the training phase but the label distribution is imperceptible, which can be addressed through domain adaptation; and domains added after training as transaction activities develop. These domains may include all of the above types and require a combination of domain generalization and domain adaptation to handle.

[0084] Traditional generalization schemes are typically designed for problems in the field of computer vision, and their adaptability to payment risk identification is low. Therefore, it is necessary to consider the requirements of payment risk identification tasks. On the other hand, traditional schemes model domain generalization and domain adaptation scenarios separately, which makes it difficult to meet the requirements of green risk control.

[0085] Therefore, there is an urgent need for a new payment risk identification scheme that can demonstrate strong risk identification capabilities in different payment scenarios, and uniformly solve the domain adaptation problem and the domain generalization problem, so as to achieve green risk control.

[0086] It should be noted that the steps of the corresponding methods are not necessarily performed in the order shown and described in this specification in other embodiments. In some other embodiments, the methods may include more or fewer steps than described in this specification. Furthermore, a single step described in this specification may be broken down into multiple steps in other embodiments; and multiple steps described in this specification may be combined into a single step in other embodiments.

[0087] The following will provide a more detailed description of the payment risk identification model generation method, payment risk identification method, and apparatus described in the embodiments of this specification, in conjunction with the accompanying drawings and specific examples. However, this detailed description does not constitute a limitation on the embodiments of this specification.

[0088] In some embodiments, a method for generating a payment risk identification model is provided; please refer to [reference needed]. Figure 1 This includes steps S100-S106.

[0089] S100: Obtain the first training sample and set the first label. The first training sample is a payment event under a preset payment scenario.

[0090] In this context, a payment scenario refers to a situation where two parties conduct financial transactions through various platforms, such as online apps, bank transfers, and QR code payments. A payment event can be understood as payment data generated during the payment process. This embodiment does not limit the platform where the payment event or the payment entity is located. Furthermore, the two parties to the transaction are not restricted; they can both be individual users, or it can be a transaction between an individual user and an online merchant. Specifically, payment scenarios can include transfers to accounts, transfers to cards, online app transactions of physical goods, and instant transfers to external platforms. It should be noted that the different payment scenarios corresponding to the first training sample are all within a known domain of known data distribution and label distribution.

[0091] The first label is used to identify the risk level of a payment event in the corresponding payment scenario.

[0092] In some more specific embodiments, the first label can be used to comprehensively characterize whether the corresponding payment event carries risk. In this case, payment risk identification becomes a binary classification problem, with the identification result including whether the payment event carries risk or not. This allows for a simple and quick determination of whether risk exists.

[0093] In other embodiments, the first label can also be used to characterize the risk type of the corresponding payment event, reflecting the specific risk meaning. In this case, payment risk identification in the scenario becomes a multi-classification problem, and the identification result may be, for example, that the payment event involves risks such as theft, fraud, or misuse. This provides more specific risk information, facilitating the effective implementation of subsequent risk management.

[0094] S102: Set up a classifier for each payment scenario, and train the classifier based on the first training sample and the first label.

[0095] Each payment scenario has its own unique data distribution characteristics. To ensure that the payment risk identification model has a relatively accurate risk identification capability for each different payment scenario, a specific classifier can be trained for each payment scenario. The parameters of each classifier are unique to the corresponding payment scenario. After training, each classifier will have a higher risk identification capability for its corresponding payment scenario than for other payment scenarios.

[0096] Optionally, the classifier can be constructed based on a multi-layer fully connected network structure, with its input being the features of the first training sample and its output being the risk identification and classification result of the first training sample.

[0097] By setting classifiers for different payment scenarios in the payment risk identification model, the accuracy of risk identification for different payment scenarios can be improved, thereby achieving the model's versatility.

[0098] In some embodiments, training a classifier based on a first training sample and a first label specifically includes:

[0099] The first training sample is input into the feature extraction network to obtain the features of the first sample;

[0100] Input the features of the first sample into the classifier to obtain the first prediction result;

[0101] Based on the first prediction result and the first label, determine the first loss function;

[0102] Update the classifier based on the first loss function.

[0103] The process of training the classifier is a traditional classification task learning. Specifically, for each classifier, features are extracted from the first training sample in the corresponding payment scenario through a general feature extraction network to obtain the first sample features. The corresponding classifier is then used to classify the risk identification result, i.e., the first prediction result, based on the first sample features. Next, the first loss function is determined by calculating the difference between the first prediction result and the first label, and the loss is calculated. The classifier is trained with the goal of minimizing the loss.

[0104] Specifically, a first loss function can be determined by calculating the cross-entropy between the first prediction result and the first label, then the cross-entropy loss can be calculated, and the classifier can be trained with the goal of minimizing the cross-entropy loss. This loss ensures the accuracy of each classifier in identifying risks for specific payment scenarios.

[0105] Optionally, the feature extraction network includes:

[0106] The representation layer is used to project the input payment event onto the feature space and perform semantic alignment to obtain the first feature vector;

[0107] The processing layer is used to extract features from the first feature vector at different depths and perform feature interactions to obtain the second feature vector.

[0108] The merging layer is used to concatenate the second feature vector to obtain the third feature vector.

[0109] Specifically, the representation layer projects the input payment event onto the feature space, aligns features of the same type in the payment event to their corresponding embedding vectors, and the resulting embedding vectors constitute the first feature vector. The processing layer performs feature extraction and feature interaction at a corresponding depth on different embedding vectors in the first feature vector based on a specific processing mode. Optionally, the processing mode may include residual neural networks, deep feature crossing, shallow feature crossing, or any effective combination of the three. The specific implementation method will be described in the following embodiments. The combination layer concatenates the second feature vectors obtained after processing by different processing modes, and the resulting third feature vector can be used as the first sample feature input to the classifier for risk identification.

[0110] It should be noted that the parameters of this feature extraction network can be shared across all payment scenarios.

[0111] Semantic alignment of payment event features can comprehensively capture the features of different types of payment events. Furthermore, through feature extraction and feature interaction at different depths, the representational power of the obtained feature vectors can be improved, thereby making the risk identification results of the classifier more accurate.

[0112] S104: Select at least one payment scenario and use the training samples of the payment scenario as the second training samples; input the second training samples into the classifier of the payment scenario and use the obtained prediction results as the second label; perform integrated training on other classifiers based on the second training samples and the second label.

[0113] For each specific payment scenario, the classification result output by the classifier corresponding to that scenario is used as a pseudo-label. This enables the construction of samples when both the data distribution and label distribution are unknown, and the classifiers corresponding to other payment scenarios are trained to perform ensemble learning on that payment scenario. This achieves cross-scenario knowledge transfer, fully learns the common and proprietary knowledge between different payment scenarios, thereby improving the overall recognition effect of the payment risk identification model, enhancing the generalization ability of the payment risk identification model, and solving the domain generalization problem mentioned above.

[0114] In some embodiments, ensemble training of other classifiers is performed based on the second training samples and the second label, specifically including:

[0115] The second training sample is input into the feature extraction network to obtain the features of the second sample;

[0116] The features of the second sample are input into other classifiers to obtain the second prediction result;

[0117] Based on the second prediction results of other classifiers, determine the ensemble prediction results of other classifiers;

[0118] Based on the ensemble prediction results of other classifiers and the second label, determine the second loss function;

[0119] The other classifiers are updated based on the second loss function.

[0120] Specifically, for each payment scenario, features are first extracted from the second training sample in that payment scenario using a general feature extraction network to obtain the second sample features. Other classifiers are then used to classify the risk identification result, i.e., the second prediction result, based on the second sample features. The prediction results of all other classifiers are then integrated to obtain the integrated prediction result. Next, the second loss function is determined by calculating the difference between the integrated prediction result and the second label, and the loss is calculated. The second label is the prediction result of the classifier corresponding to that payment scenario for the second training sample. Other classifiers besides the classifier corresponding to that payment scenario are trained with the goal of minimizing the loss.

[0121] Specifically, the ensemble prediction result can be determined by averaging the second prediction results of all other classifiers.

[0122] More specifically, a second loss function can be determined by calculating the mean squared error between the ensemble prediction result and the second label. The mean squared error loss is then calculated, and other classifiers besides the one corresponding to the payment scenario are trained with the goal of minimizing this loss. This loss calculation improves the risk identification performance of each classifier for non-corresponding payment scenarios, enhances the generalization ability of the payment risk identification model, and solves the domain generalization problem.

[0123] It should be noted that the same feature extraction network as that in step S202 can be used directly for feature extraction, so the details of the feature extraction network will not be elaborated here.

[0124] S106: Integrate the trained classifiers into a payment risk identification model.

[0125] The final payment risk identification model consists of a general feature extraction network and several classifiers. After the training samples input into the model have their features extracted by the feature extraction network, the model identifies the payment scenario corresponding to the training samples. If the payment scenario is known, the sample features are input into the corresponding classifier for risk identification; if the payment scenario is unknown, all classifiers are integrated to obtain the identification result.

[0126] In some embodiments, prior to integrating the classifier into the payment risk identification model, the method further includes:

[0127] Obtain the third training sample in the target payment scenario;

[0128] In payment scenarios, select the payment scenario whose sample distribution is closest to the target payment scenario;

[0129] The third training sample is input into the classifier for this payment scenario, and the resulting prediction is used as the third label.

[0130] Based on the third training sample and the third label, classifiers for different payment scenarios are integrated and trained.

[0131] In this embodiment, the data distribution of the target payment scenario corresponding to the third training sample is known, while the label distribution is unknown. Therefore, among payment scenarios where both data and label distributions are known, the payment scenario closest to the target payment scenario is selected, and the prediction result obtained by the classifier corresponding to this payment scenario for the third training sample is used as the pseudo-label, i.e., the third label, thus constructing the sample. Next, all classifiers are trained to perform ensemble learning on this payment scenario, thereby overcoming the difference between the data distribution of the target payment scenario and the known data distribution of payment scenarios, and solving the domain adaptation problem.

[0132] Optionally, the payment scenario with the closest sample distribution to the target payment scenario can be selected. Specifically, for each known payment scenario and its corresponding classifier, the third training sample and the training sample under that payment scenario can be input into the corresponding classifier. The two prediction results are then calculated by vector dot product, and the payment scenario with the largest dot product value is selected as the payment scenario with the closest sample distribution to the target payment scenario.

[0133] Specifically, based on the third training samples and the third label, classifiers for different payment scenarios are ensemble-trained, including:

[0134] The third training sample is input into the feature extraction network to obtain the features of the third sample;

[0135] The features of the third sample are input into classifiers for different payment scenarios to obtain the third prediction result;

[0136] Based on the third prediction results of classifiers for different payment scenarios, determine the integrated prediction result;

[0137] Based on the integrated prediction results and the third label, determine the third loss function;

[0138] The classifiers for different payment scenarios are updated based on the third loss function.

[0139] Specifically, firstly, features are extracted from the third training sample under the target payment scenario using a general feature extraction network to obtain the third sample features; then, risk identification results, i.e., the third prediction results, are obtained by classifying the third sample features using all classifiers respectively, and the prediction results of all classifiers are integrated to obtain the integrated prediction result; next, the third loss function is determined by calculating the difference between the integrated prediction result and the third label, and the loss is calculated, where the third label is the prediction result of the classifier corresponding to the payment scenario closest to the target payment scenario for the third training sample; and finally, all classifiers corresponding to different payment scenarios are trained with the goal of minimizing the loss.

[0140] Specifically, the ensemble prediction result can be determined by calculating the average of the third prediction results of all classifiers.

[0141] More specifically, a third loss function can be determined by calculating the cross-entropy between the ensemble prediction result and the third label. The cross-entropy loss is then calculated, and the goal is to minimize this loss. This method effectively addresses the discrepancy between the data distribution of the target payment scenario and known payment scenarios, allowing for the inference of risk identification results for the target payment scenario from known scenarios, thus resolving the domain adaptation problem.

[0142] It should be noted that the same feature extraction network as that in step S202 can be used directly for feature extraction, so the details of the feature extraction network will not be elaborated here.

[0143] The payment risk identification model generation method described in this embodiment can improve the risk identification accuracy in each payment scenario by training classifiers for each payment scenario individually. For each classifier, ensemble learning of the corresponding payment scenario through other classifiers enables cross-scenario knowledge transfer, fully learning common and specific knowledge across scenarios to improve the generalization ability of the obtained payment risk identification model and solve the domain generalization problem. Furthermore, for the target payment scenario, selecting the closest known payment scenario as the label and ensemble training classifiers for other payment scenarios can solve the domain adaptation problem.

[0144] Figure 2 An exemplary flowchart of the payment risk identification model provided in one or more embodiments of this specification is shown in a scenario.

[0145] In some specific embodiments, please refer to Figure 2 The processing layer includes a residual neural network module (ResMLP), a deep feature cross module (Multi-head Attention), and a shallow feature cross module (FM).

[0146] The representation layer projects the input payment event onto the feature space, divides the resulting feature vector into m fields according to the different types of features, and then projects each field onto the corresponding m embedding vectors to obtain the first feature vector.

[0147] The processing layer extracts and interacts features of the first feature vector at different depths through the residual neural network module, the deep feature cross module, and the shallow feature cross module.

[0148] More specifically, in the residual neural network module, the fully connected layers are connected in a residual manner, as shown in the following equation:

[0149] H(x)=F(x)+x

[0150] Where H(x) represents the output of the next layer in the fully connected layer; F(x) represents the output of the layer before H(x) in the fully connected layer; and x represents the original input of the residual neural network module, i.e., the first feature vector.

[0151] In the deep feature cross module, multi-head attention is an attention mechanism for processing sequential data. It uses multi-head attention to obtain different heads by passing the first feature vector of the input through multiple different linear mappings, then performs attention calculations, and finally concatenates them to obtain the output.

[0152] In the shallow feature crossing module, a factorization machine (FM) is used to perform second-order feature crossing operations, as shown in the following equation:

[0153]

[0154] Where, d e Indicates the number of fields; These are the parameters of the factorization machine; This represents the embedding vector corresponding to the i-th field.

[0155] The merging layer is used to concatenate the second feature vectors obtained after processing by the residual neural network module, the deep feature cross module, and the shallow feature cross module, respectively, and use the resulting third feature vector as the first sample feature input to the classifier for risk identification.

[0156] The encoder in the backbone network of the payment risk identification model can be implemented based on the structure of the feature extraction network described above, and the encoder parameters are shared by all classifiers.

[0157] In this scenario, after extracting the feature vector for each training sample, the feature vector of the training sample is input into the classifier corresponding to the payment scenario according to the payment scenario information in the feature vector, and the classifier outputs the prediction result.

[0158] For ease of explanation, the method for generating the payment risk identification model described in one or more embodiments of this specification is defined as follows.

[0159] Task 1: Obtain the first training sample and set the first label. The first training sample consists of payment events under different preset payment scenarios. Set up a classifier for each payment scenario and train the classifier based on the first training sample and the first label.

[0160] Task II: Select at least one payment scenario and use the training samples of that payment scenario as the second training samples; input the second training samples into the classifier of that payment scenario and use the obtained prediction results as the second label; perform ensemble training on other classifiers based on the second training samples and the second label.

[0161] Task III: Obtain the third training sample under the target payment scenario; in the payment scenario, select the payment scenario whose sample distribution is closest to that of the target payment scenario; input the third training sample into the classifier of the payment scenario, and use the obtained prediction result as the third label; based on the third training sample and the third label, perform integrated training on the classifiers of different payment scenarios.

[0162] Task I is the basic training task, which involves classifying and training the classifier for its corresponding payment scenario. Task II is the integrated training task, which involves classifying the classifier for payment scenarios other than its corresponding payment scenario. Task III is the transfer training of all classifiers given the data distribution of the target payment scenario.

[0163] In one application scenario, facing a payment situation where both the data distribution and label distribution are unknown, corresponding to the domain generalization problem mentioned above, it is necessary to train the classifier for both Task I and Task II simultaneously before generating the payment risk identification model. The specific steps are as follows:

[0164] S200: Obtain the first training sample and set the first label. The first training sample is a payment event under a preset different payment scenario. Set a classifier for each payment scenario and train the classifier based on the first training sample and the first label.

[0165] S202: Select at least one payment scenario and use the training samples of the payment scenario as the second training samples; input the second training samples into the classifier of the payment scenario and use the obtained prediction results as the second label; perform integrated training on other classifiers based on the second training samples and the second label.

[0166] S202: Integrate the trained classifiers into a payment risk identification model.

[0167] For payment scenarios where both data distribution and label distribution are unknown, the method described in S302 is used to select payment scenarios to construct samples and provide corresponding pseudo-labels, enabling other classifiers to learn the knowledge in the payment scenario. The model trained in this way has strong generalization ability and can demonstrate higher risk identification accuracy when facing unknown payment scenarios.

[0168] In another application scenario, facing a target payment scenario where the data distribution is known but the label distribution is unknown, corresponding to the domain adaptation problem mentioned above, it is necessary to train the classifier for both Task I and Task III before generating the payment risk identification model. The specific steps are as follows:

[0169] S300: Obtain the first training sample and set the first label. The first training sample is a payment event under a preset different payment scenario. Set a classifier for each payment scenario and train the classifier based on the first training sample and the first label.

[0170] S302: Obtain the third training sample under the target payment scenario; in the payment scenario, select the payment scenario whose sample distribution is closest to that of the target payment scenario; input the third training sample into the classifier of the payment scenario, and use the obtained prediction result as the third label; based on the third training sample and the third label, perform integrated training on the classifiers of different payment scenarios.

[0171] S304: Integrate the trained classifiers into a payment risk identification model.

[0172] Task III selects the payment scenario that is closest to the target payment scenario from payment scenarios where both data and label distributions are known. The prediction result obtained by the classifier corresponding to this payment scenario for the third training sample is used as the pseudo-label, i.e., the third label, to construct the sample. Then, all classifiers are trained to perform transfer learning on this payment scenario, thereby overcoming the difference between the data distribution of the target payment scenario and the known payment scenarios, and solving the domain adaptation problem.

[0173] In another preferred application scenario, as transaction activities develop, some new unknown payment scenarios will emerge. These payment scenarios may be known payment scenarios where both data distribution and label distribution are known, unknown payment scenarios where both data distribution and label distribution are unknown, or target payment scenarios where the data distribution is known but the label distribution is unknown. Therefore, it is necessary to uniformly solve the domain generalization and domain adaptation problems. Before generating the payment risk identification model, the classifier is trained simultaneously for Task I, Task II, and Task III. The specific steps are as follows:

[0174] S400: Obtain the first training sample and set the first label. The first training sample is a payment event under a preset payment scenario. Set a classifier for each payment scenario and train the classifier based on the first training sample and the first label.

[0175] S402: Select at least one payment scenario and use the training samples of the payment scenario as the second training samples; input the second training samples into the classifier of the payment scenario and use the obtained prediction results as the second label; perform integrated training on other classifiers based on the second training samples and the second label.

[0176] S404: Obtain the third training sample under the target payment scenario; in the payment scenario, select the payment scenario whose sample distribution is closest to that of the target payment scenario; input the third training sample into the classifier of the payment scenario, and use the obtained prediction result as the third label; based on the third training sample and the third label, perform integrated training on the classifiers of different payment scenarios.

[0177] S406: Integrate the trained classifiers into a payment risk identification model.

[0178] Specifically, the loss function used in the traditional classification training for Task I can be the cross-entropy loss function. The loss for each classifier is calculated separately and then averaged, as shown in the following formula:

[0179]

[0180] Where K represents the number of payment scenarios; i represents the index of the current payment scenario; D i H represents the data distribution for the i-th payment scenario; H represents the cross-entropy loss function; E represents the cross-entropy loss function. i This represents the classifier output for the i-th payment scenario; x i Represents the feature of the i-th payment scenario; y(x i ) represents x i The tag 'a' indicates a data augmentation operation (such as intra-domain Mixup), which can be removed.

[0181] The loss function used in the ensemble training for Task II can be the mean squared error loss function. The mean squared error between the prediction results obtained from inputting the training samples into the corresponding classifier and the prediction results obtained from inputting them into other classifiers is calculated for each payment scenario. The average of all payment scenarios is then calculated, as shown in the following formula:

[0182]

[0183] Where K represents the number of payment scenarios, K-1 represents the payment scenario domains other than the current payment scenario; j represents the index of the payment scenario other than the current payment scenario; A represents data augmentation operations (such as intra-domain Mixup, etc.), which can be removed.

[0184] The loss function used during training for Task III can be the cross-entropy loss function. First, the classifier corresponding to the payment scenario closest to the target payment scenario is selected. Then, the loss is determined based on the prediction results of this classifier for the training samples and the prediction results of other classifiers, as shown in the following formula:

[0185]

[0186] Where t represents the target payment scenario; D T p represents the data distribution of the T-th payment scenario, i.e., the target payment scenario; i* This represents the similarity between the target payment scenario and known payment scenarios; max represents the maximum value function; ∈ represents the hyperparameter; x represents t pseudo-tags; H represents the average value of the classifier output; H represents the cross-entropy loss function.

[0187] In summary, during the classifier training process in the payment risk identification model, the overall loss function is as follows:

[0188]

[0189] Here, α, β, and γ represent hyperparameters, which are manually adjusted by technicians based on specific scenarios or experience. By adjusting α, β, and γ, the obtained payment risk identification model can be made more suitable for domain generalization or domain adaptation problems. For example, when dealing with domain generalization problems, Task III is not involved in the training process, so the value of γ can be set to 0.

[0190] It should be noted that training samples can be extracted from K payment scenarios in the dataset where both the data distribution and label distribution are known. Classifier training and ensemble training are performed within these K known payment scenarios to fully simulate payment risk identification tasks under different scenarios, thereby facilitating generalization to real unknown payment scenarios.

[0191] In some specific scenarios, during the training phase, each payment event to be identified can be set as follows: Figure 3 The data format shown is [event_id, label, feature, domain]. Please refer to [reference needed]. Figure 3 .

[0192] Wherein, event_id represents the identity credential (e.g., ID) of the current payment event; label represents the label of the current payment event, with 0 indicating no risk, 1 indicating risk, or indicating whether a specific risk type exists; feature represents the characteristics of the current payment event; and domain represents the payment scenario to which the current payment event belongs.

[0193] In some embodiments, a payment risk identification method is also provided, such as Figure 4 As shown, it includes:

[0194] S500: Obtain the payment event to be identified.

[0195] S502: Input the payment event into the payment risk identification model; the payment risk identification model is generated using any of the above-mentioned methods for generating payment risk identification models.

[0196] S504: Determine the risk outcome of a payment event based on the prediction results of each classifier in the payment model.

[0197] A payment event may contain the payment scenario corresponding to the payment event, or information such as the identity credentials of the payment event.

[0198] Specifically, for payment scenarios that already exist during the model training phase, the payment risk identification model uses the following method for risk prediction:

[0199] a. If the payment event belongs to a known payment scenario where both the data distribution and label distribution are known, then the risk outcome of the payment event is determined directly based on the prediction result of the classifier corresponding to the payment scenario;

[0200] b. If the payment event belongs to an unknown payment scenario where both the data distribution and label distribution are unknown, corresponding to the domain generalization problem, the prediction result output by all classifiers after ensemble learning can be taken as the risk result of the payment event. For example, the average value of the output results of each classifier can be taken.

[0201] c. If the payment event belongs to the target payment scenario with known data distribution but unknown label distribution, then take the prediction result of the classifier corresponding to the known payment scenario that is closest to the target payment scenario, and determine the risk outcome of the payment event.

[0202] For payment scenarios added after the training phase, such as those added due to the expansion of transaction activities or changes in the risk situation, the risk identification task first needs to be classified according to the definition of domain generalization and domain adaptation, and then the risk results are output according to the specific task type.

[0203] Corresponding to the above method, one embodiment of this specification also provides a device for generating a payment risk identification model. Please refer to [link / reference]. Figure 5 The device includes:

[0204] The first data acquisition module 60 is configured to acquire a first training sample and a first label. The first training sample is a payment event under a preset different payment scenario.

[0205] The first processing module 62 is configured to set up a classifier for each payment scenario and train the classifier based on the first training sample and the first label.

[0206] The second processing module 64 is configured to select at least one payment scenario, use the training samples of the payment scenario as the second training samples; input the second training samples into the classifier of the payment scenario, use the obtained prediction results as the second label; and perform integrated training on other classifiers based on the second training samples and the second label.

[0207] Module 66 is configured to integrate the trained classifier into a payment risk identification model.

[0208] In some embodiments, the apparatus further includes a feature extraction module configured to input training samples into a feature extraction network to obtain sample features.

[0209] Specifically, the feature extraction network includes:

[0210] The representation layer is used to project the input payment event onto the feature space and perform semantic alignment to obtain the first feature vector;

[0211] The processing layer is used to extract features from the first feature vector at different depths and perform feature interactions to obtain the second feature vector.

[0212] The merging layer is used to concatenate the second feature vector to obtain the third feature vector.

[0213] In some embodiments, the first processing module further includes: inputting a first training sample into a feature extraction module to obtain a first sample feature; inputting the first sample feature into a classifier to obtain a first prediction result; determining a first loss function based on the first prediction result and a first label; and updating the classifier based on the first loss function.

[0214] In some embodiments, the second processing module further includes: inputting the second training sample into the feature extraction module to obtain the second sample features; inputting the second sample features into other classifiers respectively to obtain the second prediction results; determining the ensemble prediction results of other classifiers based on the second prediction results of other classifiers; determining the second loss function based on the ensemble prediction results of other classifiers and the second label; and updating other classifiers based on the second loss function.

[0215] In some embodiments, the first data acquisition module is further configured to acquire a third training sample under the target payment scenario; the device also includes a third processing module;

[0216] The third processing module is configured to select the payment scenario whose sample distribution is closest to the target payment scenario; input the third training sample into the classifier of the payment scenario, and use the obtained prediction result as the third label; and perform integrated training on the classifiers of different payment scenarios based on the third training sample and the third label.

[0217] Specifically, the third processing module further includes: inputting the third training sample into the feature extraction module to obtain the third sample feature; inputting the third sample feature into the classifiers for different payment scenarios to obtain the third prediction result; determining the ensemble prediction result based on the third prediction result of the classifiers for different payment scenarios; determining the third loss function based on the ensemble prediction result and the third label; and updating the classifiers for different payment scenarios based on the third loss function.

[0218] In some embodiments, a payment risk identification device is also provided, such as Figure 6 As shown, it includes:

[0219] The second data acquisition module 70 is configured to acquire payment events to be identified;

[0220] The risk identification module 72 is configured to input the payment event into the payment risk identification model and determine the risk outcome of the payment event based on the prediction results of each classifier in the payment model; the payment risk identification model is generated using any of the above-mentioned payment risk identification model generation methods.

[0221] Figure 7 An exemplary payment risk identification system is shown, which can be used to implement the payment risk identification model generation method and payment risk identification method in the above embodiments. It should be noted that the payment risk identification model generation method and payment risk identification method described in one or more embodiments of this application can rely on... Figure 7 The payment risk identification system shown is implemented, but is not limited to this payment risk identification system.

[0222] like Figure 7As shown, the payment risk identification system includes a payment terminal and an identification terminal. In this embodiment, the payment terminal and the identification terminal can be deployed in two separate terminal devices. The payment terminal connects to the identification terminal via a communication link, which can be a wired network or a wireless network. For example, the payment terminal can use communication methods such as WIFI, Bluetooth, or infrared to establish a communication connection with the identification terminal. Alternatively, the payment terminal can also establish a communication connection with the identification terminal through a mobile network, where the mobile network standard can be any one of 2G (GSM), 2.5G (GPRS), 3G (WCDMA, TD-SCDMA, CDMA2000, UTMS), 4G (LTE), 4G+ (LTE+), WiMax, etc.

[0223] The payment terminal can be a mobile phone, tablet computer, laptop computer, personal computer, or other terminal device capable of online transactions, configured for user-executed transactions. A trained payment risk identification model is deployed within the identification terminal. It can acquire transaction data from user transactions at the payment terminal via a communication link, input the transaction data into the payment risk identification model to identify risks, output the identification result, and then return the result to the payment terminal to inform the user. The identification terminal can be any device, equipment, platform, or device cluster with computing and processing capabilities. This embodiment does not limit the implementation form of the identification terminal. For example, the identification terminal can be a single server, a server cluster consisting of multiple servers, or a cloud server, also known as a cloud computing server or cloud host, which is a host product in the cloud computing service system. The payment risk identification model can be trained within the identification terminal or the payment terminal, or it can be trained on one or more other servers.

[0224] Figure 8 Another payment risk identification system is illustrated as an example. In this embodiment, the payment terminal and the identification terminal can be deployed in the same terminal device as a payment module and an identification module, such as... Figure 8 As shown, the terminal devices may include user device 82, user device 84, and user device 86. Each user device can independently complete transactions and perform risk identification under the user's operation. Specifically, each user device can use the data in the data storage system 80 to train a payment risk identification model itself, or the payment risk identification model can be trained by other servers or devices. The trained model is then stored in the data storage system 80 in the form of program code, and the user device calls the program code in the data storage system 80 to implement the payment risk identification method provided in the embodiments of this specification.

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

[0226] Corresponding to the above-described method for generating the payment risk identification model, this embodiment also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the above-described method for generating the payment risk identification model.

[0227] Corresponding to the payment risk identification method described above, this embodiment also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the payment risk identification method described above.

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

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

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

[0231] Corresponding to the above-described method for generating the payment risk identification model, this embodiment also provides an electronic device, including:

[0232] One or more processors; and

[0233] A memory associated with the one or more processors, the memory being used to store program instructions that, when read and executed by the one or more processors, perform the steps of the method for generating the payment risk identification model described above.

[0234] Corresponding to the above-described payment risk identification method, this embodiment also provides an electronic device, including:

[0235] One or more processors; and

[0236] A memory associated with the one or more processors, the memory being used to store program instructions that, when read and executed by the one or more processors, perform the steps of the payment risk identification method described above.

[0237] Please refer to Figure 9 , Figure 9 This is an exemplary embodiment illustrating the hardware structure of an electronic device 900 containing a distributed transaction processing device.

[0238] At the hardware level, the device includes a processor 902, a computer-readable storage medium 904, memory 906, a data interface 908, and a network interface 910, and may also include other hardware required for business operations. One or more embodiments of this specification can be implemented in software, for example, the processor 902 reads the corresponding computer program from the computer-readable storage medium 904 into memory 906 and then runs it. Of course, besides software implementation, one or more embodiments of this specification do not exclude other implementation methods, such as logic devices or a combination of hardware and software, etc. That is to say, the execution entity of the above processing flow is not limited to individual logic units, but can also be hardware or logic devices.

[0239] It is understood that the structures illustrated in the embodiments of this specification do not constitute a specific limitation on the system of the embodiments of this specification. In other embodiments of the specification, the above system may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0240] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the apparatus embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0241] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0242] It should be noted that the above examples are merely specific embodiments of the present invention, and the present invention is obviously not limited to the above embodiments, with many similar variations. All modifications that can be directly derived or conceived by those skilled in the art from the content disclosed in this invention should fall within the protection scope of this invention.

Claims

1. A method for generating a payment risk identification model, comprising: Obtain a first training sample and set a first label. The first training sample consists of payment events under different preset payment scenarios. A classifier is set up for each payment scenario, and a corresponding classifier is trained for each payment scenario based on the first training sample and the first label. Select at least one payment scenario and use the training samples whose data distribution and label distribution for that payment scenario are both unknown as the second training samples. The second training sample is input into the feature extraction network to obtain the features of the second sample; The second sample features are input into the classifier for this payment scenario, and the resulting prediction is used as the second label. The second sample features are then input into other classifiers to obtain the second prediction result; Based on the second prediction results of the other classifiers, determine the ensemble prediction results of the other classifiers; Based on the ensemble prediction results of the other classifiers and the second label, a second loss function is determined; The other classifiers are updated based on the second loss function; The trained classifiers are integrated into the payment risk identification model.

2. The method as described in claim 1, wherein training the classifier based on the first training sample and the first label specifically includes: The first training sample is input into the feature extraction network to obtain the first sample features; The first sample features are input into the classifier to obtain the first prediction result; Based on the first prediction result and the first label, a first loss function is determined; The classifier is updated based on the first loss function.

3. The method of claim 1, further comprising, before integrating the classifier into the payment risk identification model: Obtain the third training sample in the target payment scenario; In the payment scenarios, the payment scenario whose sample distribution is closest to the target payment scenario is selected; The third training sample is input into the classifier for this payment scenario, and the resulting prediction is used as the third label. Based on the third training sample and the third label, the classifiers for the different payment scenarios are integrated and trained.

4. The method as described in claim 3, wherein the classifiers for the different payment scenarios are integrated and trained based on the third training samples and the third labels, specifically including: The third training sample is input into the feature extraction network to obtain the features of the third sample; The third sample features are input into the classifiers for the different payment scenarios to obtain the third prediction result; Based on the third prediction results of the classifiers for the different payment scenarios, the integrated prediction result is determined; Based on the integrated prediction results and the third label, a third loss function is determined; The classifiers for the different payment scenarios are updated based on the third loss function.

5. The method according to any one of claims 1 to 4, wherein the feature extraction network comprises: The representation layer is used to project the input payment event onto the feature space and perform semantic alignment to obtain a first feature vector; The processing layer is used to perform feature extraction and feature interaction at different depths on the first feature vector to obtain the second feature vector. The combination layer is used to concatenate the second feature vector to obtain the third feature vector.

6. A method for identifying payment risks, comprising: Retrieve the payment event to be identified; Input the payment event into the payment risk identification model; The payment risk identification model is generated using the method described in any one of claims 1 to 5; Based on the prediction results of each classifier in the payment risk identification model, the risk outcome of the payment event is determined.

7. A device for generating a payment risk identification model, comprising: The first data acquisition module is configured to acquire a first training sample and a first label, wherein the first training sample is a payment event under a preset different payment scenario; The first processing module is configured to set up a classifier for each payment scenario, and train a corresponding classifier for each payment scenario based on the first training sample and the first label. The second processing module is configured to: select at least one payment scenario; use training samples whose data distribution and label distribution for the payment scenario are both unknown as second training samples; input the second training samples into a feature extraction network to obtain second sample features; input the second sample features into a classifier for the payment scenario and use the resulting prediction as a second label; input the second sample features into other classifiers to obtain second prediction results; determine the ensemble prediction result of the other classifiers based on the second prediction results of the other classifiers; determine a second loss function based on the ensemble prediction result of the other classifiers and the second label; and update the other classifiers based on the second loss function. The generation module is configured to integrate the trained classifier into the payment risk identification model.

8. The apparatus of claim 7, further comprising a feature extraction module configured to input training samples into a feature extraction network to obtain sample features.

9. The apparatus of claim 8, wherein the feature extraction network comprises: The representation layer is used to project the input payment event onto the feature space and perform semantic alignment to obtain a first feature vector; The processing layer is used to perform feature extraction and feature interaction at different depths on the first feature vector to obtain the second feature vector. The combination layer is used to concatenate the second feature vector to obtain the third feature vector.

10. The apparatus of claim 7, wherein the first data acquisition module is further configured to acquire a third training sample in the target payment scenario; the apparatus further comprises a third processing module; The third processing module is configured to select the payment scenario whose sample distribution is closest to that of the target payment scenario; input the third training sample into the classifier of the payment scenario, and use the obtained prediction result as the third label; and perform integrated training on the classifiers of the different payment scenarios based on the third training sample and the third label.

11. A payment risk identification device, comprising: The second data acquisition module is configured to acquire payment events to be identified; The risk identification module is configured to input the payment event into the payment risk identification model and determine the risk outcome of the payment event based on the prediction results of each classifier in the payment model. The payment risk identification model is generated using the method described in any one of claims 1 to 5.

12. A computer-readable storage medium having a computer program stored thereon, the computer program, when executed by a processor, implementing the method as claimed in any one of claims 1 to 5.

13. An electronic device, comprising: One or more processors; as well as A memory associated with the one or more processors, the memory being used to store program instructions that, when read and executed by the one or more processors, perform the steps of the method as described in any one of claims 1 to 5.

14. A computer-readable storage medium having a computer program stored thereon, the computer program, when executed by a processor, implementing the method of claim 6.

15. An electronic device comprising: One or more processors; as well as A memory associated with the one or more processors, the memory being used to store program instructions that, when read and executed by the one or more processors, perform the steps of the method as described in claim 6.

Images