WO2020015484A1 - 风险识别方法、装置及服务器 - Google Patents
风险识别方法、装置及服务器 Download PDFInfo
- Publication number
- WO2020015484A1 WO2020015484A1 PCT/CN2019/091033 CN2019091033W WO2020015484A1 WO 2020015484 A1 WO2020015484 A1 WO 2020015484A1 CN 2019091033 W CN2019091033 W CN 2019091033W WO 2020015484 A1 WO2020015484 A1 WO 2020015484A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- user side
- user
- order request
- risk
- information
- Prior art date
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/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 the present specification relate to the technical field of risk identification, and in particular, to a risk identification method, device, and server.
- the prepaid and postpaid model also brings risks to network service providers, causing network service providers to fail to receive payment from some users after providing service products, resulting in economic losses.
- the embodiments of the present specification provide and a risk identification method, device and server.
- an embodiment of the present specification provides a risk identification method, including:
- an embodiment of the present specification provides a risk identification device, including:
- a level determination unit is configured to obtain user information that characterizes behaviors on the user side, and to determine the credit level of the user side based on the user information; a permission determination unit is configured to, based on the credit level and the pre-stored credit level and purchase The corresponding relationship of the rights determines the current purchase right of the user side; and an identifying unit is configured to identify whether there is a risk in the order request sent by the user side according to the current purchase right.
- an embodiment of the present specification provides a server, including a memory, a processor, and a computer program stored on the memory and executable on the processor.
- the processor executes the program, any one of the foregoing is implemented. Steps in risk identification method.
- an embodiment of the present specification provides a computer-readable storage medium on which a computer program is stored, and when the program is executed by a processor, the steps of the risk identification method according to any one of the foregoing are implemented.
- the user's credit level is determined according to the user information on the user side to confirm its current purchase authority, so that the purchase authority can be customized for different user sides in accordance with its own behavior characteristics, so that According to the current purchase authority, it is more accurately identified whether there is a risk in the order request on the user side, that is, the economic loss of the service provider is reduced, and frequent interruptions to high-credit customers caused by inappropriate purchase authority settings are avoided.
- FIG. 1 is a schematic diagram of a risk identification application scenario according to an embodiment of the present specification
- FIG. 2 is a flowchart of a risk identification method provided by the first aspect of the embodiment of the present specification
- FIG. 3 is a schematic structural diagram of a risk identification device according to a second aspect of the embodiment of the present specification.
- FIG. 4 is a schematic structural diagram of a server according to a third aspect of the embodiment of the present specification.
- FIG. 1 is a schematic diagram of a risk identification application scenario according to an embodiment of the present specification.
- the terminal 100 is located on the user side and communicates with the server 200 on the network side.
- the transaction processing client 101 in the terminal 100 may be an APP or website that implements services based on the Internet, provides a user with a transaction interface and provides transaction data to the network side for processing; the risk identification system 201 in the server 200 is used to process transactions The risky transactions involved in the client 101 are identified.
- the existing payment model includes a post-payment model, that is, after the user places an order to the server, the cloud service product in the order request is first provided to the user Side use, and then the service provider uniformly performs batch deductions at a fixed time (for example, a monthly fixed deduction day).
- a post-payment model that is, after the user places an order to the server, the cloud service product in the order request is first provided to the user Side use, and then the service provider uniformly performs batch deductions at a fixed time (for example, a monthly fixed deduction day).
- a post-payment model that is, after the user places an order to the server, the cloud service product in the order request is first provided to the user Side use, and then the service provider uniformly performs batch deductions at a fixed time (for example, a monthly fixed deduction day).
- service providers' deductions at fixed times are prone to failures due to insufficient deposit balances, leading to bad debts and economic losses to service providers.
- the purchase authority that is consistent with its own behavior characteristics is customized for different user sides, so that it can more accurately identify whether there is a risk in the order request of the user side according to the current purchase authority, which reduces the economics of the service provider.
- the loss also avoids frequent interruptions to customers with high credit levels caused by inappropriate purchase permission settings.
- the above method includes S201-S203.
- S201 Acquire user information characterizing behavior characteristics on the user side, and determine a credit level on the user side based on the user information.
- the user information includes any one or more of registration information on the user side, historical payment information, or device status information. Specifically, it may be one or more of user registration area information, registered industry information, associated account active information, equipment information, environmental information, historical prepaid payment information, historical postpaid payment information, and product use information.
- the user registration area information is the geographic area where the user is registered, for example: Chengdu, Wuhan, or South China; the registered industry information is the information of the business to which the user is registered, such as education, medical, or government affairs; the associated account active information is the user Information such as login duration, frequency, or service life of the side-linked account; device information is information such as the model, type, or number of devices of the user-side device; environmental information is information such as the network connection environment or installation system environment of the user-side device; historical prepayment The fee payment information is information such as the amount and number of times the service product was previously paid by the user in advance; the postpaid payment information is the amount, frequency, and delayed payment of the service product that was previously used by the user. Information about the type, quantity, and duration of service products purchased and used.
- the acquisition of the above user information may be triggered by an APP installed on the user side or an open website, which triggers the user side to send to the server according to preset reporting rules; it may also be obtained by the server sending a collection request to the user side; or it may be the server There are no restrictions on the data obtained from the transaction log.
- the user information is used as input data of the preset model, and the user-side credit rating is determined through calculation of the preset model.
- using a preset model to calculate the credit level of each user can not only increase the speed of determining the credit level through fast model calculations, but also use more and more abundant user information as training data for the preset model.
- the calculation accuracy of the model is improved to make the determined credit level more consistent with the behavior characteristics of each user side.
- the user information may be used as input data of the preset model, and the credit rating data may be directly output through calculation of the preset model; or the user information may be used as input data of the preset model, and preset
- the model first calculates the output user's credit score, and then determines the user's credit rating based on the correspondence between the credit score and the pre-stored credit score and the credit rating, which is not limited here.
- the preset model can be a model based on a random forest algorithm, or a model based on other supervised or unsupervised algorithms, such as: gradient boosted tree algorithm, neural network algorithm, clustering algorithm, anomaly detection algorithm based on Gaussian distribution, Wait, there are no restrictions here.
- the following uses a random forest algorithm to generate a preset model, and the preset model outputs a credit score as an example for illustration.
- Random forest is a forest algorithm that contains multiple decision trees, and the output score is determined by the mode of the scores output by individual trees. That is, a forest is established in a random manner. The forest includes many decision trees. There is no correlation between each decision tree in the random forest. When a new input sample enters, each decision tree in the forest is calculated separately to determine the score of the sample, and then see which score is selected the most, as the predicted score of this sample. .
- user data of the past two years is collected, including user information of each user side and deduction status data of each user side, and then the staff member organizes the user data and deducts the charges according to the deduction.
- the n training samples are input into the random forest algorithm to generate a preset model for scoring, and the calculated prediction score is compared with the training sample's pre-scoring score, and then the preset model is modified according to the comparison result to complete the preset.
- Model training When the difference between the pre-score value and the pre-score value of the preset model is less than the preset range, the preset model is considered to be in line with expectations, and it can be deployed online to determine the user's credit rating.
- the method of calculating the user-side credit score according to a preset model to determine the user-side credit rating may be a mapping table of a credit score range and a credit rating set in advance, and the credit rating may be confirmed by querying the mapping table; or A calculation rule for a credit score and a credit rating is set in advance, and the credit rating is confirmed by the calculation rule (for example, a ten-digit number of the credit score is used as its credit rating), which is not limited herein.
- the second type is to set a mapping table between credit rating and user information, and determine the credit rating by looking up the table.
- mapping table of credit levels and user information is set in advance.
- the mapping table lists different combinations of user information and their corresponding credit levels. After obtaining user information, you only need to find the corresponding credit level of the user information in the table. can.
- the method of confirming the credit rating based on the user information is not limited to the above two types, and is not limited here, nor will it be enumerated one by one.
- S202 Determine the current purchase authority on the user side according to the correspondence between the credit rating and the pre-stored credit rating and the purchase authority.
- a mapping table between the credit level and the purchase authority may be set in advance, and the purchase authority corresponding to the credit level of the user side may be determined by querying the mapping table as the current purchase authority of the user side placing an order this time.
- the current purchase authority of the user side includes any one or more of the types of products, the number of products, or the deferred payment amount that the user side is allowed to purchase.
- the deferred payment amount refers to the total amount of the product cost that the user can use the product first and pay later.
- the service product purchased is a cloud service product
- the quantity of the product may refer to the amount of instances, that is, the number of devices or resources that provide the service.
- the purchase authority can be: the user side can only purchase cloud computing services and cloud storage services this time; the user side can only obtain 4 instances; the user side's delay
- the post-payment limit is 20,000.
- the purchase authority may be: the user side can only purchase the service that pushes the shop link to the homepage at this time; the deferred payment amount of the user side is 10,000.
- S203 Identify whether there is a risk in the order request sent by the user side according to the current purchase authority.
- the purchase information carried in the order request meets the current purchase authorization requirements, it can be identified whether there is a risk. If the purchase request is outside the scope of the current purchase authority, it is considered a risk; if the purchase request is within the scope of the current purchase authority, it is considered that there is no risk.
- the order request sent by the user side carries the product type and product quantity of the purchase, and the total cost required for the purchase can be determined according to the product type and product quantity. Determine whether the product type, product quantity, and total cost purchased in the order request meet the product type, product quantity, and deferred payment limit specified in the current purchase authority. If they all meet, then there is no risk. If there are non-conformities, they are considered risk.
- the purchase information carried in the order request sent by the user side is the purchase of cloud security services and the number of 3 instances. It is determined that the current purchase right of the user side can only purchase cloud computing services and cloud storage services; the user side has only obtained 4 instances; the deferred payment amount of the user side is 20,000. Since the cloud security service is not within the current purchase rights of the user side, it is considered to be a risk.
- the server After receiving the order request sent by the user, the server triggers and responds to the order request, and executes steps S201 to S203. That is, the server triggers the acquisition of user information for risk identification after receiving the order request from the user.
- the second type is to periodically obtain user information to determine the user level, and risk identification is triggered by an order request.
- step S203 After identifying whether there is a risk in the order request through step S203, different risk processing methods can be set according to the recognition result to ensure the economic benefits of the service provider.
- the server can be set to feed back the interception information to the user.
- the interception information includes the reason for the interception and prompts the user to improve the credit level (for example, to guide the user) Submit relevant information to prove or instruct users to bind new payment accounts, etc.).
- the service product corresponding to the order request is provided to the user side; if there is a risk, a part of the prepayment is deducted first, and then The user side provides a service product corresponding to the order request.
- the process of using the service product will generate more cost consumption as the usage time increases.
- the service product corresponding to the order request is provided to the user side
- the user side will also be used according to a preset second cycle (one hour, half an hour, or one day).
- Use information of service products generate billing data based on the usage information, and then identify whether there is a risk of insufficient deposits on the user side based on the generated billing data.
- a process of identifying whether there is a risk of insufficient deposits on the user side is: using the newly generated billing data and other behavior characteristic data of the user side as new user information, and then determining the method using steps S201-S202
- the current purchase authority determines whether there is a risk of insufficient deposit by judging whether the service product currently used by the user conforms to the newly calculated current purchase authority.
- the process of identifying whether there is a risk of insufficient deposits on the user side is: comparing the newly generated billing data with the deferred payment amount in the current purchase authority previously determined by the user side to identify whether there is Risk of insufficient deposits. It can be that the amount of the newly generated billing data is greater than or equal to the deferred payment amount, and there is a risk of insufficient deposits, or the difference between the amount of the newly generated billing data and the deferred payment amount is less than a preset difference, it is considered that there is insufficient deposit risk.
- the user's credit level is determined according to the user-side user information to confirm its current purchase authority, and the purchase authority that suits its own behavior characteristics can be customized for different user-sides, thereby enabling According to the current purchase authority, it is more accurately identified whether there is a risk in the order request on the user side, that is, the economic loss of the service provider is reduced, and frequent interruptions to customers with high credit levels caused by improper purchase authority settings are avoided.
- the online credit model of the server takes the user information of the user as input to score the user. And confirm whether there is a risk of insufficient funds (Non Fufficient Fund) (NSF) according to the scoring, if there is an interception of the order, if there is no, the user placed the order successfully.
- NSF Non Fufficient Fund
- the user-side bill is generated once an hour, combined with the bill and then scored using the online credit model, and the existence of NSF risk is confirmed based on the scoring result. If there is no risk, it will not be processed, and if there is risk, the deduction will be triggered. If the debit is successful, it will not be dealt with. If the debit is not successful, strengthened review of the account holder to understand the legality of the source of funds (Know Your Customer, KYC) or prohibit the use of goods and other measures.
- a level determining unit 301 configured to obtain user information that characterizes behavior characteristics of a user side, and determine a credit level of the user side based on the user information;
- An authority determining unit 302 configured to determine a current purchase authority of the user side according to the corresponding relationship between the credit level and the pre-stored credit level and the purchase authority;
- the identifying unit 303 is configured to identify whether there is a risk in the order request sent by the user side according to the current purchase authority.
- the level determining unit 301 is further configured to: use the user information as input data of a preset model, and determine the credit level of the user side by calculating through the preset model.
- the level determining unit 301 is further configured to: use the user information as input data of a preset model, and calculate and output the user-side credit score through the preset model; The corresponding relationship between the credit score and the pre-stored credit score and the credit rating is used to determine the credit rating of the user side.
- the device further includes:
- a processing unit 304 is configured to provide the user with a service product corresponding to the order request if there is no risk in the order request; and intercept the order request if the order request has risks.
- the processing unit 304 is further configured to: obtain usage information of the user side using the service product according to a preset second cycle, and generate billing data according to the usage information;
- the bill data identifies whether there is a risk of insufficient deposit on the user side.
- the processing unit 304 is further configured to: if there is a risk of insufficient deposit in the order request, deduct from the account corresponding to the user side that the user side has consumed but has not yet been charged. cost.
- the processing unit 304 is further configured to: if the deduction is unsuccessful, prohibit the user side from using the service product.
- the level determining unit 301 is further configured to: when receiving the order request sent by the user side, respond to the order request, thereby obtaining user information characterizing behavior characteristics of the user side .
- the level determining unit 301 is further configured to: obtain user information characterizing behavior characteristics on the user side according to a preset first period.
- the authority determining unit 302 is further configured to: receive the order request sent by the user side; and in response to the order request, identify the user side sent based on the current purchase authority Is an order request at risk.
- the present invention also provides a server, as shown in FIG. 4, including a memory 404, a processor 402, and stored in the memory 404 and may be stored in the processor.
- a server as shown in FIG. 4, including a memory 404, a processor 402, and stored in the memory 404 and may be stored in the processor.
- a computer program running on 402. When the processor 402 executes the program, the steps of any method of the risk identification method described above are implemented.
- the bus architecture (represented by the bus 400).
- the bus 400 may include any number of interconnected buses and bridges.
- the bus 400 will include one or more processors represented by the processor 402 and memory 404.
- the various circuits of the memory are linked together.
- the bus 400 can also link various other circuits such as peripheral devices, voltage regulators, and power management circuits, which are well known in the art, and therefore, they will not be further described herein.
- the bus interface 406 provides an interface between the bus 400 and the receiver 401 and the transmitter 403.
- the receiver 401 and the transmitter 403 may be the same element, that is, a transceiver, providing a unit for communicating with various other devices on a transmission medium.
- the processor 402 is responsible for managing the bus 400 and general processing, and the memory 404 may be used to store data used by the processor 402 when performing operations.
- the present invention also provides a computer-readable storage medium having stored thereon a computer program which, when executed by a processor, implements the risk identification method described above. Steps of either method.
- These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to work in a particular manner such that the instructions stored in the computer-readable memory produce a manufactured article including the instruction device, the instructions
- the device implements the functions specified in one or more flowcharts and / or one or more blocks of the block diagram.
- These computer program instructions can also be loaded on a computer or other programmable data processing device, so that a series of steps can be performed on the computer or other programmable device to produce a computer-implemented process, which can be executed on the computer or other programmable device.
- the instructions provide steps for implementing the functions specified in one or more flowcharts and / or one or more blocks of the block diagrams.
Landscapes
- Business, Economics & Management (AREA)
- Engineering & Computer Science (AREA)
- Accounting & Taxation (AREA)
- Computer Security & Cryptography (AREA)
- Finance (AREA)
- Strategic Management (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
本说明书实施例提供了一种风险识别方法，为不同的用户侧定制出符合其自身行为特征的购买权限，从而能根据当前购买权限更准确的识别出该用户侧的订单请求是否存在风险，即减小了服务商的经济损失，也避免了购买权限设置不合适导致的对高信用等级客户的频繁打扰。
Description
本说明书实施例涉及风险识别技术领域，尤其涉及一种风险识别方法、装置及服务器。
网络社会中，为了方便用户能持续的使用网络服务商提供的服务商品，推出了先享后付模式，即用户可以先使用服务商品，再延后进行付费。
然而，先享后付模式在给用户提供便利的同时，也给网络服务商带来了风险，导致网络服务商在提供服务商品后，却不能收到部分用户的付费，造成经济损失。
发明内容
本说明书实施例提供及一种风险识别方法、装置及服务器。
第一方面，本说明书实施例提供一种风险识别方法，包括：
获取表征用户侧的行为特征的用户信息，并基于所述用户信息确定所述用户侧的信用等级；根据所述信用等级和预存的信用等级与购买权限的对应关系，确定所述用户侧的当前购买权限；根据所述当前购买权限，识别所述用户侧发送的订单请求是否存在风险。
第二方面，本说明书实施例提供一种风险识别装置，包括：
等级确定单元，用于获取表征用户侧的行为特征的用户信息，并基于所述用户信息确定所述用户侧的信用等级；权限确定单元，用于根据所述信用等级和预存的信用等级与购买权限的对应关系，确定所述用户侧的当前购买权限；识别单元，用于根据所述当前购买权限，识别所述用户侧发送的订单请求是否存在风险。
第三方面，本说明书实施例提供一种服务器，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上述任一项所述风险识别方法的步骤。
第四方面，本说明书实施例提供一种计算机可读存储介质，其上存储有计算机程序， 该程序被处理器执行时实现上述任一项所述风险识别方法的步骤。
本说明书实施例有益效果如下：
通过本发明实施例提供的风险识别方法，根据用户侧的用户信息来确定用户的信用等级进而确认其当前购买权限，实现可以为不同的用户侧定制出符合其自身行为特征的购买权限，从而能根据当前购买权限更准确的识别出该用户侧的订单请求是否存在风险，即减小了服务商的经济损失，也避免了购买权限设置不合适导致的对高信用等级客户的频繁打扰。
图1为本说明书实施例风险识别应用场景示意图；
图2本说明书实施例第一方面提供的风险识别方法的流程图；
图3本说明书实施例第二方面提供的风险识别装置结构示意图；
图4本说明书实施例第三方面提供的服务器结构示意图。
为了更好的理解上述技术方案，下面通过附图以及具体实施例对本说明书实施例的技术方案做详细的说明，应当理解本说明书实施例以及实施例中的具体特征是对本说明书实施例技术方案的详细的说明，而不是对本说明书技术方案的限定，在不冲突的情况下，本说明书实施例以及实施例中的技术特征可以相互组合。
参见图1，为本说明书实施例风险识别应用场景示意图。终端100位于用户侧，与网络侧的服务器200通信。终端100中的交易处理客户端101可以是基于互联网实现业务的APP或网站，为用户提供交易的界面并将交易数据提供给网络侧进行处理；服务器200中的风险识别系统201用于对交易处理客户端101中涉及的有风险交易进行识别。
以服务商提供云计算、云存储和云安全等云服务商品为例，现有的付费模式包括后付费模式，即在用户侧下订单至服务器后，先提供订单请求中的云服务商品至用户侧使用，再由服务商统一在固定时间(例如，每月的固定扣款日)进行批量扣款。然而，在用户出现资金问题或存在低信用用户时，服务商在固定时间的扣费容易出现存款余额不足导致的扣款失败，从而出现坏账，给服务商带来经济损失。
本说明书实施例，为不同的用户侧定制出符合其自身行为特征的购买权限，从而能根据当前购买权限更准确的识别出该用户侧的订单请求是否存在风险，即减小了服务商的经济损失，也避免了购买权限设置不合适导致的对高信用等级客户的频繁打扰。
第一方面，本说明书实施例提供一种风险识别方法，用于根据用户侧的用户信息，确定其信用等级和其对应的当前购买权限，从而根据当前购买权限识别用户侧发送的订单请求是否存在风险。
请参考图2，上述方法包括S201-S203。
S201：获取表征用户侧的行为特征的用户信息，并基于用户信息确定用户侧的信用等级。
在本申请实施例中，该用户信息，包括：用户侧的注册信息、历史付费信息或设备状态信息中的任一种或多种信息。具体来讲，可以是用户注册区域信息、注册行业信息、关联账户活跃信息、设备信息、环境信息、历史预付费缴费信息、历史后付费缴费信息和产品使用信息中的一种或多种信息。
其中，用户注册区域信息是用户注册的地理区域，例如：成都、武汉或华南等；注册行业信息是用户注册的业务所属领域的信息，例如：教育、医疗或政务等；关联账户活跃信息是用户侧关联的账户的登录时长、频率或使用年限等信息；设备信息是用户侧设备的型号、类型或设备数量等信息；环境信息是用户侧设备的网络连接环境或安装系统环境等信息；历史预付费缴费信息是用户侧以前预先缴费再使用服务商品的金额、次数等信息；历史后付费缴费信息是用户侧以前先使用服务商品再付费的金额、次数、延迟付款等信息；产品使用信息是用户侧购买和使用过的服务商品种类、数量和使用时长等信息。
上述用户信息的获取可以是由用户侧安装的APP或开启的网站根据预设的上报规则，触发用户侧发送给服务器的；也可以是由服务器发送收集请求至用户侧获取的；还可以是服务器从交易日志中整理获取的，在此不作限制。
而基于用户信息确定用户侧的信用等级的方法也可以有多种，下面列举两种为例：
第一种，以用户信息作为预设模型的输入数据，通过预设模型计算确定用户侧的信用等级。
具体来讲，采用预设模型来计算各个用户侧的信用等级不仅能通过快速的模型计算提高确定信用等级的速度，还能通过采用越来越丰富的用户信息作为该预设模型的训练 数据来提高模型的计算精确度，使确定出的信用等级更符合各用户侧的行为特征。
在具体实施过程中，可以是，以用户信息作为预设模型的输入数据，通过预设模型的计算直接输出信用等级数据；也可以是，以用户信息作为预设模型的输入数据，通过预设模型先计算输出用户侧的信用分数，再根据信用分数和预存的信用分数与信用等级的对应关系，确定用户侧的信用等级，在此不作限制。
预设模型可以是基于随机森林算法的模型，也可以是基于其他的有监督或无监督算法的模型，例如：梯度提升树算法，神经网络算法，聚类算法，基于高斯分布的异常检测算法，等等，在此不作限制。
下面以采用随机森林算法生成预设模型，该预设模型输出信用分数为例进行说明。
随机森林是包含多个决策树的森林算法，并且其输出的分值是由个别树输出的分值的众数而定。即是用随机的方式建立一个森林，森林里面包括很多的决策树，随机森林的每棵决策树之间是没有关联的。当有一个新的输入样本进入的时候，就由森林中的每一棵决策树分别进行计算，确定该样本的分值，然后看看哪个分值被选择最多，就作为这个样本的预测分值。
例如，在本说明书实施例中，先收集近两年的用户数据，包括各用户侧的用户信息，及各用户侧的扣费情况数据，再由工作人员对用户数据进行整理，并按照扣费情况进行预打分，生成n条训练样本，其中，每条训练样本包括一用户侧的用户信息及其对应的预打分分值。将n条训练样本输入随机森林算法生成预设模型进行打分，将计算出的预测分值与训练样本的预打分分值进行比对，再根据比对结果修正预设模型，从而完成对预设模型的训练。在预设模型的预打分分值与预打分分值的差值小于预设范围时，认为该预设模型符合预期，可以部署上线来确定用户信用等级。
而根据预设模型计算输出的用户侧的信用分数，来确定用户侧的信用等级的方法，可以是预先设置信用分数范围与信用等级的映射表格，通过查询映射表格来确认信用等级；也可以是预先设置信用分数与信用等级的计算规则，通过计算规则来确认信用等级(例如，以信用分数的十位数字作为其信用等级)，在此不作限制。
第二种，设置信用等级与用户信息的映射表格，通过查表确定信用等级。
即预先设置信用等级与用户信息的映射表格，该映射表格中列举有不同的用户信息组合及其对应的信用等级，获取用户信息后，只需要到表格中查找到该用户信息对应的信用等级即可。
当然，在具体实施过程中，根据用户信息确认信用等级的方式不限于上述两种，在此不作限制，也不再一一列举。
S202：根据信用等级和预存的信用等级与购买权限的对应关系，确定用户侧的当前购买权限。
具体来讲，可以预先设置信用等级与购买权限的映射表，通过查询该映射表来确定用户侧的信用等级对应的购买权限，作为该用户侧本次下订单的当前购买权限。
在本申请实施例中，用户侧的当前购买权限，包括：该用户侧允许购买的产品种类、产品数量或延后付款额度中的任一种或多种。其中，延后付款额度是指用户能先使用商品，后进行支付的商品费用总额度。具体来讲，当购买的服务商品为云服务商品时，该产品数量可以是指实例数额度，即指提供服务的设备数量或资源大小。
举例来说，以服务商品为云服务商品为例，购买权限可以是：该用户侧本次只能购买云计算服务和云存储服务；该用户侧只有获得4台实例数；该用户侧的延后付款额度为2万。
以服务商品为网购平台服务商品为例，购买权限可以是：该用户侧本次只能购买将商铺链接推送显示在主页的服务；该用户侧的延后付款额度为1万。
S203：根据当前购买权限，识别用户侧发送的订单请求是否存在风险。
通过判断订单请求中携带的购买信息是否满足当前购买权限的规定即可以识别是否存在风险。如果购买请求超出当前购买权限的范围，则认为存在风险；如果购买请求在当前购买权限的范围内，则认为不存在风险。
举例来讲，用户侧发送的订单请求中携带有本次购买的产品种类和产品数量，根据产品种类和产品数量能够确定该次购买所需的总费用。分别判断订单请求中购买的产品种类、产品数量和总费用是否符合当前购买权限规定的产品种类、产品数量和延后付款额度。如果均符合则认为不存在风险，如果有不符合则认为存在风险。
例如，用户侧发送的订单请求携带的购买信息为，购买云安全服务，3台实例数。而确定出该用户侧的当前购买权限为只能购买云计算服务和云存储服务；该用户侧只有获得4台实例数；该用户侧的延后付款额度为2万。由于云安全服务不在该用户侧的当前购买权限内，则认为存在风险。
还需要说明的是，本实施提供的风险识别方法可以有多种实施流程方案，下面列举 两种为例：
第一种，由订单请求触发获取用户信息。
在服务器接收到用户侧发送的订单请求后，触发响应该订单请求，执行步骤S201～S203。即服务器是在接收到用户侧的订单请求后才触发获取用户信息进行风险识别。
第二种，定期获取用户信息进行用户等级确定，由订单请求触发风险识别。
按预设的第一周期(每天，每2天或每10小时等)执行步骤S201～S202，并存储各用户侧确定出的当前购买权限，在服务器接收到用户侧发送的订单请求后，触发响应该订单请求，执行步骤S203。即服务器会定期(每天、每10小时或每周)收集各用户侧的用户信息来确定个用户侧的当前购买权限并存储，在接收到用户侧的订单请求后才触发根据当前购买权限进行风险识别。
当然，在具体实施过程中，不限于上述两种实施流程方案，也可以定期执行步骤S201，在接收到用户侧的订单请求后才触发执行步骤S202～S203，在此不作限制。
在通过步骤S203识别出订单请求是否存在风险后，就可以根据识别结果设置不同的风险处理方法，来保证服务商的经济利益。
在一种实现方式中，在识别出订单请求是否存在风险后，如果不存在风险，则向所述用户侧提供订单请求对应的服务商品；如果存在风险，则拦截该订单请求。为了避免拦截该订单请求后导致用户侧不能再下单购买服务商品，可以设置服务器向用户侧反馈拦截信息，该拦截信息包括：拦截的理由说明，提示用户提升信用等级的方法(例如，指导用户提交相应资料证明或指导用户绑定新的付款账户等)。
在另一种实现方式中，在识别出订单请求是否存在风险后，如果不存在风险，则向所述用户侧提供订单请求对应的服务商品；如果存在风险，则先扣除部分预付款项，再向所述用户侧提供订单请求对应的服务商品。
进一步，考虑到在用户侧的订单请求通过后，其使用服务商品的过程中，随着使用时间的增加，会产生更多的费用消耗，为了减少用户侧在使用服务商品过程中的费用消耗给服务商带来的经济损失风险，本实施例还设置在向用户侧提供订单请求对应的服务商品之后，还会按预设的第二周期(一小时、半小时或一天等)获取用户侧使用服务商品的使用信息，并根据使用信息生成账单数据，再根据生成的账单数据，识别用户侧是否存在存款不足风险。
在一种实现方式中，识别用户侧是否存在存款不足风险的过程为：将新生成的账单数据和该用户侧的其他行为特征数据作为新的用户信息，再采用步骤S201～S202的方法确定出当前购买权限，通过判断用户当前使用的服务商品是否符合新计算出的当前购买权限，来识别是否存在存款不足风险。
在另一种实现方式中，识别用户侧是否存在存款不足风险的过程为：将新生成的账单数据与该用户侧之前确定出当前购买权限中的延后付款额度进行比对，来识别是否存在存款不足风险。可以是新生成的账单数据的金额大于等于延后付款额度，则认为存在存款不足风险，也可以是新生成的账单数据的金额距延后付款额度的差额小于预设差额，则认为存在存款不足风险。
进一步，在识别出用户侧存在存款不足风险之后，可以设置从用户侧对应的账户中扣除该用户侧已消费但尚未扣款的费用，以减少坏账风险。如果扣除不成功，则禁止用户侧继续使用服务商品，减少损失。还可以对扣除不成功的用户侧发送审查信息，以提醒用户侧上传审核资料来申请继续使用商品。
可见，通过本发明实施例提供的风险识别方法，根据用户侧的用户信息来确定用户的信用等级进而确认其当前购买权限，为不同的用户侧定制出符合其自身行为特征的购买权限，从而能根据当前购买权限更准确的识别出该用户侧的订单请求是否存在风险，即减小了服务商的经济损失，也避免了购买权限设置不合适导致的对高信用等级客户的频繁打扰。
以一个具体应用场景说明，例如，在购买云服务商品的场景，用户侧向服务器发送订单请求后，由服务器的在线信用模型以用户侧的用户信息为输入，对用户侧进行打分。并根据打分确认其是否存在存款不足(Non Fufficient Fund,NSF)风险，如果存在则拦截订单，如果不存在则用户下单成功。在用户下单成功后，每小时产生一次该用户侧的账单，结合该账单再采用在线信用模型进行打分，根据打分结果确认是否存在NSF风险。如果不存在风险则不作处理，如果存在风险则触发扣款。如果扣款成功则不作处理，如果扣款不成功则采取对账户持有人的强化审查来了解资金来源的合法性(Know Your Customer,KYC)或禁止使用商品等措施。
第二方面，基于同一发明构思，本说明书实施例提供一种风险识别装置，参见图3，所述风险识别装置，包括：
等级确定单元301，用于获取表征用户侧的行为特征的用户信息，并基于所述用户 信息确定所述用户侧的信用等级；
权限确定单元302，用于根据所述信用等级和预存的信用等级与购买权限的对应关系，确定所述用户侧的当前购买权限；
识别单元303，用于根据所述当前购买权限，识别所述用户侧发送的订单请求是否存在风险。
在一种可选的方式中，所述用户信息，包括：所述用户侧的注册信息、历史付费信息或设备状态信息中的任一种或多种组合。
在一种可选的方式中，所述等级确定单元301还用于：以所述用户信息作为预设模型的输入数据，通过所述预设模型计算确定所述用户侧的信用等级。
在一种可选的方式中，所述等级确定单元301还用于：以所述用户信息作为预设模型的输入数据，通过所述预设模型计算输出所述用户侧的信用分数；根据所述信用分数和预存的信用分数与信用等级的对应关系，确定所述用户侧的信用等级。
在一种可选的方式中，所述权限确定单元302还用于：确定所述用户侧允许购买的产品种类、产品数量或延后付款额度中的任一种或多种组合。
在一种可选的方式中，所述的装置还包括：
处理单元304，用于如果所述订单请求不存在风险，则向所述用户侧提供所述订单请求对应的服务商品；如果所述订单请求存在风险，则拦截所述订单请求。
在一种可选的方式中，所述处理单元304还用于：按预设的第二周期获取所述用户侧使用所述服务商品的使用信息，并根据所述使用信息生成账单数据；根据所述账单数据，识别所述用户侧是否存在存款不足风险。
在一种可选的方式中，所述处理单元304还用于：如果所述订单请求存在存款不足风险，则从所述用户侧对应的账户中扣除所述用户侧已消费但尚未扣款的费用。
在一种可选的方式中，所述处理单元304还用于：如果扣除不成功，则禁止所述用户侧使用所述服务商品。
在一种可选的方式中，所述等级确定单元301还用于：在接收所述用户侧发送的所述订单请求时，响应所述订单请求，从而获取表征用户侧的行为特征的用户信息。
在一种可选的方式中，所述等级确定单元301还用于：按预设的第一周期，获取表征用户侧的行为特征的用户信息。
在一种可选的方式中，所述权限确定单元302还用于：接收所述用户侧发送的所述订单请求；响应所述订单请求，根据所述当前购买权限，识别所述用户侧发送的订单请求是否存在风险。
第三方面，基于与前述实施例中风险识别方法同样的发明构思，本发明还提供一种服务器，如图4所示，包括存储器404、处理器402及存储在存储器404上并可在处理器402上运行的计算机程序，所述处理器402执行所述程序时实现前文所述风险识别方法的任一方法的步骤。
其中，在图4中，总线架构(用总线400来代表)，总线400可以包括任意数量的互联的总线和桥，总线400将包括由处理器402代表的一个或多个处理器和存储器404代表的存储器的各种电路链接在一起。总线400还可以将诸如外围设备、稳压器和功率管理电路等之类的各种其他电路链接在一起，这些都是本领域所公知的，因此，本文不再对其进行进一步描述。总线接口406在总线400和接收器401和发送器403之间提供接口。接收器401和发送器403可以是同一个元件，即收发机，提供用于在传输介质上与各种其他装置通信的单元。处理器402负责管理总线400和通常的处理，而存储器404可以被用于存储处理器402在执行操作时所使用的数据。
第四方面，基于与前述实施例中风险识别方法的发明构思，本发明还提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现前文所述风险识别方法的任一方法的步骤。
本说明书是参照根据本说明书实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的设备。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令设备的制造品，该指令设备实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
尽管已描述了本说明书的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本说明书范围的所有变更和修改。
显然，本领域的技术人员可以对本说明书进行各种改动和变型而不脱离本说明书的精神和范围。这样，倘若本说明书的这些修改和变型属于本说明书权利要求及其等同技术的范围之内，则本说明书也意图包含这些改动和变型在内。
Claims (26)
- 一种风险识别方法，包括：获取表征用户侧的行为特征的用户信息，并基于所述用户信息确定所述用户侧的信用等级；根据所述信用等级和预存的信用等级与购买权限的对应关系，确定所述用户侧的当前购买权限；根据所述当前购买权限，识别所述用户侧发送的订单请求是否存在风险。
- 如权利要求1所述的方法，所述用户信息，包括：所述用户侧的注册信息、历史付费信息或设备状态信息中的任一种或多种组合。
- 如权利要求1所述的方法，所述基于所述用户信息确定所述用户侧的信用等级，包括：以所述用户信息作为预设模型的输入数据，通过所述预设模型计算确定所述用户侧的信用等级。
- 如权利要求3所述的方法，所述以所述用户信息作为预设模型的输入数据，通过所述预设模型计算确定所述用户侧的信用等级，包括：以所述用户信息作为预设模型的输入数据，通过所述预设模型计算输出所述用户侧的信用分数；根据所述信用分数和预存的信用分数与信用等级的对应关系，确定所述用户侧的信用等级。
- 如权利要求1所述的方法，所述确定所述用户侧的当前购买权限，包括：确定所述用户侧允许购买的产品种类、产品数量或延后付款额度中的任一种或多种组合。
- 如权利要求1所述的方法，所述识别所述用户侧发送的订单请求是否存在风险之后，还包括：如果所述订单请求不存在风险，则向所述用户侧提供所述订单请求对应的服务商品；如果所述订单请求存在风险，则拦截所述订单请求。
- 如权利要求6所述的方法，所述向所述用户侧提供所述订单请求对应的服务商品之后，还包括：按预设的第二周期获取所述用户侧使用所述服务商品的使用信息，并根据所述使用信息生成账单数据；根据所述账单数据，识别所述用户侧是否存在存款不足风险。
- 如权利要求7所述的方法，所述识别所述用户侧是否存在存款不足风险之后，还包括：如果所述订单请求存在存款不足风险，则从所述用户侧对应的账户中扣除所述用户侧已消费但尚未扣款的费用。
- 如权利要求8所述的方法，所述从所述用户侧对应的账户中扣除所述用户侧已消费但尚未扣款的费用之后，还包括：如果扣除不成功，则禁止所述用户侧使用所述服务商品。
- 如权利要求1所述的方法，所述获取表征用户侧的行为特征的用户信息的时机为：在接收所述用户侧发送的所述订单请求时，响应所述订单请求，从而获取表征用户侧的行为特征的用户信息。
- 如权利要求1所述的方法，所述获取表征用户侧的行为特征的用户信息的时机为：按预设的第一周期，获取表征用户侧的行为特征的用户信息。
- 如权利要求11所述的方法，所述方法还包括：接收所述用户侧发送的所述订单请求；所述根据所述当前购买权限，识别所述用户侧发送的订单请求是否存在风险，包括：响应所述订单请求，根据所述当前购买权限，识别所述用户侧发送的订单请求是否存在风险。
- 一种风险识别装置，包括：等级确定单元，用于获取表征用户侧的行为特征的用户信息，并基于所述用户信息确定所述用户侧的信用等级；权限确定单元，用于根据所述信用等级和预存的信用等级与购买权限的对应关系，确定所述用户侧的当前购买权限；识别单元，用于根据所述当前购买权限，识别所述用户侧发送的订单请求是否存在风险。
- 如权利要求13所述的装置，所述用户信息，包括：所述用户侧的注册信息、历史付费信息或设备状态信息中的任一种或多种组合。
- 如权利要求13所述的装置，所述等级确定单元还用于：以所述用户信息作为预设模型的输入数据，通过所述预设模型计算确定所述用户侧的信用等级。
- 如权利要求15所述的装置，所述等级确定单元还用于：以所述用户信息作为预设模型的输入数据，通过所述预设模型计算输出所述用户侧的信用分数；根据所述信用分数和预存的信用分数与信用等级的对应关系，确定所述用户侧的信用等级。
- 如权利要求13所述的装置，所述权限确定单元还用于：确定所述用户侧允许购买的产品种类、产品数量或延后付款额度中的任一种或多种组合。
- 如权利要求13所述的装置，还包括：处理单元，用于如果所述订单请求不存在风险，则向所述用户侧提供所述订单请求对应的服务商品；如果所述订单请求存在风险，则拦截所述订单请求。
- 如权利要求18所述的装置，所述处理单元还用于：按预设的第二周期获取所述用户侧使用所述服务商品的使用信息，并根据所述使用信息生成账单数据；根据所述账单数据，识别所述用户侧是否存在存款不足风险。
- 如权利要求19所述的装置，所述处理单元还用于：如果所述订单请求存在存款不足风险，则从所述用户侧对应的账户中扣除所述用户侧已消费但尚未扣款的费用。
- 如权利要求20所述的装置，所述处理单元还用于：如果扣除不成功，则禁止所述用户侧使用所述服务商品。
- 如权利要求13所述的装置，所述等级确定单元还用于：在接收所述用户侧发送的所述订单请求时，响应所述订单请求，从而获取表征用户侧的行为特征的用户信息。
- 如权利要求13所述的装置，所述等级确定单元还用于：按预设的第一周期，获取表征用户侧的行为特征的用户信息。
- 如权利要求23所述的装置，所述权限确定单元还用于：接收所述用户侧发送的所述订单请求；响应所述订单请求，根据所述当前购买权限，识别所述用户侧发送的订单请求是否存在风险。
- 一种服务器，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现权利要求1-12任一项所述方法的步骤。
- 一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现权利要求1-12任一项所述方法的步骤。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201810790676.3 | 2018-07-18 | ||
| CN201810790676.3A CN109034823A (zh) | 2018-07-18 | 2018-07-18 | 风险识别方法、装置及服务器 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| WO2020015484A1 true WO2020015484A1 (zh) | 2020-01-23 |
Family
ID=64644009
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| PCT/CN2019/091033 WO2020015484A1 (zh) | 2018-07-18 | 2019-06-13 | 风险识别方法、装置及服务器 |
Country Status (3)
| Country | Link |
|---|---|
| CN (1) | CN109034823A (zh) |
| TW (1) | TWI759596B (zh) |
| WO (1) | WO2020015484A1 (zh) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112819476A (zh) * | 2021-02-25 | 2021-05-18 | 北京互金新融科技有限公司 | 风险识别方法、装置、非易失性存储介质和处理器 |
| CN113761908A (zh) * | 2020-11-26 | 2021-12-07 | 北京沃东天骏信息技术有限公司 | 一种存量用户信息的处理方法和装置 |
Families Citing this family (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109034823A (zh) * | 2018-07-18 | 2018-12-18 | 阿里巴巴集团控股有限公司 | 风险识别方法、装置及服务器 |
| CN110060047A (zh) * | 2019-03-28 | 2019-07-26 | 阿里巴巴集团控股有限公司 | 基于交易的信用风险判别方法及其装置 |
| CN111260368A (zh) * | 2020-01-08 | 2020-06-09 | 支付宝(杭州)信息技术有限公司 | 一种账户交易风险判断方法、装置及电子设备 |
| CN111222889B (zh) * | 2020-01-16 | 2022-05-17 | 支付宝(杭州)信息技术有限公司 | 交易免打扰服务的获取方法及装置 |
| CN111681118B (zh) * | 2020-05-29 | 2024-03-15 | 泰康保险集团股份有限公司 | 一种数据处理方法及装置 |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102194177A (zh) * | 2011-05-13 | 2011-09-21 | 南京柯富锐软件科技有限公司 | 一种用于在线支付风险控制的系统 |
| CN105608580A (zh) * | 2015-12-15 | 2016-05-25 | 百纳（武汉）信息技术有限公司 | 一种移动端支付方法及移动端支付系统 |
| CN109034823A (zh) * | 2018-07-18 | 2018-12-18 | 阿里巴巴集团控股有限公司 | 风险识别方法、装置及服务器 |
Family Cites Families (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7792743B2 (en) * | 2007-05-02 | 2010-09-07 | Google Inc. | Flexible advertiser billing system with mixed postpayment and prepayment capabilities |
| CN101308562A (zh) * | 2008-06-30 | 2008-11-19 | 北京金山软件有限公司 | 网络游戏中提供游戏体验服务的方法及装置 |
| CN104778623A (zh) * | 2015-04-02 | 2015-07-15 | 浙江吉利控股集团有限公司 | 用于网络交易平台的网络交易系统和交易平台服务器 |
| CN107808283A (zh) * | 2016-09-09 | 2018-03-16 | 腾讯科技（深圳）有限公司 | 订单处理方法、装置及系统 |
| CN108074084A (zh) * | 2016-11-18 | 2018-05-25 | 腾讯科技（深圳）有限公司 | 一种延迟处理请求的方法、装置及服务器 |
| CN106897871A (zh) * | 2017-03-02 | 2017-06-27 | 杭州陆港科技有限公司 | 一种购物方法和计算机可读存储媒体 |
| CN108133372B (zh) * | 2017-12-28 | 2022-02-18 | 蚂蚁智安安全技术(上海)有限公司 | 评估支付风险的方法及装置 |
-
2018
- 2018-07-18 CN CN201810790676.3A patent/CN109034823A/zh active Pending
-
2019
- 2019-05-08 TW TW108115877A patent/TWI759596B/zh active
- 2019-06-13 WO PCT/CN2019/091033 patent/WO2020015484A1/zh active Application Filing
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102194177A (zh) * | 2011-05-13 | 2011-09-21 | 南京柯富锐软件科技有限公司 | 一种用于在线支付风险控制的系统 |
| CN105608580A (zh) * | 2015-12-15 | 2016-05-25 | 百纳（武汉）信息技术有限公司 | 一种移动端支付方法及移动端支付系统 |
| CN109034823A (zh) * | 2018-07-18 | 2018-12-18 | 阿里巴巴集团控股有限公司 | 风险识别方法、装置及服务器 |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113761908A (zh) * | 2020-11-26 | 2021-12-07 | 北京沃东天骏信息技术有限公司 | 一种存量用户信息的处理方法和装置 |
| CN112819476A (zh) * | 2021-02-25 | 2021-05-18 | 北京互金新融科技有限公司 | 风险识别方法、装置、非易失性存储介质和处理器 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN109034823A (zh) | 2018-12-18 |
| TWI759596B (zh) | 2022-04-01 |
| TW202006636A (zh) | 2020-02-01 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| WO2020015484A1 (zh) | 风险识别方法、装置及服务器 | |
| US11875350B2 (en) | Systems and methods for improved fraud detection | |
| US20200058027A1 (en) | Systems and methods for blocking credit card charges | |
| KR101458593B1 (ko) | 온라인 거래 검증 방법 및 시스템 | |
| AU2020201684A1 (en) | Method of processing a transaction request | |
| US9928549B2 (en) | Methods and systems for expedited trading account funding | |
| WO2016036890A2 (en) | System and method for performing payment authorization verification using geolocation data | |
| KR20180023603A (ko) | 대출 중개 시스템 및 이에 이용되는 중개 서버 | |
| WO2019177722A1 (en) | Systems, methods and computer program products for automated bill payment | |
| CN113159859A (zh) | 一种费用调整方法和装置 | |
| KR102215542B1 (ko) | 데이터 서비스 처리 | |
| US20230050176A1 (en) | Method of processing a transaction request | |
| US20200286065A1 (en) | Systems and methods for managing transactions by consolidating associated transactions | |
| US11321128B2 (en) | System for resource allocation via an intermediate resource volume adjustment sub-system | |
| CN114066615A (zh) | 受托支付方法、装置、电子设备和存储介质 | |
| JP6423031B2 (ja) | 情報処理装置及びプログラム | |
| CN111429092A (zh) | 缴存公积金的方法、装置、设备和计算机可读介质 | |
| KR101568414B1 (ko) | 리스크 관리 서비스 제공 방법 | |
| TW201743270A (zh) | 一種連續性動態融資方法與系統 | |
| KR20230036715A (ko) | 중고폰 시세조회가 가능한 중고폰 악세사리 거래 중개 플랫폼 | |
| KR20230116279A (ko) | 핸드폰 수리 업체 중개 및 악세사리 판매 서비스 플랫폼 | |
| CN117035984A (zh) | 数据处理方法、装置、设备、可读存储介质和程序产品 | |
| KR20170055291A (ko) | 은행 서버 및 기부금 관리 서비스 방법 | |
| CN115345682A (zh) | 一种企业的返利管理方法、装置、电子设备及存储介质 | |
| CN115619521A (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: 19837111 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: 19837111 Country of ref document: EP Kind code of ref document: A1 |