A payment method, device and network system based on risk association model

Abstract

The present invention discloses a payment method, device and network system based on a risk association model, the method comprising: upon receiving a payment request, obtaining a payment-related data set of a payer account and a payment-related data set of a payee account corresponding to the payment request; using a target risk association model to identify risks of the payment-related data set of the payer account and / or the payment-related data set of the payee account, and obtaining payment risk information corresponding to the payment request; using a payment method corresponding to the payment risk information, and executing a payment operation corresponding to the payment request. The technical solution disclosed in the present invention can improve the convenience and security of payment.

Description

Technical Field

[0001] The present disclosure relates to the field of electronic payment technology, and in particular to a payment method, device and network system based on a risk association model. Background Art

[0002] With the continuous evolution of payment methods, the gradual expansion of payment channels, and the continuous promotion of new payment methods, people's lives are becoming more and more convenient. Among them, risk control for payment can, for example, limit the payment amount and improve payment security by dynamically analyzing payment data. Summary of the invention

[0003] In order to overcome the problems existing in the related art, the present disclosure provides a payment method, device and network system based on a risk association model.

[0004] According to a first aspect of an embodiment of the present disclosure, a payment method based on a risk association model is provided, comprising:

[0005] When a payment request is received, obtaining a payment-related data set of a payer account and a payment-related data set of a payee account corresponding to the payment request;

[0006] Using a target risk association model to perform risk identification on a payment-related data set of the payer's account and / or a payment-related data set of the payee's account, and obtaining payment risk information corresponding to the payment request;

[0007] The payment operation corresponding to the payment request is performed using the payment method corresponding to the payment risk information.

[0008] According to some embodiments, obtaining a payment-related data set of a payer account and a payment-related data set of a payee account corresponding to the payment request includes:

[0009] Obtaining a payment requirement corresponding to the payment request, wherein the payment requirement includes at least one of a payment requirement corresponding to the payer account and a payment requirement corresponding to the payee account;

[0010] In the case that the payment data in the payment request does not meet the payment requirement, a payment related data set of a payer account and a payment related data set of a payee account corresponding to the payment request are obtained.

[0011] According to some embodiments, the step of using a target risk association model to perform risk identification on a payment-related data set of the payer's account and / or a payment-related data set of the payee's account to obtain payment risk information corresponding to the payment request includes:

[0012] When it is determined by using a target risk association model that the account data in the payment-related data set of the payer account and the account data in the payment-related data set of the payee account are not preset account data, obtaining a payment requirement corresponding to the payment request, wherein the payment requirement includes a payment requirement corresponding to the payer account and a payment requirement corresponding to the payee account;

[0013] According to the historical payment data set corresponding to the payer account and the historical payment data set corresponding to the payee account, the payment requirement is adjusted using a target risk association model to obtain an adjusted payment requirement;

[0014] A target risk association model is used to identify risks of the adjusted payment requirement and the payment data, and payment risk information corresponding to the payment request is obtained.

[0015] According to some embodiments, the payment requirement includes the payment requirement corresponding to the payer account, and the step of using a target risk association model to perform risk identification on a payment-related data set of the payer account to obtain payment risk information corresponding to the payment request includes:

[0016] According to the historical payment data set corresponding to the payer account, a target risk association model is used to obtain the standard deviation and mean corresponding to the payer account;

[0017] The payment requirement corresponding to the payer account is adjusted according to the standard deviation and the mean to obtain the payment requirement corresponding to the payer account after adjustment.

[0018] According to some embodiments, the adopting the payment means corresponding to the payment risk information to perform the payment operation corresponding to the payment request includes:

[0019] When it is determined by using a target risk association model that the account data in the payment-related data set of the payer's account and the account data in the payment-related data set of the payee's account are not preset account data, obtaining a payment verification method corresponding to the payment risk information, wherein different payment risk information corresponds to payment verification methods of different complexity;

[0020] Performing payment verification on the payment data using the payment verification method;

[0021] When the payment verification is passed and the payment data is within the payment data range corresponding to the adjusted payment request, the payment operation corresponding to the payment request is completed.

[0022] According to some embodiments, the step of using a target risk association model to perform risk identification on a payment-related data set of the payer's account and / or a payment-related data set of the payee's account to obtain payment risk information corresponding to the payment request includes:

[0023] Using a target risk association model to identify the risks of the account data in the payment-related data set of the payer's account and the account data in the payment-related data set of the payee's account, and obtaining the security level of the account data of the payee's account;

[0024] In a case where the security level of the account data of the payee account indicates that the security level of the payee account is a preset security level account, determining that the payment risk information is payable information, wherein the payable information is used to indicate that a payment method corresponding to the payment risk information is used to perform a payment operation corresponding to the payment request;

[0025] or,

[0026] When the security level of the account data of the payee account indicates that the security level of the payee account is a preset unsafe level account, the payment risk information is determined to be unpayable information, wherein the unpayable information is used to instruct to stop executing the payment operation corresponding to the payment request.

[0027] According to some embodiments, the method further comprises:

[0028] Obtain a historical payment data set corresponding to the payer account, a historical payment data set corresponding to the payee account, and a payment completion data set within a historical time period, wherein the payment completion data set includes payment completion data in the historical payment data set corresponding to the payer account and payment completion data in the historical payment data set corresponding to the payee account;

[0029] Get historical account information;

[0030] The target risk association model is trained based on the connectivity relationship between the historical payment data set corresponding to the payer account, the historical payment data set corresponding to the payee account and the payment completion data set, as well as the historical account information, wherein the target risk association model is a multi-factor risk association model.

[0031] According to some embodiments, the method further comprises:

[0032] Processing the historical payment data set corresponding to the payer account, the historical payment data set corresponding to the payee account, and the payment completion data set to obtain a processed historical payment data set corresponding to the payer account, a processed historical payment data set corresponding to the payee account, and a processed payment completion data set;

[0033] Obtaining the category information corresponding to each of the processed historical payment data set corresponding to the payer account, the processed historical payment data set corresponding to the payee account, and the processed payment completion data set;

[0034] Obtaining a Gini index corresponding to an initial risk association model according to the category information and the processed historical payment data set corresponding to the payer account, the processed historical payment data set corresponding to the payee account, and the processed payment completion data set, wherein the initial risk association model includes at least two factors;

[0035] When the Gini index meets the index requirement, it is determined that the target risk association model is obtained.

[0036] According to some embodiments, the method further comprises:

[0037] Obtaining payment scenario information corresponding to the payment request;

[0038] Obtain the target risk association model corresponding to the payment scenario information, wherein the target risk association model includes a risk association model corresponding to one factor or a risk association model corresponding to multiple factors, and different factors in the risk association model corresponding to multiple factors correspond to different weights.

[0039] According to a second aspect of an embodiment of the present disclosure, there is provided a payment device based on a risk association model, comprising:

[0040] A data acquisition unit, configured to, upon receiving a payment request, acquire a payment-related data set of a payer's account and a payment-related data set of a payee's account corresponding to the payment request;

[0041] an information acquisition unit, configured to perform risk identification on the payment-related data set of the payer's account and / or the payment-related data set of the payee's account using a target risk association model, and acquire payment risk information corresponding to the payment request;

[0042] The payment operation unit is used to adopt the payment means corresponding to the payment risk information to execute the payment operation corresponding to the payment request.

[0043] According to a third aspect of an embodiment of the present disclosure, there is provided a network system, including:

[0044] processor;

[0045] a memory for storing processor-executable instructions;

[0046] The processor is configured to implement the method described in the first aspect above.

[0047] According to a fourth aspect of an embodiment of the present disclosure, a non-temporary computer-readable storage medium is provided, wherein the non-temporary computer-readable storage medium stores computer-executable instructions; after the computer-executable instructions are executed by a processor, the method described in the first aspect above can be implemented.

[0048] According to a fifth aspect of an embodiment of the present application, a computer program product is provided, including a computer program, wherein the computer program implements any one of the methods described in the preceding aspects when executed by a processor.

[0049] The technical solution provided by the embodiments of the present disclosure may include the following beneficial effects: when a payment request is received, the payment-related data set of the payer's account and the payment-related data set of the payee's account corresponding to the payment request are obtained; the target risk association model is used to identify the risk of the payment-related data set of the payer's account and / or the payment-related data set of the payee's account, and the payment risk information corresponding to the payment request is obtained; the payment means corresponding to the payment risk information is used to perform the payment operation corresponding to the payment request. Therefore, the present disclosure can judge the payment-related data sets of the two payment parties, dynamically adjust the payment restrictions, dynamically control the payment process, and reduce the situation where static control makes the payment convenience poor, and the associated risk model can identify the payment data, improve the accuracy of data analysis, improve the accuracy of obtaining payment risk information, improve the flexibility of payment control, and improve the convenience and security of payment.

[0050] It is to be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0051] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present disclosure and, together with the description, serve to explain the principles of the present disclosure.

[0052] Figure 1 is a flow chart of a payment method based on a risk association model according to some embodiments of the present disclosure;

[0053] Figure 2 is a flow chart of a payment method based on a risk association model according to some embodiments of the present disclosure;

[0054] Figure 3 is an exemplary schematic diagram of a payment device based on a risk association model according to some embodiments of the present disclosure;

[0055] Figure 4 is an exemplary schematic diagram of a network system according to some embodiments of the present disclosure. DETAILED DESCRIPTION

[0056] Some embodiments of the present disclosure will be described in detail here, and examples thereof are shown in the accompanying drawings. When the following description refers to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. Various changes, modifications and equivalents of the methods, systems and / or systems described herein will become apparent after understanding the present disclosure. For example, the order of operations described herein is merely an example and is not limited to those orders set forth herein, but can be changed as becomes apparent after understanding the present disclosure, except for operations that must be performed in a specific order. In addition, for clarity and brevity, descriptions of features known in the art may be omitted.

[0057] The embodiments described in some embodiments of the present disclosure below do not represent all embodiments consistent with the present disclosure. Instead, they are only examples of systems and methods consistent with some aspects of the present disclosure as detailed in the appended claims.

[0058] In some embodiments, the recording method of "A or B" may include the following technical solutions according to the situation: in some embodiments, A (A is executed independently of B); in some embodiments, B (B is executed independently of A); in some embodiments, execution is selected from A and B (A and B are selectively executed). When there are more branches such as A, B, C, etc., the above is also similar.

[0059] In some embodiments, terms such as "in response to ...", "in response to determining ...", "in the case of ...", "at the time of ...", "when ...", "if ...", "if ...", etc. can be used interchangeably.

[0060] The prefixes such as "first" and "second" in the embodiments of the present disclosure are only used to distinguish different description objects, and do not constitute restrictions on the position, order, priority, quantity or content of the description objects. The statement of the description object refers to the description in the context of the claims or embodiments, and should not constitute unnecessary restrictions due to the use of prefixes. For example, if the description object is a "field", the ordinal number before the "field" in the "first field" and the "second field" does not limit the position or order between the "fields", and the "first" and "second" do not limit whether the "fields" they modify are in the same message, nor do they limit the order of the "first field" and the "second field". For another example, if the description object is a "level", the ordinal number before the "level" in the "first level" and the "second level" does not limit the priority between the "levels". For another example, the number of description objects is not limited by the ordinal number, and can be one or more. Taking the "first device" as an example, the number of "devices" can be one or more. In addition, the objects modified by different prefixes may be the same or different. For example, if the description object is "device", then the "first device" and the "second device" may be the same device or different devices, and their types may be the same or different. For another example, if the description object is "information", then the "first information" and the "second information" may be the same information or different information, and their contents may be the same or different.

[0061] In some embodiments, devices and equipment may be interpreted as physical or virtual, and their names are not limited to the names recorded in the embodiments. In some cases, they may also be understood as "equipment", "device", "circuit", "network element", "node", "function", "unit", "section", "system", "network", "chip", "chip system", "entity", "subject", etc.

[0062] In some embodiments, "terminal" or "terminal device" may be referred to as "user equipment (UE)", "user terminal" "mobile station (MS)", "mobile terminal (MT)", subscriber station, mobile unit, subscriber unit, wireless unit, remote unit, mobile device, wireless device, wireless communication device, remote device, mobile subscriber station, access terminal, mobile terminal, wireless terminal, remote terminal, handset, user agent, mobile client, client, etc.

[0063] In some embodiments, data, information, etc. may be obtained after obtaining account consent.

[0064] It should be noted that the terms "first", "second", etc. in the specification and claims of the present disclosure and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchanged where appropriate, so that the embodiments of the present disclosure described herein can be implemented in an order other than those illustrated or described herein. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present disclosure. Instead, they are merely examples of devices and methods consistent with some aspects of the present disclosure as detailed in the appended claims.

[0065] In some embodiments, the account can control the payment risk during the payment process. Specifically, for example, the payment risk control can be performed using a static risk control method. For example, the transaction amount of a bank card can be limited to RMB 2,000, and risk control is not required for amounts below RMB 2,000.

[0066] In some embodiments, for example, the payment object is a small shop, and the normal distribution of a single consumption may be, for example, between 30 and 70 yuan. For example, the single transaction amount of a Q account may be limited to less than 2,000 yuan, and when the single consumption of a Q account is 1,800 yuan, payment control will not be performed. For example, the payment object is a restaurant, and the normal distribution of a single consumption may be, for example, between 800 and 3,500 yuan. For example, the single transaction amount of a Q account may be limited to less than 2,000 yuan, and when the single consumption of a Q account is 2,200 yuan, payment risk control is performed, causing the payment transaction to fail. Therefore, the convenience and security of payment control are poor, resulting in poor accuracy of payment risk control.

[0067] Figure 1 is a flow chart of a payment method based on a risk association model according to an exemplary embodiment. Figure 1 As shown, the following steps are included:

[0068] In step S11, when a payment request is received, a payment-related data set of a payer's account and a payment-related data set of a payee's account corresponding to the payment request are obtained;

[0069] According to some embodiments, the execution subject of the embodiment of the present disclosure may be, for example, a network system. The name of the network system is not limited. For example, the network system may also be called a server, a server cluster, a network device, etc. The execution subject of the embodiment of the present disclosure may also be an electronic device. The embodiment of the present disclosure does not limit this.

[0070] In some embodiments, the embodiments of the present disclosure may be applied to product payment scenarios. Specifically, for example, it may be applied to scenarios where the transaction information corresponding to the product is greater than the payment threshold and the payment cannot be completed safely, but is not limited thereto. Specifically, for example, it may be a scenario where the transaction information corresponding to the product is not within the payment threshold and the payment cannot be completed safely. Among them, a payment operation of an embodiment of the present disclosure may include, for example, a payer account and a payee account at the same time, wherein the payer account and the payee account exist at the same time, and the payment transactions corresponding to the payer account and the payee account are consistent.

[0071] According to some embodiments, when there are multiple payment parties, the number of payer accounts and payee accounts may be, for example, multiple. Wherein, when the number of payer accounts is multiple, the names of the payer accounts may not be limited, for example, when the number of payer accounts is three, they may be payer account 1, payer account 2, and payer account 3. Wherein, when the number of payee accounts is multiple, the names of the payee accounts may not be limited, for example, when the number of payee accounts is three, they may be payee account 1, payee account 2, and payee account 3. The disclosed embodiments do not limit this.

[0072] In some embodiments, the payer account may be, for example, a device that needs to perform payment operations in a payment scenario. The payer account does not specifically refer to a fixed device. For example, when the login device type corresponding to the payer account changes, the payer account may also change accordingly. For example, when the login application corresponding to the payer account changes, the payer account may also change accordingly. Among them, the name of the payer account is not limited, and any name that can be distinguished from the payee account is acceptable. For example, when the payer account is a first account, the payee account may be, for example, a second account.

[0073] According to some embodiments, the payment request may be, for example, a request initiated when making a payment, and the payment request may be a request initiated when the payer account or the payee account makes a payment. The payment request may be, for example, a payment request generated when the payer account receives a purchase instruction for product A. The payment request does not specifically refer to a fixed request. For example, when the request time point corresponding to the payment request changes, the payment request may also change accordingly. For example, when the product information corresponding to the payment request changes, the payment request may also change accordingly.

[0074] According to some embodiments, the payment-related data set includes account data and historical payment data, and the payee account is another account in the payment request. The payment-related data set of the payee account and the payment-related data set of the payee account corresponding to the payment request may include, for example, the payment-related data set of the payee account and the payment-related data set of the payee account, and specifically, for example, may include account data of the payee account, historical payment data of the payee account, account data of the payee account, and historical payment data of the payee account.

[0075] In some embodiments, the payment-related data set of the payer account can be used to indicate the data set related to the payment made by the payer account. The payment-related data set of the payer account can include, for example, the account data of the payer account and the historical payment data of the payer account. The number of data included in the account data is not limited. The account data can include, for example, at least one account data. The account data can include, for example, the security level information of the account, which can be the account data obtained by identifying the account information of the payer account, or can be set according to the received security level information setting instruction. The embodiments of the present disclosure are not limited to this.

[0076] In some embodiments, the historical payment data may be, for example, data generated by product payments within a preset historical period. The historical payment data includes, but is not limited to, payer identification, recipient identification, payer description, recipient description, transaction information, transaction amount, payment scenario, payment type, and other descriptions. The names of the various data are not limited. For example, the payer may also be referred to as the payee.

[0077] In some embodiments, the historical payment data of the payer account may include, for example, data obtained when the payer account makes payments to other accounts, and the historical payment data may also include, for example, data obtained when other accounts make payments to the payer account. The historical payment data of the payer account does not specifically refer to a fixed historical payment data. For example, when the historical duration corresponding to the historical payment data changes, the historical payment data of the payer account may also change accordingly. For example, when a certain historical payment data included in the historical payment data changes, the historical payment data of the payer account may also change accordingly.

[0078] The historical payment data of the payee account may be, for example, the historical payment data corresponding to the payee account. The historical payment data of the payee account does not specifically refer to a fixed data. The historical payment data of the payee account may, for example, include at least one historical payment data. For example, when the historical duration corresponding to the historical payment data of the payee account changes, the historical payment data of the payee account may also change accordingly. For example, when a certain historical payment data in the historical payment data of the payee account changes, the historical payment data of the payee account may also change accordingly.

[0079] In some embodiments, when a payment request is received, a payment-related data set of a payer's account and a payment-related data set of a payee's account corresponding to the payment request are obtained.

[0080] In step S12, a target risk association model is used to identify risks of a payment-related data set of a payer's account and / or a payment-related data set of a payee's account, and payment risk information corresponding to the payment request is obtained;

[0081] According to some embodiments, the risk association model can, for example, determine the risk information that exists when a payment is made between a payer account and a payee account. The target risk association model can, for example, be a model that has been trained and can be used to determine payment risk information. The target risk association model does not specifically refer to a fixed risk association model. For example, when the payment type corresponding to the payment request changes, the target risk association model may also change accordingly. For example, when the model parameters in the target risk association model change, the target risk association model may also change accordingly. Among them, the name of the risk association model is not limited. For example, the risk association model can also be called a data model, a multi-factor model, etc.

[0082] In some embodiments, the payment risk information may be used to indicate the risk information corresponding to the current payment. The payment risk information may be, for example, a risk value, a risk level, etc. The disclosed embodiments are not limited to this. The payment risk information does not specifically refer to a fixed information. For example, when the target risk association model changes, the payment risk information may also change accordingly.

[0083] In some embodiments, for example, a target risk association model may be used to identify risks of payment-related data sets of the payer's account and / or payment-related data sets of the payee's account, and obtain payment risk information corresponding to the payment request. Specifically, which data sets are to be identified for risk needs to be determined based on the number of factors required for risk identification. This disclosure embodiment does not limit this.

[0084] In step S13, a payment method corresponding to the payment risk information is used to execute a payment operation corresponding to the payment request.

[0085] In some embodiments, when payment risk information is obtained, a payment method corresponding to the payment risk information is used to perform a payment operation corresponding to the payment request.

[0086] According to some embodiments, the payment means may be, for example, a payment method used when making a payment. The payment means does not specifically refer to a fixed payment means, for example, the payment means may include at least one payment verification method.

[0087] The technical solution provided by the embodiments of the present disclosure may include the following beneficial effects: when a payment request is received, the payment-related data set of the payer's account and the payment-related data set of the payee's account corresponding to the payment request are obtained; the payment-related data set of the payer's account and / or the payment-related data set of the payee's account are identified for risk using a target risk association model to obtain payment risk information corresponding to the payment request; the payment means corresponding to the payment risk information are used to execute the payment operation corresponding to the payment request. Thus, the present disclosure can judge the payment-related data sets of both parties to the payment, dynamically adjust the payment restrictions, dynamically control the payment process, and reduce the situation where static control makes the payment convenience poor, and the associated risk model can identify the payment data, improve the accuracy of data analysis, improve the accuracy of obtaining payment risk information, improve the flexibility of payment control, and improve the convenience and security of payment.

[0088] Figure 2 is a flow chart of a payment method based on a risk association model according to an exemplary embodiment. Figure 2 As shown, the following steps are included:

[0089] In step S21, when a payment request is received from a payer account, a payment requirement corresponding to the payment request is obtained, wherein the payment requirement includes at least one of a payment requirement corresponding to the payer account and a payment requirement corresponding to the payee account;

[0090] The specific process is as described above and will not be repeated here.

[0091] In some embodiments, the payment requirement includes at least one of a payment requirement corresponding to a payer account and a payment requirement corresponding to a payee account. The payment requirement corresponding to the payer account may, for example, be a payment range associated with the payer account. The payment requirement corresponding to the payer account may, for example, judge the payment data of the payer account to improve the security of payment or the accuracy of asset management. The payment requirement corresponding to the payer account does not specifically refer to a fixed requirement. For example, when the payment data range corresponding to the payment requirement changes, the payment requirement corresponding to the payer account may also change accordingly. For example, when a modification instruction for the payment requirement corresponding to the payer account is received, the payment requirement corresponding to the payer account may also change accordingly. The payment requirement corresponding to the payee account may, for example, be a payment range associated with the payee account.

[0092] In some embodiments, when a payment request is received from a payer account, a payment requirement corresponding to the payment request may be obtained.

[0093] In step S22, when the payment data in the payment request does not meet the payment requirements, a payment-related data set of the payer's account and a payment-related data set of the payee's account corresponding to the payment request are obtained;

[0094] The specific process is as described above and will not be repeated here.

[0095] In some embodiments, the payment data may be, for example, data included in a payment request. The payment data does not specifically refer to a fixed data. The payment data may, for example, include the transaction flow information corresponding to the product in the payment request. The payment data may also include, for example, the time point of order generation and the time point of payment request sending, which is not limited in the embodiments of the present disclosure. The payment data does not specifically refer to a fixed data. For example, when the payment time point corresponding to the payment data changes, the payment data may also change accordingly. For example, when the payment request changes, the payment data may also change accordingly.

[0096] In some embodiments, when a payment requirement is obtained, for example, it can be determined whether the payment data meets the payment requirement. When the payment requirement is a payment range, it can be determined whether the payment data falls within the payment range. When the payment data exceeds the payment range, the payment-related data set of the payer account and the payment-related data set of the payee account corresponding to the payment request can be obtained. Among them, which payment requirement is compared needs to be determined according to the number of factors required for risk identification.

[0097] In some embodiments, the payer account may be, for example, a payment account logged in on mobile phone A, and the payee account may be, for example, a payment account logged in on the payment device of merchant B. The method for generating the payment request is not limited. For example, the payment QR code displayed by merchant B is scanned by mobile phone A. For example, merchant B may scan the payment QR code displayed by mobile phone A. The disclosed embodiments do not limit this.

[0098] According to some embodiments, for example, a payment request may be generated by scanning a payment QR code displayed by merchant B through mobile phone A. The payment requirement may be determined, for example, based on the historical payment data of the payer's account. For example, when the payment data of mobile phone A within a month are all within the range of 80-100 yuan, the payment requirement corresponding to the payer's account may be, for example, that the payment data is less than 100 yuan. When the payment data included in the payment request sent by mobile phone A is 900 yuan, since 900 yuan is greater than 100 yuan, it is determined that the payment data does not meet the payment requirement corresponding to the payer's account.

[0099] According to some embodiments, for example, a payment request can be generated by scanning the payment QR code displayed by merchant B through mobile phone A. The payment requirement can be determined, for example, based on the historical payment data of the payer's account. For example, when the payment data of mobile phone A within a month are all within the range of 800-1000 yuan, and the payment requirement corresponding to the payer's account is 900 yuan, the requirement of payment data of 800-1000 yuan can be met, but the payee account has a corresponding payment requirement, for example, payment data of 0-200 yuan can be accepted. When the payment data included in the payment request sent by mobile phone A is 800 yuan, since 800 yuan is greater than 200 yuan, it is determined that the payment data does not meet the payment requirement corresponding to the payee account.

[0100] According to some embodiments, the method further comprises:

[0101] Obtain a historical payment data set corresponding to the payer account, a historical payment data set corresponding to the payee account, and a payment completion data set within a historical period, wherein the payment completion data set includes payment completion data in the historical payment data set corresponding to the payer account and payment completion data in the historical payment data set corresponding to the payee account;

[0102] Get historical account information;

[0103] According to the connectivity between the historical payment data set corresponding to the payer's account, the historical payment data set corresponding to the payee's account, and the payment completion data set, as well as the historical account information, the target risk association model is trained, wherein the target risk association model is a multi-factor risk association model. Therefore, the payment data of the payer's account and the payee's account can be distinguished, so that different factors appear discretely, reducing the situation where one-time appearance makes data acquisition inaccurate, which can improve the consistency, relevance and integrity of the data, improve the accuracy of multi-factor association risk model training, and improve the security of data when using the risk association model. In addition, the data can be classified and data from different data domains can be obtained, which can improve the accuracy and pertinence of model training, improve the effectiveness and precision of risk identification, and make the data self-learning and classifiable.

[0104] According to some embodiments, the method further comprises:

[0105] Processing the historical payment data set corresponding to the payer account, the historical payment data set corresponding to the payee account, and the payment completion data set to obtain a processed historical payment data set corresponding to the payer account, a processed historical payment data set corresponding to the payee account, and a processed payment completion data set;

[0106] Obtain the category information corresponding to each of the processed historical payment data set corresponding to the payer account, the processed historical payment data set corresponding to the payee account, and the processed payment completion data set;

[0107] Obtaining a Gini index corresponding to an initial risk association model according to the category information and a processed historical payment data set corresponding to the payer account, a processed historical payment data set corresponding to the payee account, and a processed payment completion data set, wherein the initial risk association model includes at least two factors;

[0108] When the Gini index meets the index requirements, it is determined that the target risk association model is obtained. Therefore, obtaining the target risk association model through Gini training can improve the accuracy of obtaining the risk association model.

[0109] Among them, in some embodiments, for example, the historical payment data set can be processed, and specifically, for example, it can be desensitized. Among them, the historical payment data set can be modified, for example, the current payment data can be added to the historical payment data set, the historical payment data set can be filled, the accuracy of the historical payment data set acquisition can be improved, the accuracy of the risk association model acquisition can be improved, the risk association model can be improved, and the security of payment can be improved.

[0110] In some embodiments, the Gini formula may be, for example, as shown in formula (1):

[0111] (1)

[0112] Among them, G(p) is the Gini value, p is the gap value; k is the number of categories;

[0113] According to some embodiments, the historical payment data set may include two categories, for example, payer and payee. For any training subset in the historical payment data set, the training subset may include k categories, and the kth category corresponds to C k Samples, to obtain the Gini index D corresponding to the initial risk association model, for example, can be expressed as formula (2):

[0114] (2)

[0115] Among them, G(D) is the Gini coefficient and k is the number of categories.

[0116] In some embodiments, the risk association model can be trained based on one factor, or multiple factors. The more factors there are, the higher the accuracy of the acquired risk association model, the higher the accuracy of the payment risk information, and the higher the security of the payment.

[0117] In step S23, the payment scenario information corresponding to the payment request is obtained;

[0118] The specific process is as described above and will not be repeated here.

[0119] According to some embodiments, the payment scenario information may be used to indicate the payment scenario corresponding to the current payment request. Specifically, for example, the product type of the product corresponding to the payment request may be included. For example, the geographical location information corresponding to the payment request may also be included. For example, the current environment information of the payer's account may also be included. This disclosure embodiment does not limit this.

[0120] In some embodiments, for example, payment scenario information corresponding to the payment request may be obtained.

[0121] In step S24, a target risk association model corresponding to the payment scenario information is obtained, wherein the target risk association model includes a risk association model corresponding to one factor or a risk association model corresponding to multiple factors, and different factors in the risk association model corresponding to multiple factors correspond to different weights;

[0122] In some embodiments, the risk association model used in the embodiments of the present disclosure may be preset, for example, or may be determined based on payment scenario information.

[0123] Among them, the payment scenario can be online payment or offline payment, or it can be shopping, living expenses, travel, entertainment ticketing, transfer services and other corresponding risk association models, which are not limited in the embodiments of the present disclosure.

[0124] Different factors in the risk association model corresponding to the multiple factors correspond to different weights. The multiple factors may include payment data and payment methods, for example. The first weight corresponding to the payment data is 0.7, and the second weight corresponding to the payment method is 0.3.

[0125] In step S25, the target risk association model is used to identify the risk of the payment-related data set of the payer's account and / or the payment-related data set of the payee's account, and the payment risk information corresponding to the payment request is obtained;

[0126] The specific process is as described above and will not be repeated here.

[0127] According to some embodiments, risk identification is performed on a payment-related data set of a payer's account and / or a payment-related data set of a payee's account using a target risk association model to obtain payment risk information corresponding to a payment request, including:

[0128] Using a target risk association model to identify risks of account data in a payment-related data set of a payer's account and account data in a payment-related data set of a payee's account, and obtaining a security level of the account data of the payee's account;

[0129] In a case where the security level of the account data of the payee's account indicates that the security level of the payee's account is a preset security level account, determining the payment risk information as payable information, wherein the payable information is used to indicate that a payment method corresponding to the payment risk information is used to perform a payment operation corresponding to the payment request;

[0130] or,

[0131] When the security level of the account data of the payee account indicates that the security level of the payee account is a preset unsafe level account, the payment risk information is determined to be unpayable information, wherein the unpayable information is used to instruct to stop executing the payment operation corresponding to the payment request.

[0132] In some embodiments, for example, when the payee account is a blacklist account, the security level of the account data of the payee account obtained by using the target risk association model may be, for example, level 5, where level 5 is the lowest security level among the set levels. The payment risk information corresponding to the payment request may be, for example, non-payable information, that is, no matter how much payment data the payee account pays or what payment verification method is used for payment, the payment operation corresponding to the payment request is stopped.

[0133] In some embodiments, for example, when the payee account is a preset security account, the security level of the account data of the payee account obtained by using the target risk association model can be, for example, level 1, where level 1 is the highest security level among the set levels. The payment risk information corresponding to the payment request can be, for example, payable information, that is, no matter how much payment data the payee account pays, the payment operation corresponding to the payment request can be executed. When making a payment, a corresponding payment verification method can be used, or direct payment can be made without using any payment verification method.

[0134] According to some embodiments, the payment requirement includes a payment requirement corresponding to a payer account, and a target risk association model is used to perform risk identification on a payment-related data set of the payer account and a payment-related data set of the payee account, and payment risk information corresponding to the payment request is obtained, including:

[0135] According to the historical payment data set corresponding to the payer account, the target risk association model is used to obtain the standard deviation and mean corresponding to the payer account;

[0136] According to the standard deviation and the mean, the payment requirement corresponding to the payer's account is adjusted to obtain the adjusted first payment sub-requirement. Therefore, the payment sub-requirement is dynamically adjusted according to the historical payment data, that is, the payment requirement can be dynamically adjusted to improve the accuracy of the payment requirement determination and the accuracy of the payment.

[0137] According to some embodiments, for example, the historical payment data of the payer account Q is [440, 480, 520, 600, 750] yuan, and the corresponding mean of the payer account Q is calculated to be μ=(440+480+520+600+750) / 5=558, and the standard deviation is σ==109.62. When the historical payment data of the payer account Q satisfies the normal distribution, the payment requirement of the payer account Q can be obtained, for example, it can be (μ-3σ, μ+3σ).

[0138] Among them, when there is only one factor, the historical payment data set satisfies the one-dimensional normal distribution:

[0139] (3)

[0140] Among them, x is the factor, μ is the mathematical expectation, is the variance;

[0141] For example, when the payment data of the payer account Q is within (μ-3σ, μ+3σ), the acquired payment risk information may, for example, indicate that payment is to be made in accordance with the payment verification method.

[0142] According to some embodiments, for example, if the next payment data of the payer account Q is between 558-3x109.62 and 558+3x109.62, that is, between 229.14 yuan and 886.86 yuan, the payment risk information obtained can, for example, indicate that payment is to be made in accordance with the payment verification method. For example, if the next payment data of the payer account Q is not between 558-3x109.62 and 558+3x109.62, that is, not between 229.14 yuan and 886.86 yuan, the payment risk information obtained can, for example, indicate that risk control is required for this payment.

[0143] According to some embodiments, for example, the historical payment data of the payee account W is [800, 900, 1000, 1100, 1200] yuan, and the mean corresponding to the payee account W is calculated to be μ=(800+900+1000+1100+1200) / 5=1000, and the standard deviation is σ=141.42. When the historical payment data of the payee account W satisfies the normal distribution, the payment requirement of the payee account W can be obtained, for example, (μ-3σ, μ+3σ). The payment data received by the payee account W is within (μ-3σ, μ+3σ) for safe collection.

[0144] According to some embodiments, risk identification is performed on a payment-related data set of a payer's account and / or a payment-related data set of a payee's account using a target risk association model to obtain payment risk information corresponding to a payment request, including:

[0145] When the account data of the payer account and the account data of the payee account determined by the target risk association model are not the preset account data, obtaining the payment requirement corresponding to the payment request, wherein the payment requirement includes the payment requirement corresponding to the payer account and the payment requirement corresponding to the payee account;

[0146] According to the historical payment data set corresponding to the payer's account and the historical payment data set corresponding to the payee's account, the target risk association model is used to adjust the payment requirement to obtain the adjusted payment requirement;

[0147] The target risk association model is used to identify risks of the adjusted payment requirements and payment data, and obtain payment risk information corresponding to the payment request.

[0148] Among them, when there are two factors, the historical payment data set satisfies the two-dimensional normal distribution:

[0149] (4)

[0150] Among them, x and y are factors, μ1 is the mathematical expectation corresponding to x, and μ2 is the mathematical expectation corresponding to y. is the variance, is the variance.

[0151] Based on the above, when the next payment data of the payer account Q is sent to the payee account W, the historical payment data of the payer account Q and the historical payment data of the payee account W can be identified, and the payment requirement when the payer account Q makes payment to the payee account W can be obtained, which can be, for example, a payment range.

[0152] In step S26, the payment method corresponding to the payment risk information is used to execute the payment operation corresponding to the payment request.

[0153] The specific process is as described above and will not be repeated here.

[0154] According to some embodiments, using a payment method corresponding to the payment risk information to perform a payment operation corresponding to the payment request, performing the payment operation corresponding to the payment request includes:

[0155] When the account data of the payer's account and the account data of the payee's account determined by the target risk association model are not the preset account data, obtaining a payment verification method corresponding to the payment risk information, wherein different payment risk information corresponds to payment verification methods of different complexity;

[0156] Using payment verification method to verify payment data;

[0157] After the payment verification is passed and the payment data is within the payment data range corresponding to the adjusted payment request, the payment operation corresponding to the payment request is completed. Therefore, the matching between the risk payment information and the payment verification method can be improved, and the security and convenience of payment can be improved. Among them, the lower the risk range information, the higher the complexity of the corresponding payment verification method, that is, the more complex the number of payment verification methods.

[0158] According to some embodiments, the payment verification method may be, for example, a verification method when making a payment, which may include, for example, a password verification method, a verification code verification method, a fingerprint verification method, a voiceprint verification method, a facial verification method, a voice verification method, a follow-up verification method, etc.

[0159] The payment verification method may include, for example, at least one payment verification method. The payment verification method does not specifically refer to a fixed method. For example, when the number of verification methods included in the payment verification method changes, the payment verification method may also change accordingly.

[0160] In some embodiments, for example, when the payment verification method is a voiceprint verification method, the voiceprint verification method and the adjusted payment requirements can be used to perform payment verification on the payment data to complete the payment operation for the payment request.

[0161] According to some embodiments, where the payment requirement includes a payment threshold and the payment data in the payment request is greater than the payment threshold, the payment requirement can be adjusted using the payment risk information, the adjusted payment requirement is obtained, and the payment operation for the payment request is completed based on the adjusted payment requirement and the payment data. Specifically, it may include:

[0162] Use payment risk information to adjust payment requirements and obtain adjusted payment requirements;

[0163] When the payment risk information indicates that the risk information corresponding to the payment data is less than the risk threshold, the payment operation for the payment request is completed.

[0164] In which, when it is determined to stop the payment operation related to the payment request based on the payment risk information and payment data, a prompt message can be issued to prompt the change of delivery data or cancellation of payment or payment using a secured transaction method.

[0165] According to some embodiments, when receiving a payment request from a payer account, the payment requirement corresponding to the payment request is obtained, wherein the payment requirement includes at least one of the payment requirement corresponding to the payer account and the payment requirement corresponding to the payee account; when the payment data in the payment request does not meet the payment requirement, the payment-related data set of the payer account corresponding to the payment request and the payment-related data set of the payee account are obtained; the convenience of payment risk identification and the security of payment operation can be improved. Secondly, the payment scenario information corresponding to the payment request is obtained; the target risk association model corresponding to the payment scenario information is obtained, wherein the target risk association model includes a risk association model corresponding to one factor or a risk association model corresponding to multiple factors, and different factors in the risk association model corresponding to multiple factors correspond to different weights, and the risk association model can be used to control the payment process and ensure security, wherein the risk association model can identify risks from different factors, which can enhance security identification risks, and the multi-factor data model can accurately analyze the data, reduce the total amount of analyzed data, and improve the matching degree of the data, thereby improving the efficiency of the system. Therefore, the payment data can be processed separately by factors, which can reduce the time wasted by invalid comparison and improve payment efficiency. Secondly, the first payment verification method is used to verify the payment data and complete the payment operation for the payment request, which can improve the matching of the payment verification method and the payment risk information and improve the security of the payment.

[0166] Figure 3 is a block diagram of a payment device based on a risk association model according to an exemplary embodiment. Figure 3 The payment device 300 based on the risk association model includes:

[0167] The data acquisition unit 301 is used to acquire, upon receiving a payment request, a payment-related data set of a payer's account and a payment-related data set of a payee's account corresponding to the payment request;

[0168] An information acquisition unit 302 is used to identify risks of a payment-related data set of a payer's account and / or a payment-related data set of a payee's account using a target risk association model, and acquire payment risk information corresponding to the payment request;

[0169] The payment operation unit 303 is used to use the payment method corresponding to the payment risk information to perform the payment operation corresponding to the payment request.

[0170] According to some embodiments, the data acquisition unit 301 is used to acquire a payment-related data set of a payer account and a payment-related data set of a payee account corresponding to a payment request, specifically to:

[0171] Obtaining a payment requirement corresponding to the payment request, wherein the payment requirement includes at least one of a payment requirement corresponding to a payer account and a payment requirement corresponding to a payee account;

[0172] When the payment data in the payment request does not meet the payment requirements, a payment-related data set of the payer's account and a payment-related data set of the payee's account corresponding to the payment request are obtained.

[0173] According to some embodiments, the information acquisition unit 302 is used to identify risks of the payment-related data set of the payer's account and / or the payment-related data set of the payee's account using the target risk association model, and when acquiring payment risk information corresponding to the payment request, specifically:

[0174] When the account data of the payer account and the account data of the payee account determined by the target risk association model are not the preset account data, obtaining the payment requirement corresponding to the payment request, wherein the payment requirement includes the payment requirement corresponding to the payer account and the payment requirement corresponding to the payee account;

[0175] According to the historical payment data set corresponding to the payer's account and the historical payment data set corresponding to the payee's account, the target risk association model is used to adjust the payment requirement to obtain the adjusted payment requirement;

[0176] The target risk association model is used to identify risks of the adjusted payment requirements and payment data, and obtain payment risk information corresponding to the payment request.

[0177] According to some embodiments, the payment requirement includes a payment requirement corresponding to a payer account, and the information acquisition unit 302 is used to identify risks of a payment-related data set of the payer account using a target risk association model, and when acquiring payment risk information corresponding to the payment request, specifically:

[0178] According to the historical payment data set corresponding to the payer account, the target risk association model is used to obtain the standard deviation and mean corresponding to the payer account;

[0179] The payment requirement corresponding to the payee account is adjusted according to the standard deviation and the mean to obtain the adjusted payment requirement corresponding to the payee account.

[0180] According to some embodiments, the payment operation unit 303 is used to use the payment means corresponding to the payment risk information to perform the payment operation corresponding to the payment request, and when performing the payment operation corresponding to the payment request, specifically to:

[0181] When the account data of the payer's account and the account data of the payee's account determined by the target risk association model are not the preset account data, obtaining a payment verification method corresponding to the payment risk information, wherein different payment risk information corresponds to payment verification methods of different complexity;

[0182] Using payment verification method to verify payment data;

[0183] After the payment verification is passed and the payment data is within the payment data range corresponding to the adjusted payment request, the payment operation corresponding to the payment request is completed.

[0184] According to some embodiments, the information acquisition unit 302 is used to identify risks of the payment-related data set of the payer's account and / or the payment-related data set of the payee's account using the target risk association model, and when acquiring payment risk information corresponding to the payment request, specifically:

[0185] Using a target risk association model to identify risks of account data in a payment-related data set of a payer's account and account data in a payment-related data set of a payee's account, and obtaining a security level of the account data of the payee's account;

[0186] In a case where the security level of the account data of the payee's account indicates that the security level of the payee's account is a preset security level account, determining the payment risk information as payable information, wherein the payable information is used to indicate that a payment method corresponding to the payment risk information is used to perform a payment operation corresponding to the payment request;

[0187] or,

[0188] When the security level of the account data of the payee account indicates that the security level of the payee account is a preset unsafe level account, the payment risk information is determined to be unpayable information, wherein the unpayable information is used to instruct to stop executing the payment operation corresponding to the payment request.

[0189] According to some embodiments, the information acquisition unit 302 is further configured to:

[0190] Obtain a historical payment data set corresponding to the payer account, a historical payment data set corresponding to the payee account, and a payment completion data set within a historical period, wherein the payment completion data set includes payment completion data in the historical payment data set corresponding to the payer account and payment completion data in the historical payment data set corresponding to the payee account;

[0191] Get historical account information;

[0192] According to the connectivity relationship among the historical payment data set corresponding to the payer's account, the historical payment data set corresponding to the payee's account and the payment completion data set as well as the historical account information, a target risk association model is trained, wherein the target risk association model is a multi-factor risk association model.

[0193] According to some embodiments, the information acquisition unit 302 is further configured to:

[0194] Processing the historical payment data set corresponding to the payer account, the historical payment data set corresponding to the payee account, and the payment completion data set to obtain a processed historical payment data set corresponding to the payer account, a processed historical payment data set corresponding to the payee account, and a processed payment completion data set;

[0195] Obtain the category information corresponding to each of the processed historical payment data set corresponding to the payer account, the processed historical payment data set corresponding to the payee account, and the processed payment completion data set;

[0196] Obtaining a Gini index corresponding to an initial risk association model according to the category information and a processed historical payment data set corresponding to the payer account, a processed historical payment data set corresponding to the payee account, and a processed payment completion data set, wherein the initial risk association model includes at least two factors;

[0197] When the Gini index meets the index requirements, it is determined that the target risk association model is obtained.

[0198] According to some embodiments, the information acquisition unit 302 is further configured to:

[0199] Get the payment scenario information corresponding to the payment request;

[0200] A target risk association model corresponding to the payment scenario information is obtained, wherein the target risk association model includes a risk association model corresponding to one factor or a risk association model corresponding to multiple factors, and different factors in the risk association model corresponding to multiple factors correspond to different weights.

[0201] Regarding the device in the above embodiment, the specific manner in which each module performs operations has been described in detail in the embodiment of the method, and will not be elaborated here.

[0202] In some or related embodiments, a data acquisition unit is used to obtain the payment-related data set of the payer's account and the payment-related data set of the payee's account corresponding to the payment request when a payment request is received; an information acquisition unit is used to identify the risk of the payment-related data set of the payer's account and / or the payment-related data set of the payee's account using a target risk association model, and obtain the payment risk information corresponding to the payment request; a payment operation unit is used to use the payment means corresponding to the payment risk information to perform the payment operation corresponding to the payment request. Thus, the present disclosure can judge the payment-related data sets of the two payment parties, dynamically adjust the payment restrictions, dynamically control the payment process, and reduce the situation where static control makes the payment convenience poor, and the associated risk model can identify the payment data, improve the accuracy of data analysis, improve the accuracy of payment risk information acquisition, improve the flexibility of payment control, and improve the convenience and security of payment.

[0203] In order to implement the above embodiments, the present disclosure also proposes a computer storage medium.

[0204] The computer storage medium provided in the embodiment of the present disclosure stores an executable program; after the executable program is executed by the processor, the following can be achieved: Figure 1 to Figure 2 Any of the methods shown.

[0205] In order to implement the above embodiments, the present disclosure also provides a computer device.

[0206] The computer device provided in the embodiment of the present disclosure includes a memory, a processor, and a computer program stored in the memory and executable on the processor; when the processor executes the program, the following can be achieved: Figure 1 to Figure 2 Any of the methods shown.

[0207] Figure 4 4 is a block diagram of a network system 400 provided in an embodiment of the present disclosure. Figure 4 The network system 400 includes a processing component 422, which further includes at least one processor, and a memory resource represented by a memory 432 for storing instructions executable by the processing component 422, such as an application. The application stored in the memory 432 may include one or more modules, each corresponding to a set of instructions. In addition, the processing component 422 is configured to execute instructions to perform any of the methods described above in the network system.

[0208] The network system 400 may also include a power supply component 426 configured to perform power management of the network system 400, a wired or wireless network interface 450 configured to connect the network system 400 to a network, and an input / output (I / O) interface 458. The network system 400 may operate based on an operating system stored in the memory 432, such as Windows Server TM, Mac OS X TM, Unix TM, Linux TM, Free BSD TM or the like.

[0209] In the description of this specification, the description with reference to the terms "one embodiment", "some embodiments", "example", "specific example", or "some examples" etc. means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present application. In this specification, the schematic representations of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described may be combined in any one or more embodiments or examples in a suitable manner. In addition, those skilled in the art may combine and combine the different embodiments or examples described in this specification and the features of the different embodiments or examples, without contradiction.

[0210] Any process or method description in a flowchart or otherwise described herein may be understood to represent a module, fragment or portion of code comprising one or more executable instructions for implementing the steps of a custom logical function or process, and the scope of the preferred embodiments of the present application includes alternative implementations in which functions may not be performed in the order shown or discussed, including performing functions in a substantially simultaneous manner or in the reverse order depending on the functions involved, which should be understood by technicians in the technical field to which the embodiments of the present application belong.

[0211] Although the embodiments of the present application have been shown and described above, it can be understood that the above embodiments are exemplary and cannot be understood as limitations on the present application. Ordinary technicians in this field can change, modify, replace and modify the above embodiments within the scope of the present application.

Claims

1. A payment method based on a risk association model, characterized in that: include: When receiving a payment request, obtaining payment requirements and payment scenario information corresponding to the payment request, wherein the payment requirements include payment requirements corresponding to the payer account and payment requirements corresponding to the payee account; If the payment data in the payment request does not meet the payment requirement, obtaining a payment-related data set of a payer account and a payment-related data set of a payee account corresponding to the payment request; According to a historical payment data set corresponding to the payer's account and a historical payment data set corresponding to the payee's account, the payment requirement is adjusted using a target risk association model corresponding to the payment scenario information to obtain an adjusted payment requirement; Using the target risk association model to identify risks of the adjusted payment requirements and payment data, and obtaining payment risk information corresponding to the payment request; Obtaining a payment verification method corresponding to the payment risk information, wherein different payment risk information corresponds to payment verification methods of different complexity; Performing payment verification on the payment data using the payment verification method; When the payment verification is passed and the payment data is within the payment data range corresponding to the adjusted payment request, the payment operation corresponding to the payment request is completed.

2. The method according to claim 1, characterized in that: in, The payment requirement is adjusted using a target risk association model corresponding to the payment scenario information to obtain an adjusted payment requirement, including: According to the historical payment data set corresponding to the payer account, a target risk association model is used to obtain the standard deviation and mean corresponding to the payer account; The payment requirement corresponding to the payer account is adjusted according to the standard deviation and the mean to obtain the payment requirement corresponding to the payer account after adjustment.

3. The method according to claim 1, characterized in that: The adopting the target risk association model to perform risk identification on the adjusted payment requirements and payment data to obtain payment risk information corresponding to the payment request includes: Using a target risk association model to identify the risks of the account data in the payment-related data set of the payer's account and the account data in the payment-related data set of the payee's account, and obtaining the security level of the account data of the payee's account; In a case where the security level of the account data of the payee account indicates that the security level of the payee account is a preset security level account, determining that the payment risk information is payable information, wherein the payable information is used to indicate that a payment method corresponding to the payment risk information is used to perform a payment operation corresponding to the payment request; or, When the security level of the account data of the payee account indicates that the security level of the payee account is a preset unsafe level account, the payment risk information is determined to be unpayable information, wherein the unpayable information is used to instruct to stop executing the payment operation corresponding to the payment request.

4. The method according to claim 1, characterized in that: The method further comprises: Obtain a historical payment data set corresponding to the payer account, a historical payment data set corresponding to the payee account, and a payment completion data set within a historical time period, wherein the payment completion data set includes payment completion data in the historical payment data set corresponding to the payer account and payment completion data in the historical payment data set corresponding to the payee account; Get historical account information; The target risk association model is trained based on the connectivity relationship between the historical payment data set corresponding to the payer account, the historical payment data set corresponding to the payee account and the payment completion data set, as well as the historical account information, wherein the target risk association model is a multi-factor risk association model.

5. The method according to claim 4, characterized in that The method further comprises: Processing the historical payment data set corresponding to the payer account, the historical payment data set corresponding to the payee account, and the payment completion data set to obtain a processed historical payment data set corresponding to the payer account, a processed historical payment data set corresponding to the payee account, and a processed payment completion data set; Obtaining the category information corresponding to each of the processed historical payment data set corresponding to the payer account, the processed historical payment data set corresponding to the payee account, and the processed payment completion data set; Obtaining a Gini index corresponding to an initial risk association model according to the category information and the processed historical payment data set corresponding to the payer account, the processed historical payment data set corresponding to the payee account, and the processed payment completion data set, wherein the initial risk association model includes at least two factors; When the Gini index meets the index requirement, it is determined that the target risk association model is obtained.

6. The method according to claim 1, characterized in that The target risk association model includes a risk association model corresponding to one factor or a risk association model corresponding to multiple factors, and different factors in the risk association model corresponding to multiple factors correspond to different weights.

7. A payment device based on a risk association model, characterized in that: include: a data acquisition unit, configured to, upon receiving a payment request, acquire payment requirements and payment scenario information corresponding to the payment request, wherein the payment requirements include payment requirements corresponding to a payer account and payment requirements corresponding to a payee account; and, if the payment data in the payment request does not meet the payment requirements, acquire a payment-related data set of the payer account and a payment-related data set of the payee account corresponding to the payment request; An information acquisition unit, configured to adjust the payment requirement according to a historical payment data set corresponding to the payer's account and a historical payment data set corresponding to the payee's account, using a target risk association model corresponding to the payment scenario information, and obtain the adjusted payment requirement; perform risk identification on the adjusted payment requirement and payment data using the target risk association model, and obtain payment risk information corresponding to the payment request; A payment operation unit is used to obtain a payment verification method corresponding to the payment risk information, wherein different payment risk information corresponds to payment verification methods of different complexity; use the payment verification method to perform payment verification on the payment data; when the payment verification is passed and the payment data is within the payment data range corresponding to the adjusted payment requirement, complete the payment operation corresponding to the payment request.

8. A network system, characterized in that: include: at least one processor; as well as A memory in communication connection with the at least one processor, wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor so that the at least one processor can execute the method of any one of claims 1-6.

9. A non-transitory computer-readable storage medium storing computer-executable instructions; after the computer-executable instructions are executed by a processor, the method according to any one of claims 1 to 6 can be implemented.

Images