WO2021063015A1

WO2021063015A1 - Risk control method, system, device, and equipment

Info

Publication number: WO2021063015A1
Application number: PCT/CN2020/094591
Authority: WO
Inventors: 薛琼; 杨陆毅; 陈弢
Original assignee: 支付宝(杭州)信息技术有限公司
Priority date: 2019-09-30
Filing date: 2020-06-05
Publication date: 2021-04-08
Also published as: CN110738473B; CN110738473A

Abstract

A risk control method, a system, a device, and equipment. The method comprises: when a user can log in to different payment subsystems using a same account and password, performing risk identification with respect to service data of any of the systems and, when the risk identification result is produced, generating a shared risk feature applicable among the multiple subsystems, thus allowing any other of the subsystems to identity service data of self on the basis of the shared risk feature.

Description

Risk control methods, systems, devices and equipment

Technical field

The embodiments of this specification relate to the field of information technology, and in particular to risk control methods, systems, devices, and equipment.

Background technique

In payment applications, in order to promote third-party payment software in different regions, the following methods are often used: a set of account numbers and passwords can be adapted to multiple payment subsystems. For example, using Alipay account and password, you can open and use Alipay Hong Kong local wallet AlipayHK and Alipay Macau local wallet.

In this way, due to the different regions of the wallets of each site, the problem that the same set of account secrets can log in to multiple payment subsystems has brought potential cross-system account theft. Based on this, a risk control solution that adapts to multiple payment subsystems using the same account secret is needed.

Summary of the invention

The purpose of the embodiments of this application is to provide a risk control solution when multiple payment subsystems use the same account secret.

In order to solve the above technical problems, the embodiments of the present application are implemented as follows:

On the one hand, the embodiments of this specification provide a risk control method, which is applied to multiple payment subsystems that can log in with the same account and password, and the method includes: the first payment subsystem obtains the first business data generated by the user ; Perform risk identification on the first business data, generate and store the shared risk characteristics associated with the user that can be used in the multiple payment subsystems; the second payment subsystem obtains the user’s own system And the shared risk characteristics of the second business data, and risk identification is performed on the second business data according to the shared risk characteristics.

Corresponding to one aspect, the embodiment of this specification also provides a risk control system, which includes multiple payment subsystems that can log in with the same account and password. In the risk control system, the first payment subsystem Acquire the first business data generated by the user; perform risk identification on the first business data, generate and store the shared risk characteristics associated with the user that can be used in the multiple payment subsystems; the second payment subsystem Acquire the second business data and the shared risk characteristics generated by the user on the user's own system, and perform risk identification on the second business data according to the shared risk characteristics.

On the other hand, the embodiment of this specification also provides a risk control method, which is applied to the second payment subsystem. The method includes: obtaining second business data generated by a user; obtaining shared risk characteristics associated with the user , Wherein the shared risk feature is pre-generated by the first payment subsystem based on the first business data for risk identification, and the login account and password of the first payment subsystem and the second payment subsystem are the same; The risk feature performs risk identification on the second business data.

Corresponding to another aspect, the embodiment of this specification also provides a risk control device, which is applied to the second payment subsystem, the device includes: a business data acquisition module, which acquires second business data generated by a user; risk characteristics The acquiring module acquires the shared risk characteristics associated with the user, wherein the shared risk characteristics are pre-generated by other first payment subsystems based on the first business data for risk identification, the first payment subsystem and the second The login account and password of the payment subsystem are the same; the risk identification module performs risk identification on the second business data according to the shared risk feature.

Through the solution provided by the embodiment of this specification, when a user can log in between different payment subsystems using the same account and password, risk identification is performed on the business data of any one of the systems, and after the risk identification result is obtained, it will be generated that can be used for multiple The risk characteristics of each subsystem are shared, so that any other subsystem can identify its own business data based on the shared risk characteristics. In each payment subsystem with the same account password and relatively independent business, it can achieve targeted cross-cutting Prevention and control of site theft risk.

It should be understood that the above general description and the following detailed description are only exemplary and explanatory, and cannot limit the embodiments of this specification.

In addition, any one of the embodiments of the present specification does not need to achieve all the above-mentioned effects.

Description of the drawings

In order to more clearly describe the technical solutions in the embodiments of this specification, the following will briefly introduce the drawings needed in the description of the embodiments. Obviously, the drawings in the following description are only those recorded in the embodiments of this specification. For some embodiments, those of ordinary skill in the art can also obtain other drawings based on these drawings.

Figure 1 is a schematic diagram of a payment subsystem provided by an embodiment of the specification;

FIG. 2 is a schematic flowchart of a risk control method provided by an embodiment of this specification;

FIG. 3 is a schematic diagram of the risk control method based on different assets provided by the embodiments of this specification;

Figure 4 is a schematic flow diagram of another risk control method provided by the embodiments of this specification

Figure 5 is a schematic structural diagram of a wind control device provided by an embodiment of this specification;

Fig. 6 is a schematic structural diagram of a device for configuring the method of the embodiment of this specification.

Detailed ways

In order to enable those skilled in the art to better understand the technical solutions in the embodiments of this specification, the technical solutions in the embodiments of this specification will be described in detail below in conjunction with the drawings in the embodiments of this specification. Obviously, the described implementation The examples are only a part of the embodiments in this specification, not all the embodiments. Based on the embodiments in this specification, all other embodiments obtained by those of ordinary skill in the art should fall within the scope of protection.

In the current business system, in order to promote business, the following methods are often used: a set of account numbers and passwords can be adapted to multiple payment subsystems. For example, users who have registered for the Ant Pass can use the account and password of the Ant Pass to open or log in to the electronic wallets provided by Alipay in other regions, such as Alipay Hong Kong local wallet Alipay HK and Alipay Macau local wallet. As shown in Fig. 1, Fig. 1 is a schematic diagram of a risk control system provided by an embodiment of this specification. In this schematic diagram, the risk control system contains multiple payment subsystems, and each payment subsystem can use the same user account and password to log in, and the business functions of each payment subsystem are the same.

For example, in practical applications, an implementable way is to configure in advance in each payment subsystem to identify a universal pass. Users can register a pass based on a certain payment subsystem, and then use the same set of user accounts and passwords among multiple payment subsystems in the form of passes.

Or, the user can also authorize the user account and password in one payment subsystem to another payment subsystem through authorization. For example, if the user has activated the Hong Kong Alipay application, when the user needs to use the Macau Alipay application, he will use the Hong Kong Alipay application to authorize the registered account and password in the Hong Kong Alipay application to log in.

The same business function refers to that there are business functions owned by the first payment subsystem and also owned by the second payment subsystem, such as payment, transfer, recharge and payment, financial management, etc., and more The assets and business data of each payment subsystem are independent.

In this cross-site approach, the same set of account secrets can log into multiple payment subsystems, which further brings corresponding cross-site fraudulent use risks. For example, if a gangster succeeds in stealing an account or password in the first payment subsystem, it is possible to log in to the second payment subsystem based on the account to embezzle assets. Based on this, the embodiment of this specification provides a risk control solution to solve this cross-site fraud problem.

The following describes in detail the technical solutions provided by the embodiments of this specification in conjunction with the accompanying drawings. On the one hand, as shown in Figure 2, Figure 2 is a schematic flow diagram of a risk control method provided by an embodiment of this specification, which is applied to multiple payment subsystems that can log in with the same account and password. The flow specifically includes the following step:

S201: The first payment subsystem obtains first service data generated by the user.

First of all, it should be noted that the first payment subsystem is relative to the second and other payment subsystems. It is only for the convenience of description, and there is no substantial difference between the subsystems, that is, the first The payment subsystem and the second payment subsystem are relative terms.

For example, the first payment subsystem may be an Alipay application in the mainland area, and the second payment subsystem may be an Alipay application in Hong Kong and Macau; or the first payment subsystem may be an Alipay application in Hong Kong and the second payment subsystem may be an Alipay application in the mainland area.

Since the business data of each payment subsystem is independent, the first business data refers to the business data generated by the user in the first payment subsystem, and the second business data is the same.

The business data may include types of business data, which may include various transaction data, usage logs of various business functions in the application, user system setting data (for example, login/offline logs, passwords, user nicknames, contact information modification setting data) and many more.

S203: Perform risk identification on the first business data, generate and store shared risk characteristics associated with the user that can be used in the multiple payment subsystems.

Although the business functions of each payment system are the same, because they are used in different regions, in fact, many of the risk characteristics are regional and cannot be shared. For example, the average monthly consumption of the same feature is different in different regions. Therefore, the value of this feature cannot be shared among payment subsystems.

In the embodiments of this specification, shared risk characteristics refer to characteristics that cause risks in each payment system, for example, it may be risk characteristics related to account numbers and passwords. Two examples are given below to identify risks from two aspects to obtain shared risk characteristics that can be adapted to cross-system use, including login risk characteristics and password modification risk characteristics.

(1) Logging risk characteristics.

Specifically, the first payment subsystem receives the user's login instruction; calls historical business data containing the first payment subsystem identifier to identify the risk of the login instruction, generates a login risk identification result, and based on the login risk identification result Generate login risk characteristics shared among multiple subsystems.

It should be noted that in the process of identifying the login risk, the first payment subsystem only needs to call the first historical business data for identification, and does not involve the business data of other subsystems. In an implementation manner, the business data of each payment subsystem can be unified into the business system for centralized storage, but the business data of the subsystems are separately identified. For example, the business data generated by the user on each payment subsystem is centralized in the payment subsystem for centralized storage. The types of business data may include various transaction data, usage logs of various business functions in the application, user system setting data (for example, password, user nickname, contact information modification setting data), and so on.

At the same time, in order to more clearly define the boundaries of the business data of each payment subsystem, when the user generates the business data, it clearly indicates the payment subsystem to which the business data belongs. For example, the number "CN" is used to characterize the business data generated based on the mainland payment application, and the number "HK" is used to characterize the business data generated based on the Hong Kong Alipay application.

It should be noted that the number "CN" or "HK" here characterizes the "payment subsystem that generates business data", rather than "the place where the business data is generated". For example, a visitor from the mainland area uses a mainland payment application when making payments in Hong Kong. Since the payment application used by the visitor is "Mainland Payment Application", he will also use "CN" when identifying business data. Stored in the payment subsystem.

Through the foregoing method, the business data between multiple payment subsystems can be isolated, so that when performing risk identification, risk identification can be performed in a targeted manner. For example, when a user logs in to the first payment subsystem, the user can perform operations (such as account number, password, and verification code retries) and historical business data (such as transaction frequency, total amount) generated by the user in the first payment subsystem. , Average amount, etc.), and other risk-related data information (for example, historical login location, historical login failure times, etc.) to identify the risk of this login, and generate the corresponding risk identification result can be a labeled data, For example, the risk identification result is risky or no risk, or, based on the behavior and historical data of this login, the risk identification result can also be a risk assessment value.

Furthermore, the login risk feature can be generated according to the login risk identification result. For example, the log-in result is digitized as the characteristic value of the log-in risk feature. The log-in risk feature represents the user's login situation on the first payment subsystem, and is used in any subsystem of the business system (including the first payment subsystem). ) When receiving the user's login instruction, evaluate the login risk.

It is easy to understand that, correspondingly, any other subsystem will also generate another corresponding login risk feature, and multiple login risk features can be used for risk assessment at the same time.

(2) Password modification risk characteristics.

Specifically, the first payment subsystem accepts the user's instruction to modify the password initiated by the first payment subsystem; obtains the total amount of asset data of the user account on multiple payment subsystems; and calls the corresponding asset data based on the total amount of asset data A risk control strategy for password modification; after the user has finished modifying the password, a password modification risk feature containing the modification result is generated.

In the embodiment of this specification, if the user initiates a successful password modification, any password modification behavior in any payment subsystem will overwrite other payment subsystems. In other words, the assets between the payment subsystems are risk-related. In other words, after it has been determined that the user can log in to different payment subsystems based on the same account secret, if the user changes the password, it is necessary to determine the user's assets between different systems and adjust the risk control strategy according to the total assets.

One possible implementation is to determine the total amount of users' assets between systems. If the total amount is larger, the risk control strategy with higher precision will be invoked. For example, suppose that the user’s asset on the first payment subsystem is 0, and the asset on the second payment subsystem is 100,000. At this time, even if the user initiates a password modification instruction on the first payment subsystem, The payment subsystem will also call the risk control strategy corresponding to one hundred thousand assets based on the total assets of one hundred thousand, instead of the risk control strategy corresponding to asset 0. Generally speaking, the larger the asset amount, the higher the level of the corresponding risk control strategy, and the higher the level of the risk control strategy, the greater the precision. The greater the degree of refinement means that the more features will be used for user risk identification, and the more cautious the risk assessment will be.

For example, for users with low or no assets, use dynamic passwords, (One-time Password, OTP) single-factor verification, and generate a time-related and unpredictable random number combination at regular intervals for users to enter verification; For users with higher assets, two-factor verification (for example, combining user ID number and biological characteristics, such as ID number plus fingerprint; or, adopting a risk identification model containing multiple characteristics for risk identification) or manual review Carry out risk control in other ways. As shown in Fig. 3, Fig. 3 is a schematic diagram of the risk control method based on different assets provided by the embodiments of this specification.

By invoking the corresponding risk control strategy for the user's asset quota, risk and interference in risk control can be balanced, and system overhead can be reduced.

Further, in an implementable manner, the method that can be used is to determine whether the user has assets among the accounts, and assign an asset status label according to whether there is an asset. For example, if there are assets in any account, the value of the tag is 1, and if all accounts have no assets, the value of the tag is 0. State-based processing of tags through assets can hide the user's asset quota, realize the desensitization of the user's assets, and protect the user's privacy.

After the user initiates an instruction to modify the password based on the client, correspondingly, this modification either succeeds or fails (interruption will also be regarded as a modification failure). Further, the payment subsystem may use "modify password" as a feature, and generate a feature value based on the number of times the password is initiated and whether it is successful. For example, the proportion of the number of successes in the total number of times is used as the feature value, and the password is The modified risk feature is associated with the user account so that it can be called at any time.

In the password modification risk feature, all subsystems can use the same parameter, that is, the user's password modification situation on different payment subsystems will be statistically reflected to the same password modification risk feature, and the feature value will be dynamic modify. It is easy to understand that in practical applications, there can also be more shared risk features that can be used, as long as the use of the risk features meets the spirit of this application.

S205: The second payment subsystem obtains the second business data generated by the user on its own system and the shared risk characteristics, and performs risk identification on the second business data according to the shared risk characteristics.

Through the foregoing method, multiple shared wind direction characteristics of a user have been obtained between business systems. Therefore, when the user logs in on another payment subsystem (ie, the second payment system) and generates corresponding business data (including login data, password modification data, payment transaction data, etc.), the other payment subsystem is The shared risk characteristics of the user can be obtained for risk identification of business data, so as to achieve cross-site risk prevention and control.

For example, in one embodiment, when a user conducts transactions in any subsystem through the client, the subsystem can call the password related to the user account from the risk control system to modify the risk characteristics for the user’s transaction The instructions are evaluated.

Specifically, the risk control system can first obtain the historical data of each user's password modification, and based on the historical data, it contains training samples of password modification risk characteristics (of course, it can also contain other characteristics, such as the transaction location and the risk value of the transaction object, Transaction frequency, etc.), in the sample, the proportion of the number of successes in the total number of times is used as the characteristic value (or the ratio of the number of successes to the number of failures is used as the characteristic value, etc.), and whether the user is at risk is used as a label (ie The risk of training samples is already known), model training is carried out according to the above samples, and a usable model whose accuracy rate meets the expectations is obtained.

After obtaining the available model, for the user transaction sent from any subsystem, obtain the user's password modification risk characteristics and other characteristics, and generate samples to be evaluated for risk assessment. By adding cross-site modified tag data as a risk feature to risk identification, it is possible to effectively implement cross-system account embezzlement risk prevention and control when multiple payment subsystems use the same account secret.

Through the solution provided by the embodiment of this specification, when a user can log in between different payment subsystems using the same account and password, risk identification is performed on the business data of any one of the systems, and after the risk identification result is obtained, it will be generated that can be used for multiple Shared risk characteristics among the various subsystems, so that any other subsystem can identify its own business data based on the shared risk characteristics, and achieve targeted cross-sites in payment subsystems with the same account and password while being relatively independent Prevention and control of the risk of misappropriation.

Corresponding to one aspect, the embodiment of this specification also provides a risk control system, which includes multiple payment subsystems that can log in with the same account and password. In the risk control system,

The first payment subsystem obtains the first business data generated by the user; performs risk identification on the first business data, generates and stores the shared risk characteristics associated with the user that can be used in the multiple payment subsystems;

The second payment subsystem obtains the second business data and the shared risk characteristics generated by the user on its own system, and performs risk identification on the second business data according to the shared risk characteristics.

Further, in the system, the first payment subsystem receives a user's login instruction; calls historical business data containing the first payment subsystem identifier to identify the risk of the login instruction, and generates a login risk identification result, where: The historical business data including the identification of the first payment subsystem is generated and stored when the user uses the first payment subsystem for business processing; and the log-in risk feature is generated according to the log-in risk identification result.

Further, in the system, the first payment subsystem accepts the user's instruction to modify the password initiated by the first payment subsystem; obtains the total amount of asset data of the user account on multiple payment subsystems; The total amount of asset data calls the corresponding risk control strategy for modifying the password; after the user has finished modifying the password, a password modification risk feature including the modification result is generated.

Further, in the system, invoking the corresponding risk control strategy for modifying the password according to the total amount of asset data includes: the greater the asset data of the user account in the first payment subsystem and the second payment subsystem, the greater The higher the level of the risk control strategy for modifying the password, the level is positively correlated with the fineness of the risk control strategy.

Further, in the system, the second payment subsystem receives a transaction instruction initiated by the user in the second payment subsystem; obtains the password modification risk characteristic associated with the user, and compares the password modification characteristic data with the user according to the password modification characteristic data. The transaction instructions are described for risk identification.

On the other hand, the embodiment of this specification also provides a risk control method, which is applied to the second payment subsystem, as shown in FIG. 4, which is an example of another aspect of the risk control method provided by the embodiment of this specification. Schematic diagram of the process, including:

S401: Acquire second service data generated by a user;

S403. Acquire a shared risk feature associated with the user, where the shared risk feature is pre-generated by the first payment subsystem based on the first business data for risk identification, and the first payment subsystem and the second payment sub-system The login account and password of the system are the same;

S405: Perform risk identification on the second business data according to the shared risk feature.

It should be noted that shared risk characteristics can be generated between any payment subsystem, and any payment subsystem can also call shared risk characteristics generated by other subsystems and perform risk identification. The aforementioned "first payment subsystem" and "second payment subsystem" are for descriptive purposes only, and do not refer to a specific subsystem. In the risk control system, any payment subsystem is in one It can be the "first payment subsystem" in the process, or the "second payment subsystem" in another process.

Corresponding to another aspect, the embodiment of this specification also provides a risk control device, which is applied to the second payment subsystem, as shown in FIG. 5, which is a diagram of the risk control device provided by the embodiment of this specification. Schematic diagram of the structure, the device includes:

The business data acquisition module 501 acquires the second business data generated by the user;

A risk feature acquisition module 503, which acquires shared risk features associated with the user, where the shared risk features are pre-generated by other first payment subsystems based on the first business data for risk identification, and the first payment subsystem Same as the login account and password of the second payment subsystem;

The risk identification module 505 performs risk identification on the second business data according to the shared risk characteristics.

The embodiments of this specification also provide a computer device, which at least includes a memory, a processor, and a computer program stored in the memory and running on the processor, wherein the processor implements the wind shown in FIG. 4 when the program is executed.控方法。 Control method.

FIG. 6 shows a more specific hardware structure diagram of a computing device provided by an embodiment of this specification. The device may include a processor 1010, a memory 1020, an input/output interface 1030, a communication interface 1040, and a bus 1050. The processor 1010, the memory 1020, the input/output interface 1030, and the communication interface 1040 realize the communication connection between each other in the device through the bus 1050.

The processor 1010 may be implemented by a general CPU (Central Processing Unit, central processing unit), microprocessor, application specific integrated circuit (Application Specific Integrated Circuit, ASIC), or one or more integrated circuits, etc., for execution related Program to realize the technical solutions provided in the embodiments of this specification.

The memory 1020 may be implemented in the form of ROM (Read Only Memory), RAM (Random Access Memory), static storage device, dynamic storage device, etc. The memory 1020 may store an operating system and other application programs. When the technical solutions provided in the embodiments of this specification are implemented by software or firmware, related program codes are stored in the memory 1020 and called and executed by the processor 1010.

The input/output interface 1030 is used to connect an input/output module to realize information input and output. The input/output/module can be configured in the device as a component (not shown in the figure), or it can be connected to the device to provide corresponding functions. The input device may include a keyboard, a mouse, a touch screen, a microphone, various sensors, etc., and an output device may include a display, a speaker, a vibrator, an indicator light, and the like.

The communication interface 1040 is used to connect a communication module (not shown in the figure) to realize the communication interaction between the device and other devices. The communication module can realize communication through wired means (such as USB, network cable, etc.), or through wireless means (such as mobile network, WIFI, Bluetooth, etc.).

The bus 1050 includes a path to transmit information between various components of the device (for example, the processor 1010, the memory 1020, the input/output interface 1030, and the communication interface 1040).

It should be noted that although the above device only shows the processor 1010, the memory 1020, the input/output interface 1030, the communication interface 1040, and the bus 1050, in the specific implementation process, the device may also include the equipment necessary for normal operation. Other components. In addition, those skilled in the art can understand that the above-mentioned devices may also include only the components necessary to implement the solutions of the embodiments of the present specification, and not necessarily include all the components shown in the figures.

The embodiment of the present specification also provides a computer-readable storage medium on which a computer program is stored, and when the program is executed by a processor, the risk control method shown in FIG. 4 is implemented.

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 cassettes, magnetic tape magnetic disk 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.

From the description of the foregoing implementation manners, it can be understood that those skilled in the art can clearly understand that the embodiments of this specification can be implemented by means of software plus a necessary general hardware platform. Based on this understanding, the technical solutions of the embodiments of this specification can be embodied in the form of software products, which can be stored in storage media, such as ROM/RAM, A magnetic disk, an optical disk, etc., include several instructions to make a computer device (which may be a personal computer, a server, or a network device, etc.) execute the methods described in the various embodiments or some parts of the embodiments of this specification.

The systems, methods, modules, or units explained in the above embodiments may be implemented by computer chips or entities, or implemented by products with certain functions. A typical implementation device is a computer. The specific form of the computer can be a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email receiving and sending device, and a game control A console, a tablet computer, a wearable device, or a combination of any of these devices.

The various embodiments in this specification are described in a progressive manner, and the same or similar parts between the various embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, as for the method embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and for related parts, please refer to the part of the description of the method embodiment. The method embodiments described above are merely illustrative. The modules described as separate components may or may not be physically separated. When implementing the solutions of the embodiments of this specification, the functions of the modules may be in the same Or multiple software and/or hardware implementations. It is also possible to select some or all of the modules according to actual needs to achieve the objectives of the solutions of the embodiments. Those of ordinary skill in the art can understand and implement it without creative work.

The above are only specific implementations of the embodiments of this specification. It should be pointed out that for those of ordinary skill in the art, without departing from the principle of the embodiments of this specification, several improvements and modifications can be made. These Improvement and retouching should also be regarded as the protection scope of the embodiments of this specification.

Claims

A risk control method is applied to a risk control system containing multiple payment subsystems, wherein the multiple payment subsystems can log in with the same account and password, and the method includes:

The first payment subsystem obtains the first business data generated by the user;

Perform risk identification on the first business data, generate and store shared risk characteristics associated with the user that can be used in the multiple payment subsystems;

The second payment subsystem obtains the second business data and the shared risk characteristics generated by the user on its own system, and performs risk identification on the second business data according to the shared risk characteristics.
5. The method of claim 1, performing risk identification on the first business data to generate shared risk characteristics that can be used in the multiple payment subsystems, comprising:

The first payment subsystem receives the user's login instruction;

Call the historical business data containing the first payment subsystem identification to identify the risk of the login instruction, and generate a login risk identification result, wherein the historical business data containing the first payment subsystem identification is used by the user Generated and stored when the first payment subsystem performs business processing;

Generate a login risk feature according to the login risk identification result.
5. The method of claim 1, performing risk identification on the first business data to generate shared risk characteristics that can be used in the multiple payment subsystems, comprising:

Accepting the password modification instruction initiated by the user in the first payment subsystem;

Obtaining the total amount of asset data of the user account on multiple payment subsystems;

Invoke the corresponding risk control strategy for password modification according to the total amount of asset data;

After the user has finished modifying the password, a password modification risk feature containing the modification result is generated.
The method according to claim 3, invoking a corresponding risk control strategy for modifying a password according to the total amount of asset data, comprising:

The greater the asset data of the user account in the first payment subsystem and the second payment subsystem, the higher the level of risk control strategy for modifying the password is invoked, and the level is positively correlated with the fineness of the risk control strategy.
The method according to claim 3, wherein the second payment subsystem obtains the second business data and the shared risk characteristics generated by the user on its own system, and performs processing on the second business data according to the shared risk characteristics. Risk identification, including:

Receiving a transaction instruction initiated by the user in the second payment subsystem;

Obtain the password modification risk characteristics associated with the user, and perform risk identification on the transaction instruction according to the password modification characteristic data.
A risk control system includes multiple payment subsystems that can log in with the same account and password. In the risk control system,

The first payment subsystem obtains the first business data generated by the user;

Perform risk identification on the first business data, generate and store shared risk characteristics associated with the user that can be used in the multiple payment subsystems;

The second payment subsystem obtains the second business data and the shared risk characteristics generated by the user on its own system, and performs risk identification on the second business data according to the shared risk characteristics.
7. The system of claim 6, wherein the first payment subsystem receives a user's login instruction; calls historical business data containing the first payment subsystem identifier to perform risk identification on the login instruction, and generates a login risk identification result, wherein The historical business data including the identification of the first payment subsystem is generated and stored when the user uses the first payment subsystem to perform business processing; and the log-in risk feature is generated according to the log-in risk identification result.
The system of claim 6, wherein the first payment subsystem accepts an instruction to modify a password initiated by the user in the first payment subsystem; obtains the total amount of asset data of the user account on multiple payment subsystems ; According to the total amount of asset data call the corresponding risk control strategy for modifying the password; after the user has finished modifying the password, a password modification risk feature containing the modification result is generated.
The system according to claim 8, invoking the corresponding risk control strategy for modifying the password according to the total amount of asset data, including:

The greater the asset data of the user account in the first payment subsystem and the second payment subsystem, the higher the level of risk control strategy for modifying the password is invoked, and the level is positively correlated with the fineness of the risk control strategy.
The system according to claim 8, wherein the second payment subsystem receives a transaction instruction initiated by the user in the second payment subsystem; obtains a password modification risk characteristic associated with the user, and modifies the characteristic data pair according to the password The transaction instruction performs risk identification.
A risk control method applied to a second payment subsystem, the method including:

Acquiring the second service data generated by the user;

Acquire the shared risk feature associated with the user, where the shared risk feature is pre-generated by the first payment subsystem to perform risk identification based on the first business data, and the first payment subsystem and the second payment sub-system The login account and password of the system are the same;

Perform risk identification on the second business data according to the shared risk feature.
A risk control device applied to a second payment subsystem, the device comprising:

The business data acquisition module acquires the second business data generated by the user;

The risk feature acquisition module acquires the shared risk features associated with the user, where the shared risk features are pre-generated by the first payment subsystem based on the first business data for risk identification, and the first payment subsystem and the The login account and password of the second payment subsystem are the same;

The risk identification module performs risk identification on the second business data according to the shared risk characteristics.
A computer device, comprising a memory, a processor, and a computer program stored on the memory and running on the processor, wherein the processor executes the program when the program is executed as in any one of claims 1 to 5 and 11. The method described.