阅读说明：本技术 一种安全业务交易方法、装置及电子设备 (Security business transaction method and device and electronic equipment ) 是由 徐彬彬 覃桃 李典 于 2020-04-24 设计创作，主要内容包括：本说明书实施例公开了一种安全业务交易方法、装置及电子设备,在该方法中,获取账户业务请求,并利用第一风控模型来判断账户业务请求所对应的账户是否存在目标类风险,由关于目标类风险的判断结果来确定针对账户业务请求是执行预付费交易模式还是先享后付费交易模式,可以降低类似NSF模式下的综合风险情况。(The embodiment of the specification discloses a secure service transaction method, a secure service transaction device and electronic equipment.)

1. A secure business transaction method, comprising:

acquiring an account service request;

judging whether the account corresponding to the account service request has target risk or not based on a first wind control model;

and determining whether to execute a prepaid transaction mode or a share-before-pay transaction mode for the account service request according to the judgment result about the target class risk.

2. The secure transaction method of claim 1, further comprising:

when determining that a prepaid transaction mode is executed for the account service request, judging whether the account service request has a payment risk based on a second wind control model;

and determining whether to execute the payment operation aiming at the account service request according to the judgment result of the payment risk.

3. The secure transaction method according to claim 2, wherein determining whether to execute a payment operation for the account service request according to the determination result about the payment risk specifically includes:

if the judgment result indicates that the payment risk exists, refusing to execute the payment operation aiming at the account service request; and

and if the judgment result indicates that no payment risk exists, executing the payment operation aiming at the account service request.

4. The secure business transaction method of claim 2, wherein the payment risk comprises a credit card cross-border cash-out risk, and the feature dimensions of the second wind control model comprise: the account attribution country identification information, the payment card attribution country identification information, the account binding information, the payment card binding account information, the account historical transaction information and the payment card historical transaction information.

5. A secure transaction method as defined in claim 1, wherein determining whether to execute a prepaid transaction mode or a pay-first-share-after-payment transaction mode for the account service request based on the determination of the target class risk comprises:

if the judgment result indicates that the target risk exists, executing a prepaid transaction mode aiming at the account service request; and

and if the judgment result indicates that the target risk does not exist, executing a share-before-pay transaction mode aiming at the account service request.

6. The secure transaction method of claim 1, further comprising:

acquiring historical transaction data sets generated by a plurality of accounts in a set time period;

determining transaction wind control evaluation indexes based on the historical transaction data set, wherein the transaction wind control evaluation indexes comprise a bad bill deduction rate, a prepaid order proportion and a wind control transaction failure rate;

and determining whether to execute optimization operation on the first wind control model and/or the second wind control model based on the transaction wind control evaluation index.

7. The secure transaction method according to claim 6, wherein determining whether to perform an optimization operation on the first and/or second wind control models based on the transaction wind control evaluation index specifically includes:

determining whether to adjust the feature dimension and the risk threshold of the first wind control model and/or the second wind control model based on the transaction wind control evaluation index; and/or

Determining whether to train the first and/or second wind control models with the historical set of transaction data based on the transaction wind control evaluation indicator.

8. The security business transaction method of claim 6, wherein determining a transaction wind control evaluation index based on the historical transaction data set specifically comprises:

and determining a transaction wind control evaluation index based on a preset transaction noise factor and the historical transaction data set.

9. The secure transaction method of claim 1, wherein the feature dimensions of the first wind control model comprise: the method comprises the following steps of account historical payment records, account historical transaction modes, account asset information, account age information, account binding information, account registration information and account security authentication results.

10. A secure transaction method as claimed in any one of claims 1 to 9, wherein said account service request includes an account service request for a travel class service.

11. A secure business transaction method, comprising:

acquiring an account service request corresponding to a first-share-then-pay transaction mode;

judging whether the account corresponding to the account service request has target risk or not based on a first wind control model;

determining whether a transaction mode corresponding to the account service request is converted into a prepaid transaction mode according to the judgment result about the target risk;

when the transaction mode corresponding to the account service request is converted into a prepaid transaction mode, whether the account service request has payment risks or not is judged based on a second wind control model;

and determining whether to execute the payment operation aiming at the account service request according to the judgment result of the payment risk.

12. A secure transaction apparatus, comprising:

the service request acquisition unit is used for acquiring an account service request;

the first wind control unit is used for judging whether the account corresponding to the account service request has a target risk or not based on a first wind control model;

and the transaction mode determining unit is used for determining whether a prepaid transaction mode or a share-first-then-pay transaction mode is executed aiming at the account service request according to the judgment result about the target risk.

13. The secure transaction apparatus of claim 12, further comprising:

the second wind control unit is used for judging whether the account service request has payment risks or not based on a second wind control model when the prepaid transaction mode is determined to be executed aiming at the account service request;

and the payment operation execution unit determines whether to execute the payment operation aiming at the account service request according to the judgment result of the payment risk.

14. The secure transaction apparatus of claim 13, wherein the payment operation performing unit:

if the judgment result indicates that the payment risk exists, refusing to execute the payment operation aiming at the account service request; and

and if the judgment result indicates that no payment risk exists, executing the payment operation aiming at the account service request.

15. The secure business transaction apparatus of claim 13, wherein the payment risk comprises a credit card cross-border cash-out risk, and the feature dimensions of the second wind control model comprise: the account attribution country identification information, the payment card attribution country identification information, the account binding information, the payment card binding account information, the account historical transaction information and the payment card historical transaction information.

16. The secure transaction apparatus of claim 12, wherein the transaction mode determination unit:

if the judgment result indicates that the target risk exists, executing a prepaid transaction mode aiming at the account service request; and

and if the judgment result indicates that the target risk does not exist, executing a share-before-pay transaction mode aiming at the account service request.

17. The secure transaction apparatus of claim 12, further comprising:

the historical transaction data acquisition unit is used for acquiring historical transaction data sets generated by a plurality of accounts in a set time period;

the transaction wind control evaluation index determining unit determines a transaction wind control evaluation index based on the historical transaction data set, wherein the transaction wind control evaluation index comprises a bad account withholding rate, a prepaid order proportion and a wind control transaction failure rate;

and the wind control model optimization unit determines whether to execute optimization operation on the first wind control model and/or the second wind control model based on the transaction wind control evaluation index.

18. The secure transaction apparatus of claim 17, wherein the wind control model optimization unit comprises a wind control model parameter adjustment module and/or a wind control model training module,

the wind control model parameter adjusting module determines whether to adjust the characteristic dimension and the risk threshold of the first wind control model and/or the second wind control model based on the transaction wind control evaluation index; and

the wind control model training module determines whether to train the first wind control model and/or the second wind control model using the historical transaction data set based on the transaction wind control evaluation index.

19. The secure transaction device of claim 17, wherein the transaction wind control evaluation index determination unit further determines the transaction wind control evaluation index based on a preset transaction noise factor and the historical transaction data set.

20. The secure transaction apparatus of claim 12, wherein the feature dimensions of the first wind control model comprise: the method comprises the following steps of account historical payment records, account historical transaction modes, account asset information, account age information, account binding information, account registration information and account security authentication results.

21. A secure transaction apparatus according to any of claims 12 to 20, wherein the account service request comprises an account service request for a travel class service.

22. A secure transaction apparatus, comprising:

the NSF service request acquisition unit is used for acquiring an account service request corresponding to a first-share-then-pay transaction mode;

the first wind control unit is used for judging whether the account corresponding to the account service request has a target risk or not based on a first wind control model;

the transaction mode conversion unit is used for determining whether the transaction mode corresponding to the account service request is converted into a prepaid transaction mode according to the judgment result about the target risk;

the second wind control unit is used for judging whether the account service request has payment risk or not based on a second wind control model when the transaction mode corresponding to the account service request is converted into a prepaid transaction mode;

and the payment operation execution unit determines whether to execute the payment operation aiming at the account service request according to the judgment result of the payment risk.

23. An electronic device, comprising:

at least one processor; and

a memory storing instructions that, when executed by the at least one processor, cause the at least one processor to perform the method of any of claims 1 to 11.

Technical Field

The embodiment of the specification relates to the technical field of computers, in particular to a secure service transaction method and device and electronic equipment.

Background

Non-social function (NSF) is a payment mode for improving user service experience and convenience, and is characterized in that a user can enjoy service first and then deduct corresponding money.

Currently, in NSF mode, transactions are directly denied when a risk is identified. However, if the risk identification is wrong, the normal user may not enjoy the service directly, and the user experience is affected; in addition, refusing the transaction in the payment stage of the NSF mode may cause a bad account risk, that is, a part of the users may not be able to deduct the corresponding money after enjoying the service (i.e., no money deduction risk), and even a lawbreaker may perform a malicious operation on the batch registered account in the scene, thereby causing a batch bad account.

In view of the above problems, there is no better solution in the industry at present.

Disclosure of Invention

In view of this, embodiments of the present disclosure provide a secure transaction method, an apparatus, and an electronic device, which are used to at least solve the problems in the related art that a bad account rate is too high in the NSF mode and a normal user may not be able to enjoy a service.

The embodiment of the specification adopts the following technical scheme:

an embodiment of the present specification provides a secure service transaction method, including: acquiring an account service request; judging whether the account corresponding to the account service request has target risk or not based on a first wind control model; and determining whether to execute a prepaid transaction mode or a share-before-pay transaction mode for the account service request according to the judgment result about the target class risk.

An embodiment of the present specification provides a secure service transaction method, including: acquiring an account service request corresponding to a first-share-then-pay transaction mode; judging whether the account corresponding to the account service request has target risk or not based on a first wind control model; determining whether a transaction mode corresponding to the account service request is converted into a prepaid transaction mode according to the judgment result about the target risk; when the transaction mode corresponding to the account service request is converted into a prepaid transaction mode, whether the account service request has payment risks or not is judged based on a second wind control model; and determining whether to execute the payment operation aiming at the account service request according to the judgment result of the payment risk.

An embodiment of the present specification further provides a secure transaction apparatus, including: the service request acquisition unit is used for acquiring an account service request; the first wind control unit is used for judging whether the account corresponding to the account service request has a target risk or not based on a first wind control model; and the transaction mode determining unit is used for determining whether a prepaid transaction mode or a share-first-then-pay transaction mode is executed aiming at the account service request according to the judgment result about the target risk.

An embodiment of the present specification further provides a secure transaction apparatus, including: the NSF service request acquisition unit is used for acquiring an account service request corresponding to a first-share-then-pay transaction mode; the first wind control unit is used for judging whether the account corresponding to the account service request has a target risk or not based on a first wind control model; the transaction mode conversion unit is used for determining whether the transaction mode corresponding to the account service request is converted into a prepaid transaction mode according to the judgment result about the target risk; the second wind control unit is used for judging whether the account service request has payment risk or not based on a second wind control model when the transaction mode corresponding to the account service request is converted into a prepaid transaction mode; and the payment operation execution unit determines whether to execute the payment operation aiming at the account service request according to the judgment result of the payment risk.

An embodiment of the present specification further provides an electronic device, including: at least one processor; and a memory storing instructions that, when executed by the at least one processor, cause the at least one processor to perform the method as described above.

The embodiment of the specification adopts at least one technical scheme which can achieve the following beneficial effects:

when an account service request is obtained, whether a target risk (or a risk of withholding money) exists is judged by using a first wind control model, whether a prepayment transaction mode or a first-share and later-pay transaction mode is executed is determined according to whether the target risk exists, the transaction cannot be directly refused, the problem that normal users with corresponding risk identification errors cannot enjoy services can be solved, and the overall service experience and service value of a user group can be guaranteed.

Drawings

The accompanying drawings, which are included to provide a further understanding of the embodiments of the specification and are incorporated in and constitute a part of this specification, illustrate embodiments of the specification and together with the description serve to explain the description and not to limit the specification in a non-limiting sense. In the drawings:

FIG. 1 illustrates a flow diagram of an example of a secure business transaction method in accordance with embodiments of the present description;

FIG. 2 illustrates a flow diagram of an example of a secure business transaction method in accordance with an embodiment of the present description;

FIG. 3 illustrates a flow diagram of an example of a secure business transaction method in accordance with an embodiment of the present description;

FIG. 4 illustrates a flow diagram of an example of determining a transaction wind evaluation index according to embodiments of the present description;

FIG. 5 illustrates a schematic diagram of an example of model optimization in accordance with an embodiment of the present description;

FIG. 6 is a schematic diagram illustrating an example of feature dimensions of a first wind control model in accordance with an embodiment of the present description;

FIG. 7 is a schematic diagram illustrating an example of feature dimensions of a second wind control model in accordance with an embodiment of the present description;

FIG. 8 illustrates a flow diagram of an example of a secure business transaction method in accordance with an embodiment of the present description;

FIG. 9 is a flow diagram illustrating an example of a method for secure business transaction in a cross-border travel-class business application scenario, according to an embodiment of the present description;

FIG. 10 illustrates a block diagram of an example of a secure transaction apparatus in accordance with an embodiment of the present description;

fig. 11 shows a block diagram of an example of a secure transaction apparatus according to an embodiment of the present specification.

Detailed Description

With the expansion of the business of internet companies, a lot of businesses are opened to overseas users, for example, some cross-border APPs (or cross-border applets) are on-line, so that the overseas users can conveniently use the businesses in China, for example, the travel type applets of cross-border scenes can meet the business core appeal of foreign wallet users in domestic taxi. In the cross-border scenario, the client user is a foreign user, the operator merchant is an operator of the travel applet, the place of occurrence is in a domestic area, and the transaction mode is a first-share-then-pay mode (namely, NSF mode), so that the foreign user can enjoy the NSF taxi taking service in the domestic area by using the travel applet in the wallet.

However, transactions in a new cross-border scenario have a variety of risk couplings, such as target-like risks (e.g., a "no money withheld risk" for a set target) and cross-border payment risks (e.g., cash-out, account theft, and card binding theft risks, etc.). Note that the foreign wallet service end is loosely bound to foreign cards, as foreign law allows credit card cash register (its off-line ATM supports credit card cash withdrawal). However, according to domestic laws and regulations, domestic credit card cash-out is an impermissible behavior, and some domestic users may use CN double-currency credit card binding foreign purses for cash-out transactions (e.g., paying for travel-like business orders online at home), which is also not allowed.

In order to make the objects, technical solutions and advantages of the present disclosure more clear, the technical solutions of the present disclosure will be clearly and completely described below with reference to the specific embodiments of the present disclosure and the accompanying drawings. It is to be understood that the embodiments described are only a few embodiments of the present disclosure, and not all embodiments. All other embodiments, which can be derived by one of ordinary skill in the art from the embodiments given herein without making any creative effort, shall fall within the scope of the implementation of the present specification.

As used herein, the term "include" and its variants mean open-ended terms in the sense of "including, but not limited to. The term "based on" means "based at least in part on". The terms "one embodiment" and "an embodiment" mean "at least one embodiment". The term "another embodiment" means "at least one other embodiment". The terms "first," "second," and the like may refer to different or the same object. Other definitions, whether explicit or implicit, may be included below. The definition of a term is consistent throughout the specification unless the context clearly dictates otherwise.

In this context, the term "business transaction" refers to the exchange of value between two parties of a business in the medium of money and services, for example, a transaction may refer to the entire process from the initiation of a business order to the completion of the payment results, and may include an order link and a payment link. The term "target-like risk" may refer to the risk that after an NSF transaction, the merchant actively initiates a debit payment to the account designated card tie and the payment fails, as well as the risk that the user does not go to pay the money of the NSF transaction order for a long period of time (e.g., more than one month), i.e., the risk of not withholding the money.

Fig. 1 illustrates a flow diagram of an example of a secure business transaction method in accordance with an embodiment of the present description. The main body of the method according to the embodiment of the present specification may be a server directly responsible for providing business services (e.g., travel business services), or may be a third-party server associated with the business (e.g., a server of a wallet application platform for installing travel applets), and both of them fall within the scope of the implementation of the present specification.

As shown in fig. 1, in step 110, an account service request is obtained.

Specifically, the server may receive an account service request from the client. In one example of the embodiments of the present specification, the account service request may be an account service request for a travel-class service, for example, a user issues an account service request to a server by operating a travel-class applet on a wallet client.

In step 120, based on the first wind control model, it is determined whether an account corresponding to the account service request has a target class risk. In an example of the embodiment of the present specification, an existing wind control model for a target class risk may be used as a first wind control model, and account credits may be identified, so as to obtain a corresponding target class risk. In another example of the embodiments of the present specification, the first wind control model may also be a completely new wind control model proposed in other sections below to identify the target class risk, and the specific details will be developed below.

In step 130, it is determined whether to execute a prepaid transaction mode or a pay-first-share transaction mode for the account service request according to the determination result regarding the target class risk. Here, the corresponding payment transaction mode may be determined directly according to the target class risk, or a comprehensive judgment may be performed by combining one or more preset payment mode influence factors, for example, a share-before-pay transaction mode may be directly opened for a white list user according to an operation policy.

In an example of the embodiments of the present specification, if the determination result indicates that there is a target class risk, a prepaid transaction mode is executed for the account service request, and if the determination result indicates that there is no target class risk, a share-before-pay transaction mode is executed for the account service request. Therefore, the transaction is continued instead of being directly terminated by converting the payment transaction mode, the problem that the user cannot enjoy the service due to credit identification or low credit can be solved, and the overall service experience and service value of the user group can be guaranteed.

Fig. 2 illustrates a flow diagram of an example of a secure business transaction method in accordance with an embodiment of the present description.

In step 210, an account service request is obtained.

In step 220, based on the first wind control model, it is determined whether the account corresponding to the account service request has a target class risk.

In step 230, it is determined whether to execute a prepaid transaction mode or a pay-first-share transaction mode for the account service request based on the determination of the target class risk. For details and effects of the step 210-230, reference may be made to the description of the step 110-130 in fig. 1, and details will not be repeated here.

In step 240, when it is determined that the prepaid transaction mode is to be executed for the account service request, it is determined whether the account service request is at risk of payment based on a second wind control model. Here, the payment risk (or payment risk) may represent various risks that may be generated in the payment process, such as a card-theft risk, an account-theft risk, a cash-out risk, and the like. In one example of the embodiments of the present specification, an existing wind-controlled model for payment risk (or payment risk) may be used as the second wind-controlled model, and the security of the current payment operation is identified, so as to obtain the corresponding payment risk. In another example of the embodiments of the present specification, the second wind-controlled model may also be a completely new wind-controlled model as presented elsewhere in the following to identify payment risks, the details of which will be developed below.

It should be appreciated that whether in a prepaid transaction mode or a share-before-pay transaction mode, there is a need to identify payment risks when conducting a payment transaction. Specifically, in the share-before-pay transaction mode, a pay transaction is performed after a user enjoys a service (e.g., a travel service, a rental goods service, etc.), and a corresponding payment risk is identified. In addition, in the prepaid transaction mode, payment transactions are conducted when the user is not enjoying the service, at which time the corresponding payment risk is identified.

In step 250, it is determined whether to perform a payment operation for the account service request according to the determination result on the payment risk. Here, whether to execute the corresponding payment operation may be determined directly according to the payment risk, and a comprehensive determination may be performed by combining one or more preset core-body manners, for example, a face core-body manner is activated when the payment risk is identified, and whether to execute the corresponding payment operation may be determined by combining the face core-body result.

In addition, when it is determined that the share-before-pay transaction mode is executed for the account service request, the payment operation may be executed directly after the user enjoys the service, or it may be determined whether there is a payment risk in the account service request based on the second wind control model, and it is determined whether to execute the payment operation for the account service request according to a result of the determination regarding the payment risk, and all of them fall within the scope of the implementation of the present specification.

With regard to the details of step 240 described above, in one example of the embodiments of the present specification, if the determination result indicates that there is a payment risk, execution of a payment operation for the account service request is denied, and if the determination result indicates that there is no payment risk, execution of a payment operation for the account service request is denied. Therefore, for the account in the prepayment mode, payment risk identification is carried out before service is provided, when payment risk exists, execution of payment operation can be directly refused, service is refused to be provided, and the problem of bad account after service is provided in the NSF mode can be effectively solved.

In the embodiment of the specification, the corresponding payment transaction mode is determined by using the first wind control model, and whether the corresponding payment operation is executed is determined by using the payment risk determined by the second wind control model in the payment stage of prepayment. Therefore, the comprehensive risk condition similar to that in the NSF mode can be effectively reduced while the service experience of the NSF mode is guaranteed.

Fig. 3 illustrates a flow diagram of an example of a secure business transaction method in accordance with an embodiment of the present description.

As shown in fig. 3, in step 310, historical transaction data sets generated by a plurality of accounts over a set period of time are obtained. For example, historical transaction data sets generated by all accounts over the past month may be obtained. Here, the historical transaction data may include any non-sensitive data related to the transaction (e.g., not including an account password), such as transaction payment patterns, transaction results, transaction amount, and the like.

In step 320, a transaction wind control evaluation index is determined based on the historical transaction data set. Here, the transaction wind control evaluation index includes a bad payment deduction rate, a prepaid order proportion and a wind control transaction failure rate.

In one example of an embodiment of the present description, the bad-payment rate is deducted (deduction failure total/total transaction amount). Specifically, the total transaction amount may be determined according to the amount in each historical transaction data, the withholding transaction data subsets may be filtered from the historical transaction data sets, and the amounts in each withholding transaction data may be counted to determine the withholding failure total amount. Thus, the wind control decisions (e.g., the first and second wind control models) may be constrained by the index.

In one example of an embodiment of the present description, the prepaid order proportion is (prepaid transaction magnitude/total transaction magnitude). In particular, a total transaction magnitude may be determined from the amount of historical transaction data, and a prepaid transaction magnitude may be determined from each historical transaction data having a prepaid manner. Here, wind disturbance can be measured by pre-paid order proportions. For operators, the pay-before-use service mode is a characteristic, and if risk protection is intensively emphasized, the mode is converted into the traditional pay-before-use mode, which is unfavorable for business development. Thus, a wind control decision (e.g., a first wind control model) may be constrained by the indicator.

In one example of an embodiment of the present specification, a rate of failure of a gated transaction (a level of failed transactions due to gating/a level of total transactions). Here, the failed transaction caused by the wind control may include, on One hand, a transaction corresponding to the account service request rejected due to the determination result output by the second wind control model, and on the other hand, a wind control challenge (or a core operation) generated by rejection of the wind control model, where the wind control challenge includes, but is not limited to, a payment Password, an OTP (One-time Password), a 3D check, and the like, and the failed transaction caused by the wind control also needs to be included in a molecular part of an arithmetic formula of the failure rate of the wind control transaction. Thus, a wind control decision (e.g., a second wind control model) may be constrained by the indicator.

In step 330, whether to execute an optimization operation on the first wind control model and/or the second wind control model is determined based on the transaction wind control evaluation index. Therefore, the performance of the wind control model can be evaluated through the transaction wind control evaluation index, and the instructive optimization operation of the wind control model is realized. For example, when the rate of losing bad accounts is too large, the pneumatic control decision can be tightened to reduce the rate of losing bad accounts.

FIG. 4 illustrates a flow diagram of an example of determining a transaction wind evaluation index according to an embodiment of the present description.

As shown in fig. 4, in step 410, historical transaction data sets generated by a plurality of accounts over a set period of time are obtained.

In step 420, a transaction wind control evaluation index is determined based on a preset transaction noise factor and a historical transaction data set. It should be noted that, in some cases, there may be a transaction noise factor that affects the transaction real data volume, which is a non-risk factor, but should be excluded from the impact factors of the transaction wind control evaluation index for the wind control policy. Here, the transaction noise factor may be input by the operator.

For example, due to macro environmental factors (e.g., epidemic situations), the total transaction volume level in a specific time is greatly reduced, and the withholding rate is significantly increased, which belongs to the normal fluctuation caused by pure business root. At this time, when calculating the withholding rate, in addition to considering the relative value between the withholding failure transaction and the total transaction, it may also need to consider the number of the withholding failure transactions, for example, the withholding failure transactions with too small total amount should not be enough to cause the withholding rate to exceed the set threshold.

FIG. 5 illustrates a schematic diagram of an example of model optimization according to an embodiment of the present description.

As shown in fig. 5, determining whether to adjust the feature dimension and the risk threshold of the first wind control model and/or the second wind control model based on the transaction wind control evaluation index; and/or determining whether to train the first wind control model and/or the second wind control model by utilizing the historical transaction data set based on the transaction wind control evaluation index. For example, if the bad payment rate is not deducted, the wind control decision may be tightened, for example, the risk threshold is lowered, the feature dimension is perfected, and the wind control model is trained to optimize the risk recognition performance of the wind control model. For specific details of the training of the first wind control model and/or the second wind control model by using the historical transaction data set, reference may be made to a model training process in the related art, which is not repeated herein.

Fig. 6 is a schematic diagram illustrating an example of feature dimensions of a first wind control model according to an embodiment of the present specification.

As shown in fig. 6, the characteristic dimensions of the first wind control model include: the method comprises the following steps of account historical payment records, account historical transaction modes, account asset information, account age information, account binding information, account registration information and account security authentication results. In one example of an embodiment of the present specification, the first wind control model may identify one or more risk scenarios of the target class risk by using a combination of one or more (e.g., all) of the feature dimensions therein, and there may be a corresponding weight between different feature dimensions in the combination of feature dimensions.

In particular, the account historical payment record may indicate whether the account was successfully paid during the historical payment process. The historical transaction pattern of the account may indicate whether the account uses a prepaid or pay-first-share mode during historical payment. The account registration information may be used to reflect whether the account is at risk for batch registration, such as multiple accounts with devices or multiple accounts with cards, etc. In addition, many account information can be obtained through the characteristic dimensions, such as whether the account is long or not, whether the bound card is long or not, whether the account security authentication result is successful or not (for example, whether the account completes KYC audit or not), and whether the resources in the account are high or not (including bound card or balance). In addition, the historical account payment records and the historical account transaction modes can be combined to determine corresponding historical account credit information, such as whether the account successfully pays the low-risk hydroelectric coal transaction, whether the account has a historical record of successful post-payment deduction and the like.

In this embodiment of the present specification, the first wind control model may consider a plurality of account risk scenarios from each feature dimension, and may more reliably identify whether the account has a target risk.

Fig. 7 is a schematic diagram illustrating an example of feature dimensions of a second wind control model according to an embodiment of the present specification.

As shown in fig. 7, the characteristic dimensions of the second wind control model include: the account attribution country identification information, the payment card attribution country identification information, the account binding information, the payment card binding account information, the account historical transaction information and the payment card historical transaction information. In one example of an embodiment of the present specification, the second wind control model may identify payment risks by using a combination of one or more (e.g., all) of the feature dimensions therein, and there may be a corresponding weight between different ones of the feature dimensions in the combination of feature dimensions. Here, the second wind control model can identify credit card cross-border cash-out risks in addition to common payment risks.

In particular, the account home country identification information may reflect the home country of the account, such as a foreign version of a wallet account. The payment card home country identification information may reflect the home country of the payment card, such as when a CN two-currency credit card is used for a pen transaction. The historical transaction information of the account can be used for reflecting whether frequent offline consumption with large amount exists in the payment history of the account. The historical transaction information of the payment card can be used for reflecting whether the card paid currently has frequent offline consumption with large amount. In addition, the account binding information and the payment card binding account information can be combined to identify whether the single account binding multi-card risk and the single card binding multi-user risk exist.

In the embodiment of the specification, the second wind control model can identify various payment risk scenes from various feature dimensions, and can reliably identify whether the account has a payment risk, especially a cross-border cash register risk of a credit card.

Fig. 8 illustrates a flow diagram of an example of a secure business transaction method in accordance with an embodiment of the present description.

As shown in fig. 8, in step 810, an account service request corresponding to the share-then-pay transaction mode is obtained.

In step 820, based on the first wind control model, it is determined whether the account corresponding to the account service request has a target class risk.

In step 830, it is determined whether to convert the transaction mode corresponding to the account service request into a prepaid transaction mode according to the determination result regarding the target class risk. Specifically, if the target class risk is identified, the transaction mode corresponding to the account service request may be converted into a prepaid transaction mode. If no target class risk is identified, the share-before-pay transaction mode may continue to be executed.

In step 840, when the transaction mode corresponding to the account service request is converted into the prepaid transaction mode, whether the account service request has a payment risk is determined based on the second wind control model.

In step 850, it is determined whether to perform a payment operation for the account service request according to the determination result regarding the payment risk.

In the service scenario provided by the embodiment of the present specification, each client executes the NSF transaction mode respectively, and only when it is recognized that the account has the target risk, the NSF transaction mode is converted into the prepaid transaction mode, so that the user experience in the NSF transaction mode can be disturbed as little as possible.

Fig. 9 is a flowchart illustrating an example of a secure business transaction method in a cross-border travel-class business application scenario according to an embodiment of the present specification.

As shown in fig. 9, a plurality of clients (for example, clients 901, 903, and 905) may have corresponding cross-border travel applets installed thereon, and a user may make an order for a taxi service through the travel applets, that is, the client sends an account service request to the server. Here, the client may be a pay-mode that is defaulted to execute the NSF mode.

In response to the account service request, the server 910 may perform risk control in the ordering process and risk identification and risk control in the payment process, respectively. In step 921, the server 910 can identify whether the account has a target class risk in the next order stage. In step 923, if the target class risk is detected, the server 910 executes the prepaid mode and may send a payment mode conversion instruction to the client to cause the client to convert from the NSF mode to the prepaid mode. If it is detected that there is no target class risk, both the server 910 and the client may continue to execute the NSF mode.

In the payment process, the server 910 may identify whether the account is at risk of fraud or cash-out in step 931. In step 941, if there is a risk of account theft or cash-out, the payment operation is denied resulting in a failure of the transaction. In step 943, if there is no risk of account theft or cash-out, a payment operation is performed.

In the embodiment of the specification, when a user places an order to perform taxi taking service, if a potential target risk is identified, the wind control side outputs rejection, and the service side converts a corresponding decision into a prepayment mode. Therefore, the risk side still outputs accurate judgment and supplies the accurate judgment for the business side to consume. In addition, post-payment is converted into prepayment on the service side, the target risk can be avoided, the ordering condition can not be influenced, and compared with a wind control scheme which directly rejects to cause ordering failure, the technical scheme can give consideration to service value.

In the embodiment of the specification, the risk of the ordering link and the risk of the payment link are coupled and mutually influenced, so that comprehensive consideration is required in designing a corresponding evaluation index. Here, transaction wind control evaluation indexes including a bad-account withholding rate, a prepaid order proportion and a wind control transaction failure rate may be set.

The risk determination process for each transaction wind control evaluation index will be described below with reference to an example.

Regarding the risk judgment process of the withholding bad money rate, taking a business scene of a foreign wallet travel type small program as an example, the average withholding bad money rate can be obtained to be 2.5% according to data expression of a month after business is online, for example, the withholding bad money rate corresponding to each day in a month is counted, and then the average withholding bad money rate in a month is determined. When the bad payment rate is less than or equal to 7.5% (3 times principle), the overall risk is high, whether batch attack or centralized personal case is needed to pay attention, and the parameters of the first wind control model and the second wind control model can be adjusted correspondingly, or the historical transaction data set is used for training and optimizing the wind control model.

In addition, it should be noted that, because the business is greatly influenced by the macro environment (such as epidemic situation), the transaction volume level will greatly slide down within a specific time, which results in a significant increase of the withholding rate, which is a non-risk factor and normal fluctuation caused by pure business root. In this case, in addition to paying attention to the withholding rate, the comprehensive risk judgment needs to be performed in combination with the influence of the transaction noise influence factor on the denominator.

Regarding the risk judgment process of the prepaid order proportion, taking the service scene of the foreign wallet travel small program as an example, the prepaid order proportion is 15.2% according to the data expression of one month after the service is on line, for example, the prepaid order proportion corresponding to each day in one month is counted, and then the average value of the prepaid order proportion in one month is determined.

When the proportion of the prepaid order is larger than or equal to 45% (3 times principle), the overall disturbance is high, whether strategy tuning is needed or not needs to be focused, for example, parameters of a wind control model (especially a first wind control model) are adjusted and optimized, and the wind control model can be trained and optimized by utilizing a historical transaction data set.

It should be understood that when the operator actually performs the service operation, because the black sample at the early stage of the service online is insufficient, for the reason of guaranteeing the service, more postpaid orders are released in a prepaid manner to release risks. Furthermore, after the business runs for a period of time, the strategy can be gradually released and the risk exposure brought by the strategy can be observed.

Regarding the risk judgment process of the wind-controlled transaction failure rate, taking the service scene of the foreign wallet trip class applet as an example, the average value of the wind-controlled transaction failure rate is 1% according to the data expression of one month after the service is on line, for example, the wind-controlled transaction failure rate corresponding to each day in one month is counted, and then the average value of the wind-controlled transaction failure rate in one month is determined.

When the failure rate of the wind control transaction is larger than or equal to 3% (3 times principle), the overall disturbance is high, and whether strategy tuning is needed or not needs to be focused, for example, parameters of the wind control model (especially the second wind control model) are adjusted and optimized, and the wind control model can be trained and optimized by utilizing the historical transaction data set.

It should be understood that when theft batch attacks occur or the management of cash-out behavior is tightened, the wind control decision is necessarily tightened correspondingly, so that the failure rate of the wind control transaction is increased, and the analysis can be performed by combining specific situations.

Through this description embodiment, not only can cover this internal this risk scene, can also cover novel cross border risk scene, cover the risk range widely. In addition, in the embodiment, a scheme for aversion from the risk (namely, a scheme for strictly refusing all types of risks in the wind control identification) is not adopted, but both the user experience and the service value are considered, and the risk of the target type of risk is released in a prepayment mode. In addition, a corresponding wind control evaluation system is also provided in the embodiment, and compared with a wind control evaluation system with heavy risk concentration and light user experience in the prior art, the method can comprehensively balance the status among the user experience, the service type and the wind control, and realize that the wind control performance is restricted by a plurality of experience indexes.

Fig. 10 is a block diagram illustrating an example of a secure transaction apparatus according to an embodiment of the present specification.

As shown in fig. 10, the secure service transaction apparatus 1000 includes a transaction request obtaining unit 1010, a first wind control unit 1020, a transaction mode determining unit 1030, a second wind control unit 1040, a payment operation executing unit 1050, a historical transaction data obtaining unit 1060, a transaction wind control evaluation index determining unit 1070, and a wind control model optimizing unit 1080.

The transaction request acquisition unit 1010 is configured to acquire an account service request. For more details on the transaction request obtaining unit 910, reference may be made to the operation described above with reference to step 110 in fig. 1.

The first wind control unit 1020 is configured to determine whether an account corresponding to the account service request has a target class risk based on the first wind control model. For more details on the first wind control unit 920, reference may be made to the operations described above with reference to step 120 in fig. 1.

In one example of an embodiment of the present specification, the feature dimensions of the first wind control model include: the method comprises the following steps of account historical payment records, account historical transaction modes, account asset information, account age information, account binding information, account registration information and account security authentication results.

The transaction pattern determination unit 1030 is configured to determine whether to execute a prepaid transaction pattern or a pay-before-share transaction pattern for the account service request according to the determination result regarding the target class risk. For more details of the transaction pattern determination unit 1030, reference may be made to the operations described above with reference to step 130 in fig. 1.

In one example of an embodiment of the present specification, the transaction pattern determination unit 930 is further configured to execute a prepaid transaction pattern for the account service request if the determination result indicates that the target class risk exists; and if the judgment result indicates that the target risk does not exist, executing a share-before-pay transaction mode aiming at the account service request.

The second pneumatic control unit 1040 is configured to determine whether the account service request is at risk of payment based on a second pneumatic control model when determining that the prepaid transaction mode is executed for the account service request. For more details about the second wind control unit 1040, reference may be made to the operations described above with reference to step 240 in fig. 2.

In one example of an embodiment of the present specification, the payment risk comprises a credit card cross-border cash-out risk, and the feature dimensions of the second wind control model comprise: the account attribution country identification information, the payment card attribution country identification information, the account binding information, the payment card binding account information, the account historical transaction information and the payment card historical transaction information.

The payment operation execution unit 1050 is configured to determine whether to execute a payment operation for the account service request according to a result of the determination regarding the payment risk. For more details of the payment operation execution unit 1050, reference may be made to the operations described above with reference to step 250 in fig. 2.

In one example of the embodiment of the present specification, the payment operation execution unit 1050 is further configured to refuse to execute the payment operation corresponding to the account service request if the determination result indicates that there is a payment risk, and execute the account service request if the determination result indicates that there is no payment risk.

The historical transaction data acquisition unit 1060 is configured to acquire historical transaction data sets generated by a plurality of accounts over a set period of time. For more details regarding the historical transaction data acquisition unit 1060, reference may be made to the operations described above with reference to step 310 in fig. 3.

The transaction wind control evaluation index determination unit 1070 is configured to determine a transaction wind control evaluation index based on the historical transaction data set, the transaction wind control evaluation index including a withholding bad-account rate, a prepaid order proportion, and a wind control transaction failure rate. For more details of the transaction wind control evaluation index determination unit 1070, reference may be made to the operation described above with reference to step 320 in fig. 3.

In one example of the embodiments herein, the transaction wind control evaluation index determination unit 970 further determines the transaction wind control evaluation index based on a preset transaction noise factor and the historical transaction data set.

The wind control model optimization unit 1080 is configured to determine whether to perform an optimization operation on the first wind control model and/or the second wind control model based on the transaction wind control evaluation index. For more details of the wind control model optimization unit 1080, reference may be made to the operations described above with reference to step 330 in fig. 3.

In one example of an embodiment herein, the wind control model optimization unit 1080 includes a wind control model parameter adjustment module (not shown) configured to determine whether to adjust the feature dimensions and risk thresholds of the first wind control model and/or the second wind control model based on the transaction wind control evaluation index and/or a wind control model training module (not shown); and the wind control model training module is configured to determine whether to train the first wind control model and/or the second wind control model by utilizing the historical transaction data set based on the transaction wind control evaluation index.

It should be noted that some of the units in the apparatus 1000 described above are not necessary or optional in some application scenarios, for example, the historical transaction data obtaining unit 1060, the transaction wind control evaluation index determining unit 1070, and the wind control model optimizing unit 1080 may not be retained in some examples.

Fig. 11 shows a block diagram of an example of a secure transaction apparatus according to an embodiment of the present specification.

As shown in fig. 11, the secure transaction apparatus 1100 includes an NSF service request acquisition unit 1110, a first wind control unit 1120, a transaction mode conversion unit 1130, a second wind control unit 1140, and a payment operation execution unit 1150.

The NSF service request acquisition unit 1110 is configured to acquire an account service request corresponding to a pay-after-share transaction mode. For more details of the NSF service request acquisition unit 1110, reference may be made to the operation described above with reference to step 810 in fig. 8.

The first wind control unit 1120 is configured to determine whether an account corresponding to the account service request has a target class risk based on the first wind control model. For more details about first wind control unit 1120, reference may be made to the operations described above with reference to step 820 in fig. 8.

The transaction mode conversion unit 1130 is configured to determine whether to convert the transaction mode corresponding to the account service request into a prepaid transaction mode according to the determination result about the target class risk. For more details on transaction mode conversion unit 1130, reference may be made to the operations described above with reference to step 830 in FIG. 8.

The second wind control unit 1140 is configured to determine whether the account service request is at a payment risk based on a second wind control model when the transaction mode corresponding to the account service request is converted into a prepaid transaction mode. For more details on the second wind control unit 1140, reference may be made to the operations described above with reference to step 840 in fig. 8.

The payment operation performing unit 1150 is configured to determine whether to perform a payment operation for the account service request according to a result of the determination regarding the payment risk. For more details of the payment operation execution unit 1150, reference may be made to the operations described above with reference to step 850 in fig. 8.

Embodiments of a secure transaction method and apparatus according to embodiments of the present specification are described above with reference to fig. 1 to 11. The details mentioned in the above description of the method embodiments also apply to the embodiments of the apparatus of the present description. The above security transaction apparatus may be implemented by hardware, or may be implemented by software, or a combination of hardware and software.

In the 90 s of the 20 th century, improvements in a technology could clearly distinguish between improvements in hardware (e.g., improvements in circuit structures such as diodes, transistors, switches, etc.) and improvements in software (improvements in process flow). However, as technology advances, many of today's process flow improvements have been seen as direct improvements in hardware circuit architecture. Designers almost always obtain the corresponding hardware circuit structure by programming an improved method flow into the hardware circuit. Thus, it cannot be said that an improvement in the process flow cannot be realized by hardware physical modules. For example, a Programmable Logic Device (PLD), such as a Field Programmable Gate Array (FPGA), is an integrated circuit whose Logic functions are determined by programming the Device by a user. A digital system is "integrated" on a PLD by the designer's own programming without requiring the chip manufacturer to design and fabricate application-specific integrated circuit chips. Furthermore, nowadays, instead of manually making an integrated Circuit chip, such Programming is often implemented by "logic compiler" software, which is similar to a software compiler used in program development and writing, but the original code before compiling is also written by a specific Programming Language, which is called Hardware Description Language (HDL), and HDL is not only one but many, such as abel (advanced Boolean Expression Language), ahdl (alternate Language Description Language), traffic, pl (core unified Programming Language), HDCal, JHDL (Java Hardware Description Language), langue, Lola, HDL, laspam, hardsradware (Hardware Description Language), vhjhd (Hardware Description Language), and vhigh-Language, which are currently used in most common. It will also be apparent to those skilled in the art that hardware circuitry that implements the logical method flows can be readily obtained by merely slightly programming the method flows into an integrated circuit using the hardware description languages described above.

The controller may be implemented in any suitable manner, for example, the controller may take the form of, for example, a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro) processor, logic gates, switches, an Application Specific Integrated Circuit (ASIC), a programmable logic controller, and an embedded microcontroller, examples of which include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicone Labs C8051F320, the memory controller may also be implemented as part of the control logic for the memory. Those skilled in the art will also appreciate that, in addition to implementing the controller as pure computer readable program code, the same functionality can be implemented by logically programming method steps such that the controller is in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers, embedded microcontrollers and the like. Such a controller may thus be considered a hardware component, and the means included therein for performing the various functions may also be considered as a structure within the hardware component. Or even means for performing the functions may be regarded as being both a software module for performing the method and a structure within a hardware component.

The systems, devices, modules or units illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. One typical implementation device is a computer. In particular, the computer may be, for example, a personal computer, a laptop computer, a cellular telephone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

For convenience of description, the above devices are described as being divided into various units by function, and are described separately. Of course, the functions of the various elements may be implemented in the same one or more software and/or hardware implementations of the present description.

As will be appreciated by one skilled in the art, embodiments of the present description may be provided as a method, system, or computer program product. Accordingly, the description may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, embodiments of the present description may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and so forth) having computer-usable program code embodied therein.

The description has been presented with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the description. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

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

The memory may include forms of volatile memory in a computer readable medium, Random Access Memory (RAM) and/or non-volatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.

Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, 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 technology, compact disc read only memory (CD-ROM), Digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape disk storage or other magnetic storage devices, or any other non-transmission medium which can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.

It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. The use of the phrase "including a" does not exclude the presence of other, identical elements in the process, method, article, or apparatus that comprises the same element, whether or not the same element is present in all of the same element.

The embodiments of this specification may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.

The embodiments in the present specification are described in a progressive manner, and the same and similar parts among the embodiments are referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, for the system embodiment, since it is substantially similar to the method embodiment, the description is simple, and for the relevant points, reference may be made to the partial description of the method embodiment.

The above description is only an example of the present specification, and is not intended to limit the present specification. Various modifications and alterations to this description will become apparent to those skilled in the art. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included in the scope of the claims of the present application.