WO2021213250A1 - 安全业务交易 - Google Patents

安全业务交易 Download PDF

Info

Publication number
WO2021213250A1
WO2021213250A1 PCT/CN2021/087645 CN2021087645W WO2021213250A1 WO 2021213250 A1 WO2021213250 A1 WO 2021213250A1 CN 2021087645 W CN2021087645 W CN 2021087645W WO 2021213250 A1 WO2021213250 A1 WO 2021213250A1
Authority
WO
WIPO (PCT)
Prior art keywords
transaction
risk
account
risk control
payment
Prior art date
Application number
PCT/CN2021/087645
Other languages
English (en)
French (fr)
Inventor
徐彬彬
覃桃
李典
Original Assignee
支付宝(杭州)信息技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 支付宝(杭州)信息技术有限公司 filed Critical 支付宝(杭州)信息技术有限公司
Publication of WO2021213250A1 publication Critical patent/WO2021213250A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/22—Payment schemes or models
    • G06Q20/24—Credit schemes, i.e. "pay after"
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G06Q20/4016—Transaction verification involving fraud or risk level assessment in transaction processing

Definitions

  • the embodiments of this specification relate to the field of computer technology, and in particular to a secure business transaction method, device, and electronic equipment.
  • Non-sufficient Fund is a payment mode that enhances user service experience and convenience. Its characteristic is to allow users to enjoy the service before deducting the corresponding payment.
  • the embodiments of the present specification provide a secure business transaction method, device and electronic equipment, which are used to at least solve the problem of high bad debt rate in the NSF mode in the current related technology and the normal users may not be able to enjoy the service.
  • the embodiment of this specification provides a secure business transaction method, including: obtaining an account business request; judging whether the account corresponding to the account business request has a target risk based on the first risk control model; As a result of the judgment, it is determined whether to execute the prepaid transaction mode or the prepaid transaction mode for the account service request.
  • the embodiment of this specification provides a secure business transaction method, which includes: obtaining an account business request corresponding to a pre-shared post-pay transaction mode; based on the first risk control model, judging whether the account corresponding to the account business request has target risk; According to the judgment result of the target risk, it is determined whether to convert the transaction mode corresponding to the account service request to the prepaid transaction mode; when the transaction mode corresponding to the account service request is converted to the prepaid transaction mode, Determine whether there is a payment risk in the account service request based on the second risk control model; determine whether to perform the payment operation for the account service request according to the judgment result on the payment risk.
  • the embodiment of this specification also provides a secure business transaction device, including: a business request acquisition unit to acquire an account business request; a first risk control unit, based on the first risk control model, to determine whether the account corresponding to the account business request exists Target risk; a transaction mode determination unit, based on the judgment result of the target risk, determines whether to execute a prepaid transaction mode or a first-share-after-pay transaction mode for the account service request.
  • the embodiment of the present specification also provides a secure business transaction device, including: an NSF business request acquisition unit, which acquires an account business request corresponding to a pre-shared post-paid transaction mode; a first risk control unit, which determines the said transaction based on the first risk control model Whether the account corresponding to the account service request has target risk; the transaction mode conversion unit determines whether to convert the transaction mode corresponding to the account service request to the prepaid transaction mode according to the judgment result of the target risk; The second risk control unit, when converting the transaction mode corresponding to the account service request to the prepaid transaction mode, judge whether the account service request has a payment risk based on the second risk control model; the payment operation execution unit, according to the relevant The judgment result of the payment risk determines whether to perform the payment operation for the account service request.
  • an NSF business request acquisition unit which acquires an account business request corresponding to a pre-shared post-paid transaction mode
  • a first risk control unit which determines the said transaction based on the first risk control model Whether the account corresponding
  • the embodiments of the present specification also provide an electronic device, including: at least one processor; and a memory, the memory stores instructions, and when the instructions are executed by the at least one processor, the at least one processor executes The above method.
  • the first risk control model is used to determine whether there is a target risk (or, it can also be referred to as "the risk of not deducting money"), and the prepayment is determined according to whether there is a target risk
  • the transaction model is to implement the first-share-after-pay transaction model without directly rejecting the transaction, which can solve the problem that normal users with incorrect risk identification cannot enjoy the service, and can guarantee the overall service experience and business value of the user group.
  • Fig. 1 shows a flowchart of an example of a secure business transaction method according to an embodiment of this specification
  • Fig. 2 shows a flowchart of an example of a secure business transaction method according to an embodiment of the present specification
  • Fig. 3 shows a flowchart of an example of a secure business transaction method according to an embodiment of this specification
  • FIG. 4 shows a flowchart of an example of determining a transaction risk control evaluation index according to an embodiment of this specification
  • Fig. 5 shows a schematic diagram of an example of model optimization according to an embodiment of the present specification
  • Fig. 6 shows a schematic diagram of an example of the feature dimensions of the first risk control model according to an embodiment of the present specification
  • Fig. 7 shows a schematic diagram of an example of feature dimensions of a second risk control model according to an embodiment of the present specification
  • Fig. 8 shows a flowchart of an example of a secure business transaction method according to an embodiment of the present specification
  • FIG. 9 shows a schematic flowchart of an example of a secure business transaction method in a cross-border travel business application scenario according to an embodiment of this specification
  • Fig. 10 shows a structural block diagram of an example of a secure business transaction device according to an embodiment of this specification
  • Fig. 11 shows a structural block diagram of an example of a secure business transaction device according to an embodiment of the present specification.
  • cross-border apps or cross-border applets
  • travel applets in cross-border scenarios can be used. Satisfy the core business demands of Hong Kong wallet users to take taxis on the mainland.
  • the client user is a Hong Kong user
  • the operator-side merchant is the operator of a small travel program (for example, Didi Dache)
  • the place of occurrence is in the mainland
  • the transaction model is the first-share-before-pay model (i.e., NSF mode), so that Hong Kong users can use the travel applet in the wallet to enjoy NSF taxi services in the mainland.
  • the term “including” and its variations mean open terms, meaning “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”, etc. may refer to different or the same objects. Other definitions can be included below, whether explicit or implicit. Unless clearly indicated in the context, the definition of a term is consistent throughout the specification.
  • business transaction refers to the exchange of value between business parties through currency and services.
  • a transaction can refer to the entire process from the initiation of a business order to the completion of the payment result, and can include the order link and the payment link.
  • target risk can refer to the risk that after the NSF transaction, the merchant voluntarily assigns a card to the account to initiate a deduction payment and the payment fails, and the user does not pay for the NSF transaction order for a long time (for example, more than one month) The risk of payment, that is, the risk of not being deducted.
  • Fig. 1 shows a flowchart of an example of a secure business transaction method according to an embodiment of the present specification.
  • it may be a server directly responsible for providing business services (for example, travel business services), or a third-party server associated with the business (for example, a wallet that installs travel applets).
  • business services for example, travel business services
  • third-party server associated with the business for example, a wallet that installs travel applets.
  • the server side of the application platform and all belong to the scope of implementation of this specification.
  • step 110 an account service request is obtained.
  • the server may receive the account service request from the client.
  • the account service request may be an account service request for travel services.
  • the user sends an account service request to the server by operating a travel applet on the wallet client.
  • step 120 based on the first risk control model, it is determined whether the account corresponding to the account business request has target risk.
  • an existing risk control model for target risks can be used as the first risk control model to identify account credits, so as to obtain corresponding target risks.
  • the first risk control model can also be a brand new risk control model proposed in other parts below to identify target risks, and the specific details will be expanded below.
  • step 130 according to the judgment result on the target risk, it is determined whether to execute the prepaid transaction mode or the first-share-post-paid transaction mode for the account service request.
  • it can be directly based on the target risk to determine the corresponding payment transaction mode, or it can be combined with one or more preset payment mode influence factors to make a comprehensive judgment.
  • the whitelisted users can directly open the first share Post-paid transaction model.
  • the prepaid transaction mode is executed for the account business request, and if the judgment result indicates that there is no target type risk, then the account business request is executed before the payment. Transaction mode. Therefore, by switching the payment transaction mode to continue the transaction instead of directly terminating the transaction, the problem that users cannot enjoy the service due to credit identification or low credit can be solved, and the overall service experience and business value of the user group can be guaranteed.
  • Fig. 2 shows a flowchart of an example of a secure business transaction method according to an embodiment of the present specification.
  • step 210 an account service request is obtained.
  • step 220 based on the first risk control model, it is determined whether the account corresponding to the account business request has target risk.
  • step 230 according to the judgment result about the target risk, it is determined whether to execute the prepaid transaction mode or the first-share-after-paid transaction mode for the account service request.
  • steps 210-230 reference may be made to the description of steps 110-130 in FIG. 1, which will not be repeated here.
  • step 240 when it is determined that the prepaid transaction mode is executed for the account service request, it is determined whether there is a payment risk in the account service request based on the second risk control model.
  • payment risk may refer to various risks that may arise during the payment process, such as the risk of card theft, the risk of account theft, and the risk of cash out.
  • an existing risk control model for payment risk can be used as the second risk control model to identify the security of the current payment operation, so as to obtain the corresponding Payment risk.
  • the second risk control model may also be a brand new risk control model proposed in other parts below to identify payment risks, and the specific details will be expanded below.
  • a payment transaction is performed after the user enjoys a service (for example, travel service, item rental service, etc.), and the corresponding payment risk is identified at this time.
  • a payment transaction is performed when the user does not enjoy the service, and the corresponding payment risk is identified at this time.
  • step 250 it is determined whether to perform the payment operation for the account service request according to the judgment result on the payment risk.
  • the payment operation can be performed directly after the user enjoys the service, or the second risk control model can be used to determine whether there is a payment risk in the account service request.
  • the judgment result of the payment risk determines whether to perform the payment operation for the account business request, and all fall within the scope of implementation of this specification.
  • step 240 in an example of the embodiment of the present specification, if the judgment result indicates that there is a payment risk, the payment operation for the account service request is rejected, and if the judgment result indicates that there is no payment risk, then the payment operation is executed.
  • the payment operation requested by the account service Therefore, for prepaid accounts, the payment risk identification is performed before the service is provided, and when there is a payment risk, the payment operation can be directly refused and the service is refused, which can effectively solve the bad debt problem after the service is provided in the NSF model.
  • the first risk control model is used to determine the corresponding payment transaction mode
  • the payment risk determined by the second risk control model is used to determine whether to perform the corresponding payment operation during the prepayment payment stage.
  • Fig. 3 shows a flowchart of an example of a secure business transaction method according to an embodiment of the present specification.
  • historical transaction data sets generated by multiple accounts in a set time period are obtained. For example, you can obtain historical transaction data sets generated by all accounts in the past month.
  • historical transaction data may include any non-sensitive data related to the transaction (for example, without account password), such as transaction payment mode, transaction result, transaction amount, and so on.
  • a transaction risk control evaluation index is determined based on the historical transaction data set.
  • the transaction risk control evaluation indicators include the rate of undeducted bad debts, the proportion of prepaid orders and the failure rate of risk control transactions.
  • the rate of undeducted bad debts (total amount of failed deductions/total transaction amount).
  • the total transaction amount can be determined according to the amount in each historical transaction data, a subset of the transaction data that cannot be deducted from the historical transaction data set is filtered, and the amount of each transaction data that is not deducted can be counted to determine the failure of the deduction lump sum. Therefore, the index can be used to restrict risk control decisions (for example, the first risk control model and the second risk control model).
  • the proportion of prepaid orders (prepaid transaction level/total transaction level).
  • the total transaction volume level may be determined according to the amount of historical transaction data
  • the prepaid transaction volume level may be determined according to each historical transaction data with a prepayment method.
  • the prepaid order ratio can be used to measure the disturbance of risk control.
  • the service model of enjoy-before-pay is its characteristic. It will be unfavorable for business development if the mode is changed to the traditional pay-before-share model without emphasis on risk protection. Therefore, the index can be used to constrain the risk control decision (for example, the first risk control model).
  • the risk control transaction failure rate (the level of failed transactions caused by the risk control/total transaction level).
  • the failed transaction caused by the risk control can include, on the one hand, the rejection of the transaction corresponding to the account business request due to the judgment output of the second risk control model, on the other hand, it can also include the risk control challenge caused by the rejection of the risk control model ( Or, verify personal operation), risk control challenge methods include but are not limited to payment password, OTP (One-time Password), 3D verification, etc., and the failed transaction caused by it also needs to be included in the requirement of risk control transaction failure rate. Calculate the numerator part of the formula. Therefore, the index can be used to constrain the risk control decision (for example, the second risk control model).
  • step 330 based on the transaction risk control evaluation index, it is determined whether to perform an optimization operation on the first risk control model and/or the second risk control model.
  • the performance of the risk control model can be evaluated through the transaction risk control evaluation index, and the optimal operation of the risk control model can be realized. For example, when the rate of non-deductible bad debts is too large, risk control decisions can be tightened to reduce the rate of non-deductible bad debts.
  • Fig. 4 shows a flowchart of an example of determining a transaction risk control evaluation index according to an embodiment of the present specification.
  • step 410 historical transaction data sets generated by multiple accounts in a set time period are obtained.
  • a transaction risk control evaluation index is determined based on a preset transaction noise factor and historical transaction data set. It should be noted that in some cases, there will be transaction noise factors that affect the actual data volume of transactions, which are non-risk factors and should be excluded from the influencing factors of the transaction risk control evaluation indicators for risk control strategies. Here, the transaction noise factor can be entered by the operator.
  • the total transaction volume within a certain period of time will drop significantly, leading to a significant increase in the rate of deductions, which is a normal fluctuation caused by pure business roots.
  • the number of failed deduction transactions may also need to be considered, for example, the total amount is too small. It should not be enough to cause the deduction rate to exceed the set threshold.
  • Fig. 5 shows a schematic diagram of an example of model optimization according to an embodiment of the present specification.
  • the historical transaction data set is used to train the first risk control model and/or the second risk control model.
  • risk control decisions can be tightened, such as reducing risk thresholds, improving feature dimensions, and training the risk control model to optimize the risk recognition performance of the risk control model.
  • Fig. 6 shows a schematic diagram of an example of the feature dimensions of the first risk control model according to an embodiment of the present specification.
  • the characteristic dimensions of the first risk control model include: historical account payment records, historical account transaction patterns, account asset information, aging information, account binding information, account registration information, and account security verification results.
  • the first risk control model can identify one or more risk scenarios of the target risk by using a combination of one or more (for example, all) feature dimensions, and the feature dimensions There can be corresponding weights between different feature dimensions in the combination.
  • the account historical payment record may indicate whether the account is successfully paid during the historical payment process.
  • the historical transaction mode of the account can indicate whether the account used the prepaid mode or the prepaid mode during the historical payment process.
  • the account registration information can be used to reflect whether the account has the risk of batch registration, such as multiple accounts with the same device or multiple accounts with the same card.
  • a lot of account information can be obtained through the above-mentioned characteristic dimensions, such as whether the account age is long, whether the binding card age is long, whether the account security verification result is successful (for example, whether the account has completed KYC audit), whether the assets in the account are high (including Has tied the card or has a balance).
  • the aforementioned account history payment records and account history transaction modes can be combined to determine the corresponding account history credit information, such as whether the account has successfully paid for low-risk hydropower and coal transactions, and whether the account has a history of successful post-paid deductions Records etc.
  • the first risk control model can consider multiple account risk scenarios from various feature dimensions, and can more reliably identify whether the account has target risk.
  • Fig. 7 shows a schematic diagram of an example of feature dimensions of a second risk control model according to an embodiment of the present specification.
  • the characteristic dimensions of the second risk control model include: account country identification information, payment card country identification information, account binding card information, payment card binding account information, account history transaction information, and payment card history transaction information information.
  • the second risk control model can identify payment risks by using one or more (for example, all) combination of feature dimensions, and between different feature dimensions in the combination of feature dimensions. There can be corresponding weights.
  • the second risk control model can also identify cross-border cash out risks of credit cards.
  • the account home country identification information may reflect the home country of the account, such as the Hong Kong version of the wallet account.
  • the identification information of the country of origin of the payment card may reflect the country of origin of the payment card, for example, a CN dual-currency credit card is used in a transaction.
  • Account history transaction information can be used to reflect whether there are frequent and large offline consumptions in the account payment history.
  • the historical transaction information of the payment card can be used to reflect whether the current payment card has frequent large-value offline consumption.
  • the account binding information can be combined with the payment card binding account information to identify whether there is a single account binding multiple cards risk and a single card binding multiple accounts risk.
  • the second risk control model can identify multiple payment risk scenarios from various feature dimensions, and can more reliably identify whether the account has payment risk, especially the cross-border cashing risk of credit cards.
  • Fig. 8 shows a flowchart of an example of a secure business transaction method according to an embodiment of the present specification.
  • step 810 the account service request corresponding to the pre-shared post-paid transaction mode is obtained.
  • step 820 based on the first risk control model, it is determined whether the account corresponding to the account service request has target risk.
  • step 830 it is determined whether to convert the transaction mode corresponding to the account service request to the prepaid transaction mode according to the judgment result on the target risk. Specifically, if it is recognized that there is a target risk, the transaction mode corresponding to the account service request can be converted to the prepaid transaction mode. If it is recognized that there is no target type risk, you can continue to execute the first-share and then-pay transaction mode.
  • step 840 when the transaction mode corresponding to the account service request is converted to the prepaid transaction mode, it is determined whether there is a payment risk in the account service request based on the second risk control model.
  • step 850 it is determined whether to perform the payment operation for the account service request according to the judgment result regarding the payment risk.
  • each client executes the NSF transaction mode separately, and only converts to the prepaid transaction mode when it recognizes that the account has a target risk, which can achieve as little interruption to the NSF transaction mode as possible User experience.
  • Fig. 9 shows a schematic flowchart of an example of a secure business transaction method in a cross-border travel business application scenario according to an embodiment of the present specification.
  • multiple clients can install corresponding cross-border travel applets, and users can place orders for taxi services through the travel applets, that is, customers
  • the end sends an account business request to the server.
  • the client can be a payment method that implements the NSF mode by default.
  • the server 910 may perform risk management and control in the ordering link and risk identification and risk management in the payment link respectively.
  • the server 910 can identify whether the account has a target risk during the order placement stage.
  • the server 910 executes the prepaid mode and can send a payment mode conversion instruction to the client, so that the client can switch from the NSF mode to the prepaid mode. If it is detected that there is no target risk, both the server 910 and the client may continue to execute the NSF mode.
  • step 931 the server 910 can identify whether the account has a risk of embezzlement or cash out risk.
  • step 941 if there is a risk of account embezzlement or cash out risk, the payment operation is refused and the transaction fails.
  • step 943 if there is no risk of account embezzlement or cash out risk, a payment operation is performed.
  • the risk control side when a user places an order for a ride-hailing service, if a potential target risk is identified, the risk control side outputs a rejection, and the business side converts the corresponding decision to a prepayment method. As a result, the risk side still outputs accurate judgments for consumption on the business side. In addition, the conversion of post-payment to pre-payment on the business side can not only avoid target risks, but also does not affect the order situation. Compared with the risk control solution that directly rejects the risk control and leads to the failure of the order, this technical solution is more capable Take into account business value.
  • the risk of the order link and the risk of the payment link are coupled and affect each other, so comprehensive consideration needs to be taken when designing the corresponding evaluation indicators.
  • the average bad debt rate of the non-deductible bad debts is 2.5%.
  • statistics The corresponding bad debt rate of less than deductible every day in a month, and then determine the average value of the bad debt rate of less than deductible for one month.
  • the non-deductible bad debt rate is ⁇ 7.5% (3 times principle)
  • the proportion of prepaid orders take the business scenario of the Hong Kong wallet travel applet as an example. According to the data performance of one month after the business goes online, the proportion of prepaid orders is 15.2%. Prepaid order ratio, and then determine the average value of one month's prepaid order ratio.
  • the average risk control transaction failure rate is 1%, for example, within one month of statistics
  • the risk control transaction failure rate corresponding to each day is used to determine the average value of the risk control transaction failure rate for one month.
  • the risk aversion scheme is not adopted (that is, the risk control identifies various risks, and the scheme is strictly rejected). Instead, the user experience and business value are taken into account, and the target risk is prepaid. Way to release the risk.
  • a corresponding risk control evaluation system is also proposed. Compared with the current risk control evaluation system that emphasizes risk concentration and light user experience in related technologies, it can comprehensively weigh the user experience, business type and risk control. It has achieved the status of restricting risk control performance through multiple experience indicators.
  • Fig. 10 shows a structural block diagram of an example of a secure business transaction device according to an embodiment of this specification.
  • the secure business transaction device 1000 includes a transaction request acquisition unit 1010, a first risk control unit 1020, a transaction mode determination unit 1030, a second risk control unit 1040, a payment operation execution unit 1050, and a historical transaction data acquisition unit 1060 , Transaction risk control evaluation index determination unit 1070, risk control model optimization unit 1080.
  • the transaction request obtaining unit 1010 is configured to obtain an account service request.
  • the transaction request obtaining unit 910 reference may be made to the operation described with reference to step 110 in FIG. 1 above.
  • the first risk control unit 1020 is configured to determine whether the account corresponding to the account service request has target risk based on the first risk control model. For more details of the first risk control unit 920, reference may be made to the operation described with reference to step 120 in FIG. 1 above.
  • the characteristic dimensions of the first risk control model include: historical account payment records, historical account transaction patterns, account asset information, account aging information, account binding information, account registration information, and account Safety certification result.
  • the transaction mode determination unit 1030 is configured to determine whether to perform a prepaid transaction mode or a prepaid transaction mode for the account service request according to the judgment result on the target type risk. For more details of the transaction mode determining unit 1030, reference may be made to the operation described with reference to step 130 in FIG. 1 above.
  • the transaction mode determination unit 930 is further configured to execute a prepaid transaction mode for the account business request if the judgment result indicates that there is a target type risk; and if the judgment result indicates that there is no target type risk, Risks, the account business request to implement the first-share and then-pay transaction mode.
  • the second risk control unit 1040 is configured to determine whether the account service request has a payment risk based on the second risk control model when it is determined that the prepaid transaction mode is executed for the account service request. For more details of the second wind control unit 1040, reference may be made to the operation described with reference to step 240 in FIG. 2 above.
  • the payment risk includes the cross-border cash out risk of a credit card
  • the characteristic dimensions of the second risk control model include: account country identification information, payment card country identification information, account binding card Information, payment card binding account information, account historical transaction information and payment card historical transaction information.
  • the payment operation execution unit 1050 is configured to determine whether to perform the payment operation for the account service request according to the judgment result regarding the payment risk. For more details of the payment operation execution unit 1050, reference may be made to the operation described with reference to step 250 in FIG. 2 above.
  • the payment operation execution unit 1050 is further configured to refuse to perform the payment operation corresponding to the account service request if the judgment result indicates that there is a payment risk, and if the judgment result indicates that there is no payment risk, Then execute the account service request.
  • the historical transaction data acquisition unit 1060 is configured to acquire historical transaction data sets generated by multiple accounts in a set time period. For more details of the historical transaction data obtaining unit 1060, reference may be made to the operation described with reference to step 310 in FIG. 3 above.
  • the transaction risk control evaluation index determination unit 1070 is configured to determine a transaction risk control evaluation index based on the historical transaction data set.
  • the transaction risk control evaluation index includes a rate of non-deductible bad debts, a proportion of prepaid orders, and a failure rate of risk control transactions.
  • the transaction risk control evaluation index determination unit 970 also determines the transaction risk control evaluation index based on the preset transaction noise factor and the historical transaction data set.
  • the risk control model optimization unit 1080 is configured to determine whether to perform an optimization operation on the first risk control model and/or the second risk control model based on the transaction risk control evaluation index. For more details about the risk control model optimization unit 1080, reference may be made to the operation described with reference to step 330 in FIG. 3 above.
  • the risk control model optimization unit 1080 includes a risk control model parameter adjustment module (not shown) and/or a risk control model training module (not shown), the risk control model parameter adjustment module Is configured to determine whether to adjust feature dimensions and risk thresholds of the first risk control model and/or the second risk control model based on the transaction risk control evaluation index; and the risk control model training module is configured to Based on the transaction risk control evaluation index, it is determined whether to use the historical transaction data set to train the first risk control model and/or the second risk control model.
  • Fig. 11 shows a structural block diagram of an example of a secure business transaction device according to an embodiment of the present specification.
  • the secure business transaction device 1100 includes an NSF business request acquisition unit 1110, a first risk control unit 1120, a transaction mode conversion unit 1130, a second risk control unit 1140, and a payment operation execution unit 1150.
  • the NSF service request obtaining unit 1110 is configured to obtain the account service request corresponding to the pre-shared post-paid transaction mode. For more details of the NSF service request obtaining unit 1110, reference may be made to the operation described with reference to step 810 in FIG. 8 above.
  • the first risk control unit 1120 is configured to determine whether the account corresponding to the account service request has target risk based on the first risk control model. For more details of the first wind control unit 1120, reference may be made to the operation described with reference to step 820 in FIG. 8 above.
  • the transaction mode conversion unit 1130 is configured to determine whether to convert the transaction mode corresponding to the account service request to the prepaid transaction mode according to the judgment result of the target risk. For more details of the transaction mode conversion unit 1130, reference may be made to the operation described with reference to step 830 in FIG. 8 above.
  • the second risk control unit 1140 is configured to determine whether the account service request has a payment risk based on the second risk control model when the transaction mode corresponding to the account service request is converted to the prepaid transaction mode. For more details of the second risk control unit 1140, reference may be made to the operation described with reference to step 840 in FIG. 8 above.
  • the payment operation execution unit 1150 is configured to determine whether to perform the payment operation for the account service request according to the judgment result regarding the payment risk. For more details of the payment operation execution unit 1150, reference may be made to the operation described with reference to step 850 in FIG. 8 above.
  • the above secure business transaction device can be implemented by hardware, or by software or a combination of hardware and software.
  • the improvement of a technology can be clearly distinguished between hardware improvements (for example, improvements in circuit structures such as diodes, transistors, switches, etc.) or software improvements (improvements in method flow).
  • hardware improvements for example, improvements in circuit structures such as diodes, transistors, switches, etc.
  • software improvements improvements in method flow.
  • the improvement of many methods and processes of today can be regarded as a direct improvement of the hardware circuit structure.
  • Designers almost always get the corresponding hardware circuit structure by programming the improved method flow into the hardware circuit. Therefore, it cannot be said that the improvement of a method flow cannot be realized by the hardware entity module.
  • a programmable logic device for example, a Field Programmable Gate Array (Field Programmable Gate Array, FPGA)
  • PLD Programmable Logic Device
  • FPGA Field Programmable Gate Array
  • HDL Hardware Description Language
  • ABEL Advanced Boolean Expression Language
  • AHDL Altera Hardware Description Language
  • HDCal JHDL
  • Lava Lava
  • Lola MyHDL
  • PALASM RHDL
  • VHDL Very-High-Speed Integrated Circuit Hardware Description Language
  • Verilog Verilog
  • the controller can be implemented in any suitable manner.
  • the controller can take the form of, for example, a microprocessor or a processor and a computer-readable medium storing computer-readable program codes (such as software or firmware) executable by the (micro)processor. , Logic gates, switches, application specific integrated circuits (ASICs), programmable logic controllers and embedded microcontrollers. Examples of controllers include but are not limited to the following microcontrollers: ARC625D, Atmel AT91SAM, Microchip PIC18F26K20 and Silicon Labs C8051F320, the memory controller can also be implemented as part of the memory control logic.
  • controllers in addition to implementing the controller in a purely computer-readable program code manner, it is entirely possible to program the method steps to make the controller use logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded logic.
  • the same function can be realized in the form of a microcontroller or the like. Therefore, such a controller can be regarded as a hardware component, and the devices included in it for realizing various functions can also be regarded as a structure within the hardware component. Or even, the device for realizing various functions can be regarded as both a software module for realizing the method and a structure within a hardware component.
  • a typical implementation device is a computer.
  • the computer may be, for example, a personal computer, a laptop computer, a cell phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or Any combination of these devices.
  • These computer program instructions can also be stored in a computer-readable memory that can guide a computer or other programmable data processing equipment to work in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture including the instruction device.
  • the device implements the functions specified in one process or multiple processes in the flowchart and/or one block or multiple blocks in the block diagram.
  • These computer program instructions can also be loaded on a computer or other programmable data processing equipment, so that a series of operation steps are executed on the computer or other programmable equipment to produce computer-implemented processing, so as to execute on the computer or other programmable equipment.
  • the instructions provide steps for implementing the functions specified in one process or multiple processes in the flowchart and/or one block or multiple blocks in the block diagram.
  • the computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.
  • processors CPUs
  • input/output interfaces network interfaces
  • memory volatile and non-volatile memory
  • the memory may include non-permanent memory in computer readable media, 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 computer readable media.
  • RAM random access memory
  • ROM read-only memory
  • flash RAM flash memory
  • Computer-readable media include permanent and non-permanent, removable and non-removable media, and information storage can be realized by any method or technology.
  • the information can be computer-readable instructions, data structures, program modules, 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, CD-ROM, digital versatile disc (DVD) or other optical storage, Magnetic cartridges, magnetic tape storage or other magnetic storage devices or any other non-transmission media can be used to store information that can be accessed by computing devices. According to the definition in this article, computer-readable media does not include transitory media, such as modulated data signals and carrier waves.
  • program modules include routines, programs, objects, components, data structures, etc. that perform specific tasks or implement specific abstract data types.
  • This specification can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected through a communication network.
  • program modules can be located in local and remote computer storage media including storage devices.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Finance (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

本说明书实施例公开了一种安全业务交易方法、装置及电子设备，在该方法中，获取账户业务请求，并利用第一风控模型来判断账户业务请求所对应的账户是否存在目标类风险，由关于目标类风险的判断结果来确定针对账户业务请求是执行预付费交易模式还是先享后付费交易模式，可以降低类似NSF模式下的综合风险情况。

Description

安全业务交易 技术领域
本说明书实施例涉及计算机技术领域，尤其涉及一种安全业务交易方法、装置及电子设备。
背景技术
先享后付(Non-sufficient Fund,NSF)为一种提升用户服务体验及便利性的支付模式，其特点为让用户先享受服务之后再扣除相应款项。
目前，在NSF模式下，在识别到交易存在风险时，会直接拒绝进行交易。然而，如果风险识别错误，则可能会直接导致正常用户无法享受到服务，影响用户体验；此外，在NSF模式的支付阶段拒绝交易会导致坏账风险，亦即部分用户享受服务后会无法扣到相应钱款(即，扣不到款风险)，甚至会有不法分子批量注册账户在该场景下进行恶意操作，造成批量坏账。
针对上述问题，目前业界暂无较佳的解决方案。
发明内容
有鉴于此，本说明书实施例提供了一种安全业务交易方法、装置及电子设备，用于至少解决目前相关技术中在NSF模式下坏账率过高和正常用户可能无法享受到服务的问题。
本说明书实施例采用下述技术方案：
本说明书实施例提供一种安全业务交易方法，包括：获取账户业务请求；基于第一风控模型，判断所述账户业务请求所对应的账户是否存在目标类风险；根据关于所述目标类风险的判断结果，确定针对所述账户业务请求是执行预付费交易模式还是先享后付费交易模式。
本说明书实施例提供一种安全业务交易方法，包括：获取对应先享后付费交易模式的账户业务请求；基于第一风控模型，判断所述账户业务请求所对应的账户是否存在目标类风险；根据关于所述目标类风险的判断结果，确定是否将所述账户业务请求所对应的交易模式转换为预付费交易模式；当将对应所述账户业务请求的交易模式转换为预付费交易模式时，基于第二风控模型判断所述账户业务请求是否存在支付风险；根据关于所述支付风险的判断结果，确定是否执行针对所述账户业务请求的付费操作。
本说明书实施例还提供一种安全业务交易装置，包括：业务请求获取单元，获取账户业务请求；第一风控单元，基于第一风控模型，判断所述账户业务请求所对应的账户是否存在目标类风险；交易模式确定单元，根据关于所述目标类风险的判断结果，确定针对所述账户业务请求是执行预付费交易模式还是先享后付费交易模式。
本说明书实施例还提供一种安全业务交易装置，包括：NSF业务请求获取单元，获取对应先享后付费交易模式的账户业务请求；第一风控单元，基于第一风控模型，判断所述账户业务请求所对应的账户是否存在目标类风险；交易模式转换单元，根据关于所述目标类风险的判断结果，确定是否将所述账户业务请求所对应的交易模式转换为预付费交易模式；第二风控单元，当将对应所述账户业务请求的交易模式转换为预付费交易模式时，基于第二风控模型判断所述账户业务请求是否存在支付风险；付费操作执行单元，根据关于所述支付风险的判断结果，确定是否执行针对所述账户业务请求的付费操 作。
本说明书实施例还提供一种电子设备，包括：至少一个处理器；以及存储器，所述存储器存储指令，当所述指令被所述至少一个处理器执行时，使得所述至少一个处理器执行如上述的方法。
本说明书实施例采用的上述至少一个技术方案能够达到以下有益效果：
在得到账户业务请求时，利用第一风控模型来判断是否存在目标类风险(或，也可被称为“扣不到款风险”)，并且根据是否存在目标类风险来确定是执行预付费交易模式还是执行先享后付费交易模式，而不会直接拒绝交易，可以解决对应风险识别错误的正常用户无法享受服务的问题，可以保障用户群整体的服务体验和业务价值。
附图说明
此处所说明的附图用来提供对本说明书实施例的进一步理解，构成本说明书的一部分，本说明书的示意性实施例及其说明用于解释本说明书，并不构成对本说明书的不当限定。在附图中：
图1示出了根据本说明书实施例的安全业务交易方法的一示例的流程图；
图2示出了根据本说明书实施例的安全业务交易方法的一示例的流程图；
图3示出了根据本说明书实施例的安全业务交易方法的一示例的流程图；
图4示出了根据本说明书实施例的确定交易风控评价指标的一示例的流程图；
图5示出了根据本说明书实施例的模型优化的一示例的示意图；
图6示出了根据本说明书实施例的第一风控模型的特征维度的一示例的示意图；
图7示出了根据本说明书实施例的第二风控模型的特征维度的一示例的示意图；
图8示出了根据本说明书实施例的安全业务交易方法的一示例的流程图；
图9示出了根据本说明书实施例的在跨境出行类业务应用场景下的安全业务交易方法的一示例的流程示意图；
图10示出了根据本说明书实施例的安全业务交易装置的一示例的结构框图；
图11示出了根据本说明书实施例的安全业务交易装置的一示例的结构框图。
具体实施方式
随着互联网公司业务的拓展，不少业务已经对境外用户开放，例如上线一些跨境APP(或，跨境小程序)，以方便境外用户在国内使用，例如跨境场景的出行类小程序可以满足香港钱包用户在大陆打车的业务核心诉求。在该跨境场景下，客户端用户是香港用户，运营端商户是出行类小程序(例如，滴滴打车)的运营商，发生地点在大陆地区，交易模式为先享后付模式(即，NSF模式)，这样香港用户能够使用钱包中的出行类小程序在大陆地区享受NSF的打车服务。
但是，在跨境新场景下的交易存在多种风险耦合，例如目标类风险(例如，设定目标的“扣不到款风险”)和跨境支付风险(例如，套现、账户盗用和绑卡盗用风险等)。需说明的是，由于香港法律允许***套现(其线下ATM机支持***取现)，故香港钱包业务端针对外卡限制较松。然而，按照国内法律法规，国内***套现是不允许的行为，一些大陆用户会使用CN双币***绑定香港钱包进行套现交易(例如，在国 内线下支付出行类业务订单)，这也是不被允许的。
为使本说明书的目的、技术方案和优点更加清楚，下面将结合本说明书具体实施例及相应的附图对本说明书技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本说明书一部分实施例，而不是全部的实施例。基于本说明书中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本说明书实施的范围。
如本文中使用的，术语“包括”及其变型表示开放的术语，含义是“包括但不限于”。术语“基于”表示“至少部分地基于”。术语“一个实施例”和“一实施例”表示“至少一个实施例”。术语“另一个实施例”表示“至少一个其他实施例”。术语“第一”、“第二”等可以指代不同的或相同的对象。下面可以包括其他的定义，无论是明确的还是隐含的。除非上下文中明确地指明，否则一个术语的定义在整个说明书中是一致的。
在本文中，术语“业务交易”表示业务双方以货币及服务为媒介的价值的交换，例如交易可以表示从发起业务订单开始到完成付费结果的整个过程，并可以包括订单环节和支付环节。术语“目标类风险”可以表示在NSF交易之后，商家主动向账户指定绑卡发起扣款支付且支付失败的风险，以及用户很长时间(例如，超过一个月)不去支付NSF交易订单的钱款的风险，即扣不到款风险。
图1示出了根据本说明书实施例的安全业务交易方法的一示例的流程图。关于本说明书实施例方法的执行主体，可以是直接负责提供业务服务(例如，出行业务服务)的服务端，也可以是与业务相关联的第三方服务端(例如，安装出行类小程序的钱包应用平台的服务端)，且都属于本说明书的实施范围内。
如图1所示，在步骤110中，获取账户业务请求。
具体地，服务端可以从客户端接收账户业务请求。在本说明书实施例的一个示例中，账户业务请求可以是针对出行类业务的账户业务请求，例如用户通过操作钱包客户端上的出行类小程序来向服务端发出账户业务请求。
在步骤120中，基于第一风控模型，判断账户业务请求所对应的账户是否存在目标类风险。在本说明书实施例的一个示例中，可以使用已有的针对目标类风险的风控模型来作为第一风控模型，对账户信用进行识别，从而得到相应的目标类风险。在本说明书实施例的另一示例中，第一风控模型还可以是在下文中其他部分所提出的全新的风控模型来识别目标类风险，具体细节将在下文中展开。
在步骤130中，根据关于目标类风险的判断结果，确定针对账户业务请求是执行预付费交易模式还是先享后付费交易模式。这里，可以是直接根据目标类风险来确定相应的付费交易模式，还可以是结合预设的一个或多个付费模式影响因子来进行综合判断，例如根据运营策略可以针对白名单用户直接开放先享后付费交易模式。
在本说明书实施例的一个示例中，如果判断结果指示存在目标类风险，则针对账户业务请求执行预付费交易模式，如果判断结果指示不存在目标类风险，则针对账户业务请求执行先享后付费交易模式。由此，通过转换付费交易模式继续交易而不是直接终止交易，可以解决用户因信用识别或低信用而无法享受服务的问题，可以保障用户群整体的服务体验和业务价值。
图2示出了根据本说明书实施例的安全业务交易方法的一示例的流程图。
在步骤210中，获取账户业务请求。
在步骤220中，基于第一风控模型，判断账户业务请求所对应的账户是否存在目标类风险。
在步骤230中，根据关于目标类风险的判断结果，确定针对账户业务请求是执行预付费交易模式还是先享后付费交易模式。关于步骤210-230的细节和效果，可以参照上面图1中关于步骤110-130的描述，在此便不赘述。
在步骤240中，当确定针对所述账户业务请求执行预付费交易模式时，基于第二风控模型判断账户业务请求是否存在支付风险。这里，支付风险(或付费风险)可以表示在支付过程中会产生的各种风险，例如盗卡风险、盗账户风险、套现风险等。在本说明书实施例的一个示例中，可以使用已有的针对支付风险(或，付费风险)的风控模型来作为第二风控模型，对当前支付操作的安全性进行识别，从而得到相应的支付风险。在本说明书实施例的另一示例中，第二风控模型还可以是在下文中其他部分所提出的全新的风控模型来识别支付风险，具体细节将在下文中展开。
应理解的是，无论是预付费交易模式还是先享后付费交易模式，都需要在进行付费交易时识别支付风险。具体地，在先享后付费交易模式下，在用户享受了服务(例如，出行服务、物品租赁服务等)之后再进行付费交易，此时识别相应的支付风险。另外，在预付费交易模式下，在用户未享受服务时进行付费交易，此时识别相应的支付风险。
在步骤250中，根据关于支付风险的判断结果，确定是否执行针对账户业务请求的付费操作。这里，可以直接根据支付风险来确定是否执行相应的付费操作，还可以结合预设的一个或多个预设的核身方式来进行综合判断，例如在识别到存在支付风险时激发人脸核身方式，并可以结合人脸核身结果来确定是否执行相应的付费操作。
此外，当确定针对账户业务请求执行先享后付费交易模式时，可以直接在用户享受完服务之后执行支付操作，也还可以基于第二风控模型判断账户业务请求是否存在支付风险，并根据关于支付风险的判断结果来确定是否执行针对账户业务请求的付费操作，且都属于本说明书的实施范围内。
关于上述的步骤240的细节，在本说明书实施例的一个示例中，如果判断结果指示存在支付风险，则拒绝执行针对账户业务请求的付费操作，以及如果判断结果指示不存在支付风险，则执行针对账户业务请求的付费操作。由此，针对预付费方式的账户，在提供服务前就进行支付风险识别，当存在支付风险时可以直接拒绝执行付费操作并拒绝提供服务，可以有效解决NSF模式中在提供服务之后的坏账问题。
在本说明书实施例中，利用第一风控模型确定相应的付费交易模式，并在预付费的付费支付阶段利用第二风控模型确定的支付风险来确定是否执行相应的付费操作。由此，在保障NSF模式的服务体验的同时，还可以有效降低类似NSF模式下的综合风险情况。
图3示出了根据本说明书实施例的安全业务交易方法的一示例的流程图。
如图3所示，在步骤310中，获取多个账户在设定时间段所产生的历史交易数据集。例如，可以获取所有账户在过去一个月内所产生的历史交易数据集。这里，历史交易数据可以包括与交易相关的任意的非敏感数据(例如，不含账户密码)，例如交易付费模式、交易结果和交易金额等。
在步骤320中，基于历史交易数据集确定交易风控评价指标。这里，交易风控评价指标包括扣不到款坏账率、预付费订单比例和风控交易失败率。
在本说明书实施例的一个示例中，扣不到款坏账率＝(扣款失败总额/总交易金额)。具体地，可以根据各个历史交易数据中的金额来确定总交易金额，从历史交易数据集中筛选扣不到款交易数据子集，并统计各个扣不到款交易数据中的金额以确定扣款失败总额。因此，可以通过该指标来约束风控决策(例如，第一风控模型和第二风控模型)。
在本说明书实施例的一个示例中，预付费订单比例＝(预付费交易量级/总交易量级)。 具体地，可以根据历史交易数据的数量来确定总交易量级，并根据具有预付费方式的各个历史交易数据来确定预付费交易量级。这里，通过预付费订单比例，可以衡量风控打扰情况。对于运营方来说，先享后付服务模式是其特色，如果一昧地强调风险保护而将该模式转换成传统先付后享模式，是不利业务发展的。因此，可以通过该指标来约束风控决策(例如，第一风控模型)。
在本说明书实施例的一个示例中，风控交易失败率＝(风控导致的失败交易量级/总交易量级)。这里，风控导致的失败交易一方面可以包括因第二风控模型所输出的判断结果而拒绝账户业务请求所对应的交易，另一方面还可以包括在风控模型拒绝而产生风控挑战(或，核身操作)，风控挑战方式包括但不限于支付密码、OTP(One-time Password,动态口令)、3D校验等，所造成的失败交易也需要归入风控交易失败率的求算公式的分子部分中。因此，可以通过该指标来约束风控决策(例如，第二风控模型)。
在步骤330中，基于交易风控评价指标，确定是否对第一风控模型和/或第二风控模型执行优化操作。这样，通过交易风控评价指标可以对风控模型的性能进行评价，实现对风控模型有指导性的优化操作。例如，当扣不到款坏账率过大时，可以收紧风控决策以降低扣不到款坏账率。
图4示出了根据本说明书实施例的确定交易风控评价指标的一示例的流程图。
如图4所示，在步骤410中，获取多个账户在设定时间段所产生的历史交易数据集。
在步骤420中，基于预设的交易噪音因子和历史交易数据集，确定交易风控评价指标。需说明的是，在一些情况下，会存在影响交易真实数据量的交易噪音因子，其属于非风险因素，而应当将其剔除在针对风控策略的交易风控评价指标的影响因素之外。这里，交易噪音因子可以是由运营方输入的。
举例来说，因宏观环境因素(例如，疫情)而导致特定时间内的总交易量级会出现大幅下降，导致扣不到款率显著上升，其属于纯业务根因而导致的正常波动。此时，在计算扣不到款率时，除了要考虑扣款失败交易与总交易之间的相对值外，还可能需要考虑扣款失败交易的数量，例如总量过小的扣款失败交易应不足以导致扣不到款率超过设定阈值。
图5示出了根据本说明书实施例的模型优化的一示例的示意图。
如图5所示，基于交易风控评价指标，确定是否调整第一风控模型和/或第二风控模型的特征维度和风险阈值；和/或，基于交易风控评价指标，确定是否利用历史交易数据集合来训练第一风控模型和/或第二风控模型。示例性地，如果扣不到款坏账率过高，则可以收紧风控决策，例如降低风险阈值、完善特征维度和对风控模型进行训练以优化风控模型的风险识别性能等。关于第一风控模型和/或第二风控模型利用历史交易数据集合来进行训练的具体细节，可以参照目前相关技术中的模型训练过程，在此便不赘述。
图6示出了根据本说明书实施例的第一风控模型的特征维度的一示例的示意图。
如图6所示，第一风控模型的特征维度包括：账户历史支付记录、账户历史交易模式、账户资产信息、账龄信息、账户绑卡信息、账户注册信息和账户安全认证结果。在本说明书实施例的一个示例中，第一风控模型可以通过使用其中的一个或多个(例如，所有的)特征维度的组合来识别目标类风险的一个或多个风险场景，并且特征维度组合中的不同特征维度之间可以存在相应的权重。
具体地，账户历史支付记录可以表示账户在历史的支付过程中是否支付成功。账户历史交易模式可以表示账户在历史的支付过程中是使用了预付费模式还是先享后付费模式。账户注册信息可以用来反映账户是否有批量注册风险，例如同设备多账户或同卡 多账户等。此外，通过上述的特征维度还可以得到许多账户信息，例如账龄是否长、绑定卡龄是否长、账户安全认证结果是否成功(例如，账户是否完成KYC审核)、账户内资产是否高(包括已绑卡或有余额)。此外，还可以将上述的账户历史支付记录和账户历史交易模式进行组合，以确定相应的账户历史信用信息，例如账户是否成功支付过低危水电煤交易、账户是否存在后付费扣款成功的历史记录等。
在本说明书实施例中，第一风控模型可以从各个特征维度来考量多种账户风险场景，可以较可靠地识别出账户是否存在目标类风险。
图7示出了根据本说明书实施例的第二风控模型的特征维度的一示例的示意图。
如图7所示，第二风控模型的特征维度包括：账户归属国识别信息、支付卡归属国识别信息、账户绑卡信息、支付卡绑定账户信息、账户历史交易信息和支付卡历史交易信息。在本说明书实施例的一个示例中，第二风控模型可以通过使用其中的一个或多个(例如，所有的)特征维度的组合来识别支付风险，并且特征维度组合中的不同特征维度之间可以存在相应的权重。这里，第二风控模型除了能够识别常见的支付风险之外，还可以识别***跨境套现风险。
具体地，账户归属国识别信息可以反映账户的归属国家，例如香港版本的钱包账户。支付卡归属国识别信息可以反映支付卡的归属国家，例如当笔交易使用了CN双币***。账户历史交易信息，可以用来反映账户支付历史中是否存在频繁大额线下消费。支付卡历史交易信息，可以用来反映当前支付的卡片是否存在频繁大额线下消费。此外，可以将账户绑卡信息和支付卡绑定账户信息进行结合，识别是否存在单账户绑多卡风险和单卡绑多户风险。
在本说明书实施例中，第二风控模型可以从各个特征维度来识别多种支付风险场景，可以较可靠地识别出账户是否存在支付风险，尤其是***跨境套现风险。
图8示出了根据本说明书实施例的安全业务交易方法的一示例的流程图。
如图8所示，在步骤810中，获取对应先享后付费交易模式的账户业务请求。
在步骤820中，基于第一风控模型，判断账户业务请求所对应的账户是否存在目标类风险。
在步骤830中，根据关于目标类风险的判断结果，确定是否将账户业务请求所对应的交易模式转换为预付费交易模式。具体地，如果识别到存在目标类风险时，则可以将账户业务请求所对应的交易模式转换为预付费交易模式。如果识别到不存在目标类风险时，则可以继续执行先享后付费交易模式。
在步骤840中，当将对应账户业务请求的交易模式转换为预付费交易模式时，基于第二风控模型判断账户业务请求是否存在支付风险。
在步骤850中，根据关于支付风险的判断结果，确定是否执行针对账户业务请求的付费操作。
在本说明书实施例所提供的业务场景下，各个客户端分别执行NSF交易模式，并只有在识别到账户存在目标类风险时才转换为预付费交易模式，可以实现尽可能少地打扰NSF交易模式下的用户体验。
图9示出了根据本说明书实施例的在跨境出行类业务应用场景下的安全业务交易方法的一示例的流程示意图。
如图9所示，多个客户端(例如客户端901、903和905)上可以分别安装了相应的跨境出行类小程序，用户可以通过该出行类小程序下单进行打车服务，即客户端向服务 端发送账户业务请求。这里，客户端可以是默认是执行NSF模式的付费方式的。
响应于该账户业务请求，服务端910可以分别进行下单环节的风险管控和支付环节进行风险识别和风险管控。在步骤921中，服务端910可以在下单阶段识别该账户是否存在目标类风险。在步骤923中，如果检测到存在目标类风险，则服务端910执行预付费模式并可以向客户端发送付费模式转换指令，以使得客户端从NSF模式转换到预付费模式。如果检测到不存在目标类风险，则服务端910和客户端可以都继续执行NSF模式。
在支付环节，在步骤931中，服务端910可以识别账户是否存在盗用风险或套现风险。在步骤941中，如果存在账户盗用风险或套现风险，则拒绝执行付费操作而致使交易失败。在步骤943中，如果不存在账户盗用风险或套现风险，则执行付费操作。
在本说明书的实施例中，在用户下单进行打车服务时，如果识别到潜在目标类风险，则风控侧输出拒绝，业务侧将相应决策转换成预付费方式。由此，风险侧仍然输出准确判断，并供业务侧消费。此外，在业务侧将后付费转换成预付费，既能规避目标类风险，又能不影响下单情况，相比于直接风控拒绝而导致下单失败的风控方案，本技术方案更能够兼顾业务价值。
在本说明书实施例中，下单环节风险与支付环节风险耦合，互相影响，因此在设计相应的评价指标时需综合考虑。这里，可以设定交易风控评价指标，包括扣不到款坏账率、预付费订单比例和风控交易失败率。
下面将结合示例来描述各个交易风控评价指标的风险判断过程。
关于扣不到款坏账率的风险判断过程，以香港钱包出行类小程序的业务场景为例，可以根据业务上线后一个月的数据表现得到扣不到款坏账率平均值为2.5％，例如统计一个月内每天所对应的扣不到款坏账率，进而确定出一个月的扣不到款坏账率平均值。当扣不到款坏账率≥7.5％时(3倍原则)，则表示整体风险较高，需重点关注是否受到批量攻击或集中个案，并可以相应地对第一风控模型和第二风控模型的参数进行调整，或利用历史交易数据集合来对风控模型进行训练优化。
此外，应说明的是，由于业务受宏观环境影响较大(如疫情等)，特定时间内交易量级会出现大幅下滑，导致扣不到款率显著上升，此为非风险因素，纯业务根因导致的正常波动。此时，除了应关注扣不到款率以外，还需结合交易噪音影响因子对分母的影响来进行综合风险判断。
关于预付费订单比例的风险判断过程，以香港钱包出行类小程序的业务场景为例，根据业务上线后一个月的数据表现得到预付费订单比例为15.2％，例如统计一个月内每天所对应的预付费订单比例，进而确定出一个月的预付费订单比例平均值。
当预付费订单比例≥45％时(3倍原则)，则表示整体打扰较高，需重点关注是否需要进行策略调优，例如将风控模型(尤其是第一风控模型)的参数进行调整优化，并还可以利用历史交易数据集合来对风控模型进行训练优化。
应理解的是，运营端在实际进行业务运营时，由于业务上线初期黑样本不足，出于保障业务的原因，会将较多后付订单通过预付的方式来释放风险。进而，当业务运行一段时间后，可以逐步放开策略并观察带来的风险敞口。
关于风控交易失败率的风险判断过程，以香港钱包出行类小程序的业务场景为例，根据业务上线后一个月的数据表现得到风控交易失败率平均值为1％，例如统计一个月内每天所对应的风控交易失败率，进而确定出一个月的风控交易失败率平均值。
当风控交易失败率≥3％时(3倍原则)，则表示整体打扰较高，需重点关注是否需 要进行策略调优，例如将风控模型(尤其是第二风控模型)的参数进行调整优化，并还可以利用历史交易数据集合来对风控模型进行训练优化。
应理解的是，当出现盗用批量攻击或者政府监管尺度对于套现行为收紧时，势必会相应收紧风控决策，导致风控交易失败率升高，此时可以结合具体情况进行分析。
通过本说明书实施例，不仅能够覆盖国内本对本风险场景，还能够覆盖新型跨境风险场景，覆盖风险范围较广。此外，在本实施例中并未采取偏风险厌恶的方案(即风控识别各类风险，都采取从严拒绝的方案)，而是兼顾了用户体验和业务价值，将目标类风险通过预付费方式进行风险释放。另外，在本实施例中还提出了相应的风控评价体系，相比于目前相关技术中重风险浓度而轻用户体验的风控评价体系，能够综合权衡用户体验、业务类型与风控之间的地位，并实现了通过多个体验类指标来约束风控表现。
图10示出了根据本说明书实施例的安全业务交易装置的一示例的结构框图。
如图10所示，安全业务交易装置1000包括交易请求获取单元1010、第一风控单元1020、交易模式确定单元1030、第二风控单元1040、付费操作执行单元1050、历史交易数据获取单元1060、交易风控评价指标确定单元1070、风控模型优化单元1080。
交易请求获取单元1010被配置为获取账户业务请求。关于交易请求获取单元910的更多细节，可以参照上面图1中参考步骤110所描述的操作。
第一风控单元1020被配置为基于第一风控模型，判断所述账户业务请求所对应的账户是否存在目标类风险。关于第一风控单元920的更多细节，可以参照上面图1中参考步骤120所描述的操作。
在本说明书实施例的一个示例中，所述第一风控模型的特征维度包括：账户历史支付记录、账户历史交易模式、账户资产信息、账龄信息、账户绑卡信息、账户注册信息和账户安全认证结果。
交易模式确定单元1030被配置为根据关于所述目标类风险的判断结果，确定针对所述账户业务请求是执行预付费交易模式还是先享后付费交易模式。关于交易模式确定单元1030的更多细节，可以参照上面图1中参考步骤130所描述的操作。
在本说明书实施例的一个示例中，交易模式确定单元930还被配置为如果判断结果指示存在目标类风险，则针对所述账户业务请求执行预付费交易模式；以及如果判断结果指示不存在目标类风险，则针对所述账户业务请求执行先享后付费交易模式。
第二风控单元1040被配置为当确定针对所述账户业务请求执行预付费交易模式时，基于第二风控模型判断所述账户业务请求是否存在支付风险。关于第二风控单元1040的更多细节，可以参照上面图2中参考步骤240所描述的操作。
在本说明书实施例的一个示例中，所述支付风险包括***跨境套现风险，以及所述第二风控模型的特征维度包括：账户归属国识别信息、支付卡归属国识别信息、账户绑卡信息、支付卡绑定账户信息、账户历史交易信息和支付卡历史交易信息。
付费操作执行单元1050被配置为根据关于所述支付风险的判断结果，确定是否执行针对所述账户业务请求的付费操作。关于付费操作执行单元1050的更多细节，可以参照上面图2中参考步骤250所描述的操作。
在本说明书实施例的一个示例中，付费操作执行单元1050还被配置为如果判断结果指示存在支付风险，则拒绝执行对应所述账户业务请求的付费操作，以及如果判断结果指示不存在支付风险，则执行所述账户业务请求。
历史交易数据获取单元1060被配置为获取多个账户在设定时间段所产生的历史 交易数据集。关于历史交易数据获取单元1060的更多细节，可以参照上面图3中参考步骤310所描述的操作。
交易风控评价指标确定单元1070被配置为基于所述历史交易数据集确定交易风控评价指标，所述交易风控评价指标包括扣不到款坏账率、预付费订单比例和风控交易失败率。关于交易风控评价指标确定单元1070的更多细节，可以参照上面图3中参考步骤320所描述的操作。
在本说明书实施例的一个示例中，交易风控评价指标确定单元970还基于预设的交易噪音因子和所述历史交易数据集，确定交易风控评价指标。
风控模型优化单元1080被配置为基于所述交易风控评价指标，确定是否对所述第一风控模型和/或所述第二风控模型执行优化操作。关于风控模型优化单元1080的更多细节，可以参照上面图3中参考步骤330所描述的操作。
在本说明书实施例的一个示例中，风控模型优化单元1080包括风控模型参数调整模块(未示出)和/或风控模型训练模块(未示出)，所述风控模型参数调整模块被配置为基于所述交易风控评价指标，确定是否调整所述第一风控模型和/或所述第二风控模型的特征维度和风险阈值；以及所述风控模型训练模块被配置为基于所述交易风控评价指标，确定是否利用所述历史交易数据集合来训练所述第一风控模型和/或所述第二风控模型。
需说明的是，如上所描述的装置1000中的部分单元在一些应用场景下是非必需的或可选的，例如历史交易数据获取单元1060、交易风控评价指标确定单元1070、风控模型优化单元1080在一些示例中可以不被保留。
图11示出了根据本说明书实施例的安全业务交易装置的一示例的结构框图。
如图11所示，安全业务交易装置1100包括NSF业务请求获取单元1110、第一风控单元1120、交易模式转换单元1130、第二风控单元1140和付费操作执行单元1150。
NSF业务请求获取单元1110被配置为获取对应先享后付费交易模式的账户业务请求。关于NSF业务请求获取单元1110的更多细节，可以参照上面图8中参考步骤810所描述的操作。
第一风控单元1120被配置为基于第一风控模型，判断所述账户业务请求所对应的账户是否存在目标类风险。关于第一风控单元1120的更多细节，可以参照上面图8中参考步骤820所描述的操作。
交易模式转换单元1130被配置为根据关于所述目标类风险的判断结果，确定是否将所述账户业务请求所对应的交易模式转换为预付费交易模式。关于交易模式转换单元1130的更多细节，可以参照上面图8中参考步骤830所描述的操作。
第二风控单元1140被配置为当将对应所述账户业务请求的交易模式转换为预付费交易模式时，基于第二风控模型判断所述账户业务请求是否存在支付风险。关于第二风控单元1140的更多细节，可以参照上面图8中参考步骤840所描述的操作。
付费操作执行单元1150被配置为根据关于所述支付风险的判断结果，确定是否执行针对所述账户业务请求的付费操作。关于付费操作执行单元1150的更多细节，可以参照上面图8中参考步骤850所描述的操作。
如上参照图1到图11，对根据本说明书实施例的安全业务交易方法及装置的实施例进行了描述。在以上对方法实施例的描述中所提及的细节，同样适用于本说明书装置的实施例。上面的安全业务交易装置可以采用硬件实现，也可以采用软件或者硬件和 软件的组合来实现。
在20世纪90年代，对于一个技术的改进可以很明显地区分是硬件上的改进(例如，对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而，随着技术的发展，当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此，不能说一个方法流程的改进就不能用硬件实体模块来实现。例如，可编程逻辑器件(Programmable Logic Device,PLD)(例如现场可编程门阵列(Field Programmable Gate Array，FPGA))就是这样一种集成电路，其逻辑功能由用户对器件编程来确定。由设计人员自行编程来把一个数字***“集成”在一片PLD上，而不需要请芯片制造厂商来设计和制作专用的集成电路芯片。而且，如今，取代手工地制作集成电路芯片，这种编程也多半改用“逻辑编译器(logic compiler)”软件来实现，它与程序开发撰写时所用的软件编译器相类似，而要编译之前的原始代码也得用特定的编程语言来撰写，此称之为硬件描述语言(Hardware Description Language，HDL)，而HDL也并非仅有一种，而是有许多种，如ABEL(Advanced Boolean Expression Language)、AHDL(Altera Hardware Description Language)、Confluence、CUPL(Cornell University Programming Language)、HDCal、JHDL(Java Hardware Description Language)、Lava、Lola、MyHDL、PALASM、RHDL(Ruby Hardware Description Language)等，目前最普遍使用的是VHDL(Very-High-Speed Integrated Circuit Hardware Description Language)与Verilog。本领域技术人员也应该清楚，只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中，就可以很容易得到实现该逻辑方法流程的硬件电路。
控制器可以按任何适当的方式实现，例如，控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(Application Specific Integrated Circuit，ASIC)、可编程逻辑控制器和嵌入微控制器的形式，控制器的例子包括但不限于以下微控制器：ARC 625D、Atmel AT91SAM、Microchip PIC18F26K20以及Silicone Labs C8051F320，存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。
上述实施例阐明的***、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机。具体的，计算机例如可以为个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。
为了描述的方便，描述以上装置时以功能分为各种单元分别描述。当然，在实施本说明书时可以把各单元的功能在同一个或多个软件和/或硬件中实现。
本领域内的技术人员应明白，本说明书的实施例可提供为方法、***、或计算机程序产品。因此，本说明书可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本说明书实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本说明书是参照根据本说明书实施例的方法、设备(***)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带式磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。
还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
本说明书实施例可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本说明书，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。
本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于***实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
以上所述仅为本说明书的实施例而已，并不用于限制本说明书。对于本领域技术人员来说，本说明书可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims (23)

  1. 一种安全业务交易方法，包括：
    获取账户业务请求；
    基于第一风控模型，判断所述账户业务请求所对应的账户是否存在目标类风险；
    根据关于所述目标类风险的判断结果，确定针对所述账户业务请求是执行预付费交易模式还是先享后付费交易模式。
  2. 如权利要求1所述的安全业务交易方法，还包括：
    当确定针对所述账户业务请求执行预付费交易模式时，基于第二风控模型判断所述账户业务请求是否存在支付风险；
    根据关于所述支付风险的判断结果，确定是否执行针对所述账户业务请求的付费操作。
  3. 如权利要求2所述的安全业务交易方法，其中，根据关于所述支付风险的判断结果，确定是否执行针对所述账户业务请求的付费操作，具体包括：
    如果判断结果指示存在支付风险，则拒绝执行针对所述账户业务请求的付费操作；以及
    如果判断结果指示不存在支付风险，则执行针对所述账户业务请求的付费操作。
  4. 如权利要求2所述的安全业务交易方法，其中，所述支付风险包括***跨境套现风险，以及所述第二风控模型的特征维度包括：账户归属国识别信息、支付卡归属国识别信息、账户绑卡信息、支付卡绑定账户信息、账户历史交易信息和支付卡历史交易信息。
  5. 如权利要求1所述的安全业务交易方法，其中，根据关于所述目标类风险的判断结果，确定针对所述账户业务请求是执行预付费交易模式还是先享后付费交易模式包括：
    如果判断结果指示存在目标类风险，则针对所述账户业务请求执行预付费交易模式；以及
    如果判断结果指示不存在目标类风险，则针对所述账户业务请求执行先享后付费交易模式。
  6. 如权利要求1所述的安全业务交易方法，还包括：
    获取多个账户在设定时间段所产生的历史交易数据集；
    基于所述历史交易数据集确定交易风控评价指标，所述交易风控评价指标包括扣不到款坏账率、预付费订单比例和风控交易失败率；
    基于所述交易风控评价指标，确定是否对所述第一风控模型和/或所述第二风控模型执行优化操作。
  7. 如权利要求6所述的安全业务交易方法，其中，基于所述交易风控评价指标，确定是否对所述第一风控模型和/或所述第二风控模型执行优化操作，具体包括：
    基于所述交易风控评价指标，确定是否调整所述第一风控模型和/或所述第二风控模型的特征维度和风险阈值；和/或
    基于所述交易风控评价指标，确定是否利用所述历史交易数据集合来训练所述第一风控模型和/或所述第二风控模型。
  8. 如权利要求6所述的安全业务交易方法，其中，基于所述历史交易数据集确定交易风控评价指标，具体包括：
    基于预设的交易噪音因子和所述历史交易数据集，确定交易风控评价指标。
  9. 如权利要求1所述的安全业务交易方法，其中，所述第一风控模型的特征维度包括：账户历史支付记录、账户历史交易模式、账户资产信息、账龄信息、账户绑卡信息、账户注册信息和账户安全认证结果。
  10. 如权利要求1-9中任一所述的安全业务交易方法，其中，所述账户业务请求包 括针对出行类业务的账户业务请求。
  11. 一种安全业务交易方法，包括：
    获取对应先享后付费交易模式的账户业务请求；
    基于第一风控模型，判断所述账户业务请求所对应的账户是否存在目标类风险；
    根据关于所述目标类风险的判断结果，确定是否将所述账户业务请求所对应的交易模式转换为预付费交易模式；
    当将对应所述账户业务请求的交易模式转换为预付费交易模式时，基于第二风控模型判断所述账户业务请求是否存在支付风险；
    根据关于所述支付风险的判断结果，确定是否执行针对所述账户业务请求的付费操作。
  12. 一种安全业务交易装置，包括：
    业务请求获取单元，获取账户业务请求；
    第一风控单元，基于第一风控模型，判断所述账户业务请求所对应的账户是否存在目标类风险；
    交易模式确定单元，根据关于所述目标类风险的判断结果，确定针对所述账户业务请求是执行预付费交易模式还是先享后付费交易模式。
  13. 如权利要求12所述的安全业务交易装置，还包括：
    第二风控单元，当确定针对所述账户业务请求执行预付费交易模式时，基于第二风控模型判断所述账户业务请求是否存在支付风险；
    付费操作执行单元，根据关于所述支付风险的判断结果，确定是否执行针对所述账户业务请求的付费操作。
  14. 如权利要求13所述的安全业务交易装置，其中，所述付费操作执行单元：
    如果判断结果指示存在支付风险，则拒绝执行针对所述账户业务请求的付费操作；以及
    如果判断结果指示不存在支付风险，则执行针对所述账户业务请求的付费操作。
  15. 如权利要求13所述的安全业务交易装置，其中，所述支付风险包括***跨境套现风险，以及所述第二风控模型的特征维度包括：账户归属国识别信息、支付卡归属国识别信息、账户绑卡信息、支付卡绑定账户信息、账户历史交易信息和支付卡历史交易信息。
  16. 如权利要求12所述的安全业务交易装置，其中，所述交易模式确定单元：
    如果判断结果指示存在目标类风险，则针对所述账户业务请求执行预付费交易模式；以及
    如果判断结果指示不存在目标类风险，则针对所述账户业务请求执行先享后付费交易模式。
  17. 如权利要求12所述的安全业务交易装置，还包括：
    历史交易数据获取单元，获取多个账户在设定时间段所产生的历史交易数据集；
    交易风控评价指标确定单元，基于所述历史交易数据集确定交易风控评价指标，所述交易风控评价指标包括扣不到款坏账率、预付费订单比例和风控交易失败率；
    风控模型优化单元，基于所述交易风控评价指标，确定是否对所述第一风控模型和/或所述第二风控模型执行优化操作。
  18. 如权利要求17所述的安全业务交易装置，其中，所述风控模型优化单元包括风控模型参数调整模块和/或风控模型训练模块，
    所述风控模型参数调整模块基于所述交易风控评价指标，确定是否调整所述第一风控模型和/或所述第二风控模型的特征维度和风险阈值；以及
    所述风控模型训练模块基于所述交易风控评价指标，确定是否利用所述历史交易数据集合来训练所述第一风控模型和/或所述第二风控模型。
  19. 如权利要求17所述的安全业务交易装置，其中，所述交易风控评价指标确定单元还基于预设的交易噪音因子和所述历史交易数据集，确定交易风控评价指标。
  20. 如权利要求12所述的安全业务交易装置，其中，所述第一风控模型的特征维度包括：账户历史支付记录、账户历史交易模式、账户资产信息、账龄信息、账户绑卡信息、账户注册信息和账户安全认证结果。
  21. 如权利要求12-20中任一所述的安全业务交易装置，其中，所述账户业务请求包括针对出行类业务的账户业务请求。
  22. 一种安全业务交易装置，包括：
    NSF业务请求获取单元，获取对应先享后付费交易模式的账户业务请求；
    第一风控单元，基于第一风控模型，判断所述账户业务请求所对应的账户是否存在目标类风险；
    交易模式转换单元，根据关于所述目标类风险的判断结果，确定是否将所述账户业务请求所对应的交易模式转换为预付费交易模式；
    第二风控单元，当将对应所述账户业务请求的交易模式转换为预付费交易模式时，基于第二风控模型判断所述账户业务请求是否存在支付风险；
    付费操作执行单元，根据关于所述支付风险的判断结果，确定是否执行针对所述账户业务请求的付费操作。
  23. 一种电子设备，包括：
    至少一个处理器；以及
    存储器，所述存储器存储指令，当所述指令被所述至少一个处理器执行时，使得所述至少一个处理器执行如权利要求1到11中任一所述的方法。
PCT/CN2021/087645 2020-04-24 2021-04-16 安全业务交易 WO2021213250A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202010332208.9A CN111539711A (zh) 2020-04-24 2020-04-24 一种安全业务交易方法、装置及电子设备
CN202010332208.9 2020-04-24

Publications (1)

Publication Number Publication Date
WO2021213250A1 true WO2021213250A1 (zh) 2021-10-28

Family

ID=71975401

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2021/087645 WO2021213250A1 (zh) 2020-04-24 2021-04-16 安全业务交易

Country Status (2)

Country Link
CN (1) CN111539711A (zh)
WO (1) WO2021213250A1 (zh)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114240097A (zh) * 2021-12-02 2022-03-25 支付宝(杭州)信息技术有限公司 一种风险评估的方法及装置
CN115471041A (zh) * 2022-08-03 2022-12-13 中金支付有限公司 黑产账户的识别方法、装置、设备和存储介质
CN115860749A (zh) * 2023-02-09 2023-03-28 支付宝(杭州)信息技术有限公司 一种数据处理方法、装置及设备
CN116028820A (zh) * 2023-03-20 2023-04-28 支付宝(杭州)信息技术有限公司 一种模型训练的方法、装置、存储介质及电子设备
CN116091059A (zh) * 2022-11-16 2023-05-09 山东鲁商通科技有限公司 一种虚拟预付卡防盗刷***
CN118095870A (zh) * 2024-04-28 2024-05-28 晋江市昱隆体育用品有限公司 一种基于跨境电商大数据的智能风控策略***

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111539711A (zh) * 2020-04-24 2020-08-14 支付宝(杭州)信息技术有限公司 一种安全业务交易方法、装置及电子设备
CN112016929B (zh) * 2020-08-31 2023-08-04 中国银行股份有限公司 线上支付的方法及装置、电子设备、计算机存储介质
CN112232953A (zh) * 2020-10-14 2021-01-15 深圳壹账通智能科技有限公司 一种债券交易预付款方法、装置、设备及存储介质
CN112734437B (zh) * 2021-01-11 2022-08-16 支付宝(杭州)信息技术有限公司 刷脸支付的方法和装置
CN112804254B (zh) * 2021-02-07 2022-10-28 成都薯片科技有限公司 请求检测方法、装置、电子设备及存储介质
CN112712368B (zh) * 2021-02-23 2021-12-14 深圳亚桐荟科技有限公司 一种基于大数据的云安全账户管理方法及云安全平台
CN113191780A (zh) * 2021-05-31 2021-07-30 中国银行股份有限公司 基于区块链的高风险业务交易执行方法及装置
CN113344695B (zh) * 2021-06-21 2022-06-03 支付宝(杭州)信息技术有限公司 一种弹性风控方法、装置、设备和可读介质

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103530772A (zh) * 2013-09-30 2014-01-22 深圳钱盒信息技术有限公司 一种移动互联支付风险控制方法及***
US20170255937A1 (en) * 2016-03-02 2017-09-07 American Express Travel Related Services Company, Inc. Systems and methods for transaction account tokenization
CN109345220A (zh) * 2018-08-15 2019-02-15 北京三快在线科技有限公司 支付处理方法、装置及计算机可读存储介质
CN110060047A (zh) * 2019-03-28 2019-07-26 阿里巴巴集团控股有限公司 基于交易的信用风险判别方法及其装置
CN110347566A (zh) * 2019-06-25 2019-10-18 阿里巴巴集团控股有限公司 用于对注册风控模型进行效能评估的方法及装置
CN110992037A (zh) * 2020-03-03 2020-04-10 支付宝(杭州)信息技术有限公司 基于多方安全计算的风险防控方法、装置和***
CN111539711A (zh) * 2020-04-24 2020-08-14 支付宝(杭州)信息技术有限公司 一种安全业务交易方法、装置及电子设备

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108133372B (zh) * 2017-12-28 2022-02-18 蚂蚁智安安全技术(上海)有限公司 评估支付风险的方法及装置
SG10201803415SA (en) * 2018-04-24 2019-11-28 Mastercard International Inc Electronic system and method for funding a prepaid account
CN109191110B (zh) * 2018-07-27 2023-05-23 创新先进技术有限公司 后付费交易数据处理方法、装置、处理设备、及服务器
CN110245941B (zh) * 2019-04-25 2023-06-30 创新先进技术有限公司 一种交易风险识别方法及装置

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103530772A (zh) * 2013-09-30 2014-01-22 深圳钱盒信息技术有限公司 一种移动互联支付风险控制方法及***
US20170255937A1 (en) * 2016-03-02 2017-09-07 American Express Travel Related Services Company, Inc. Systems and methods for transaction account tokenization
CN109345220A (zh) * 2018-08-15 2019-02-15 北京三快在线科技有限公司 支付处理方法、装置及计算机可读存储介质
CN110060047A (zh) * 2019-03-28 2019-07-26 阿里巴巴集团控股有限公司 基于交易的信用风险判别方法及其装置
CN110347566A (zh) * 2019-06-25 2019-10-18 阿里巴巴集团控股有限公司 用于对注册风控模型进行效能评估的方法及装置
CN110992037A (zh) * 2020-03-03 2020-04-10 支付宝(杭州)信息技术有限公司 基于多方安全计算的风险防控方法、装置和***
CN111539711A (zh) * 2020-04-24 2020-08-14 支付宝(杭州)信息技术有限公司 一种安全业务交易方法、装置及电子设备

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114240097A (zh) * 2021-12-02 2022-03-25 支付宝(杭州)信息技术有限公司 一种风险评估的方法及装置
CN115471041A (zh) * 2022-08-03 2022-12-13 中金支付有限公司 黑产账户的识别方法、装置、设备和存储介质
CN115471041B (zh) * 2022-08-03 2024-05-28 中金支付有限公司 黑产账户的识别方法、装置、设备和存储介质
CN116091059A (zh) * 2022-11-16 2023-05-09 山东鲁商通科技有限公司 一种虚拟预付卡防盗刷***
CN116091059B (zh) * 2022-11-16 2023-09-05 山东鲁商通科技有限公司 一种虚拟预付卡防盗刷***
CN115860749A (zh) * 2023-02-09 2023-03-28 支付宝(杭州)信息技术有限公司 一种数据处理方法、装置及设备
CN116028820A (zh) * 2023-03-20 2023-04-28 支付宝(杭州)信息技术有限公司 一种模型训练的方法、装置、存储介质及电子设备
CN116028820B (zh) * 2023-03-20 2023-07-04 支付宝(杭州)信息技术有限公司 一种模型训练的方法、装置、存储介质及电子设备
CN118095870A (zh) * 2024-04-28 2024-05-28 晋江市昱隆体育用品有限公司 一种基于跨境电商大数据的智能风控策略***

Also Published As

Publication number Publication date
CN111539711A (zh) 2020-08-14

Similar Documents

Publication Publication Date Title
WO2021213250A1 (zh) 安全业务交易
US11694186B2 (en) Combination payment card and methods thereof
US11282070B2 (en) Combination payment card and methods thereof
US8392328B2 (en) Methods and apparatus for funding transactions using debit cards issued by one institution and funds from accounts at other institutions
US20120078790A1 (en) Real-time interchange fee estimation
CN112184239B (zh) 一种安全支付方法、装置、设备和可读介质
WO2019196257A1 (zh) 一种自动还款方法、***及终端设备
US20140164192A1 (en) Franchise royalty and advertising fee collection
US8892468B1 (en) Customer refunds by a merchant agent
US20130013506A1 (en) Variable Service Fee For Overdraft Protection
US11727412B2 (en) Systems and methods for optimizing transaction authorization request message to reduce false declines
US20100312675A1 (en) Systems and Methods for Reporting Chargebacks
CN112734561A (zh) 用于票据***的处理方法和装置
CN110276692B (zh) 一种处理交易数据的方法及装置
WO2020222071A1 (en) Transaction lifecycle monitoring
US8566241B2 (en) Deposit pending check clearance
US20140006192A1 (en) Selective escrow of funds based on transaction receipts
CN112884483B (zh) 一种担保方法、装置及设备
KR102369872B1 (ko) Ic 카드의 결제 방법
Esin Paytech regulation trends
US11971862B1 (en) Processing transactions with idempotency in real-time ledgers
TWI333171B (zh)
US20140249899A1 (en) System and method of applying rewards to fees in qualifying accounts of financial institutions
CN113344693A (zh) 基于预测账户余额的催收扣款方法、装置和存储介质
CN116485551A (zh) 融资方法及装置、存储介质和电子设备

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21792676

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21792676

Country of ref document: EP

Kind code of ref document: A1