TW201828214A - Business handling method and device in which a fast risk recognition operation is carried out first and then a deep risk recognition operation is conducted - Google Patents

Abstract

The application relates to the technical field of Internet, and more particularly to a business handling method and device for saving the consumption of system resources and improving the performance of risk recognition. Embodiments of the application provide a risk recognition method that comprises: conducting fast risk recognition for a business handling request based on a recognition algorithm of a fast risk recognition level; in case that it is not possible to determine the business handling request is a secure request or a risky request after the fast risk recognition, conducting deep risk recognition for the business handling request based on a recognition algorithm of a deep risk recognition level, wherein the amount of data used in the deep risk recognition is greater than the amount of data used in the fast risk recognition and the time period used in conducting the deep risk recognition is longer than the time period used in conducting the fast risk recognition; and processing the business handling request according to the result of the deep risk recognition.

Description

 Business processing method and device  

This application relates to the field of Internet technologies, and in particular, to a service processing method and apparatus.

With the development of Internet information technology, it is becoming more and more common to provide business services to users through the Internet, and there are more and more business service scenarios. While the network business service brings convenience to users, it also brings certain risks. In order to ensure the smooth running of the network service, it is necessary to set up a risk monitoring system to identify the user's business processing request.

As the risk monitoring system needs to monitor the risk of more and more business scenarios and the risk situation becomes more and more complex, the monitoring of various risks and the timeliness of monitoring are becoming more and more high. The rule model for risk identification is coming. The more the calculation, the higher the complexity. These have led to a significant increase in the consumption of system resources by the risk monitoring system and the time taken for analysis.

It can be seen that there is a need to provide a more reasonable risk monitoring method to improve risk analysis performance and save system resource consumption.

The embodiment of the present application provides a service processing method and device, which are used to save system resource consumption and improve risk identification performance.

A service processing method provided by the embodiment of the present application includes: after receiving a service processing request of a user, performing fast risk identification on the service processing request based on a fast risk identification layer identification algorithm; if performing fast risk identification If the service processing request cannot be determined to be risky, the deep risk identification is performed on the service processing request based on the recognition algorithm of the deep risk identification layer; wherein the amount of data used for deep risk identification is greater than the rapid risk identification The amount of data used, and the recognition duration used for depth risk identification is greater than the recognition duration used for rapid risk identification; the business processing request is processed according to the result of performing the depth risk identification.

Optionally, performing fast risk identification on the service processing request based on the fast algorithm of the fast risk identification layer, including: determining, according to user data carried in the service processing request, whether the user data belongs to pre-storage The user data in the trusted user list or the risk user list; if the user data is the user data in the trusted user list, determining that the service processing request is a security request, if the user data is The user data in the risk user list determines that the service processing request is a risk request.

Optionally, if the user data does not belong to the user data in the pre-stored trusted user list, and does not belong to the user data in the pre-stored risk user list, the recognition algorithm based on the fast risk identification layer The method, the fast risk identification of the service processing request, further includes: based on the user data carried in the service processing request, the historical behavior data of the user, and a rule for comparing user behavior data a model, determining whether the current operation behavior of the user indicated by the service processing request matches the historical habitual operation behavior of the user; if the matching, determining that the service processing request is a security request, if not, determining the The business processing request is a risk request.

Optionally, performing the deep risk identification on the service processing request according to the recognition algorithm of the depth risk identification layer, including: selecting at least one risk from the preset multiple risk topics according to the service processing type of the service processing request a topic; selecting, according to the business scenario information corresponding to the service processing request, a rule model for performing second-level risk identification; and performing depth on the service processing request based on the selected rule model Risk Identification.

Optionally, the method further includes: performing comprehensive risk identification on the service processing request based on a comprehensive risk identification layer identification algorithm; wherein the comprehensive risk identification is asynchronous with the fast risk identification and depth risk identification Execution, the amount of data used for comprehensive risk identification is greater than the amount of data used for rapid risk identification and deep risk identification, and the identification time used for comprehensive risk identification is greater than the identification used for rapid risk identification and deep risk identification. Duration; based on the results of comprehensive risk identification, update one or more of the following information: a preset list of trusted users; a preset list of risk users; historical behavior data of the users; and a preset rule model.

The embodiment of the present application provides a service processing apparatus, including: a first identification module, configured to perform fast risk identification on the service processing request after receiving a service processing request of a user, based on a recognition algorithm of a fast risk identification layer a second identification module, configured to perform depth risk identification on the service processing request based on a recognition algorithm of the depth risk identification layer if the risk detection request cannot be determined after the rapid risk identification is performed; The amount of data used for deep risk identification is greater than the amount of data used for rapid risk identification, and the recognition time used for deep risk identification is greater than the recognition duration used for rapid risk identification; The business processing request is processed according to the result of performing the depth risk identification.

The above risk identification method and device provide a scheme for hierarchical risk identification of a user's business processing request. In the rapid risk identification layer, less data is used and a shorter recognition time is used for identification, and the risk request cannot be confirmed. It is also a business request for a secure request, and then uses more data and a longer time for deep risk identification. Since the more obvious risk request or security request can be quickly identified by using less data in the rapid risk identification layer, the recognition efficiency and the system resources can be improved compared with the direct implementation of the more complex risk identification algorithm. Consumption; In addition, for business processing requests that are not easily identifiable, more complex depth risk identification is performed, so that the accuracy of risk identification can be ensured.

In addition, in the preferred embodiment of the present application, a comprehensive risk identification method based on the comprehensive risk identification layer recognition algorithm is further provided, and the comprehensive risk identification, the rapid risk identification and the deep risk identification are performed asynchronously, and the entire risk can be optimized. While identifying the algorithm, the business process is guaranteed to proceed smoothly.

31‧‧‧First identification module

32‧‧‧Second identification module

33‧‧‧Processing module

34‧‧‧The third identification module

1 is a flowchart of a service processing method according to Embodiment 1 of the present application; FIG. 2 is a flowchart of a risk identification method according to Embodiment 2 of the present application; FIG. 3 is a schematic structural diagram of a risk identification apparatus according to an embodiment of the present application.

The embodiment of the present application performs hierarchical risk identification on a service processing request of a user, and uses a small data and a short recognition time for identification in a fast risk identification layer, and a service processing request for failing to confirm whether it is a risk request or a security request. , then use more data and longer time for deep risk identification. Because of the obvious risk request or security request, it can be quickly identified by using less data in the fast risk identification layer. Compared with the direct implementation of the more complex risk identification algorithm, the recognition efficiency can be improved and the system resource consumption can be saved. For more difficult to identify business processing requests, more complex depth risk identification can improve the accuracy of risk identification. In addition, in the preferred embodiment of the present application, a comprehensive risk identification method based on the comprehensive risk identification layer recognition algorithm is further provided, and the comprehensive risk identification, the rapid risk identification and the deep risk identification are performed asynchronously, and the entire risk can be optimized. While identifying the algorithm, the business process is guaranteed to proceed smoothly.

The embodiments of the present application are further described in detail below with reference to the accompanying drawings.

 Embodiment 1  

As shown in FIG. 1 , a flowchart of a service processing method according to Embodiment 1 of the present application includes the following steps: S101: After receiving a service processing request of a user, performing a service based on a fast risk identification layer identification algorithm. Process requests for rapid risk identification.

In a specific implementation process, the service processing request may be quickly identified based on a pre-stored list of trusted users and a list of risk users. The trusted user list herein may include user data such as a trusted Internet Protocol (IP) address, a trusted media access control (MAC) address, and a trusted terminal location. Correspondingly, the risk user list may include user data such as a risk application account number, a risk bank card number, and a risk IP address. If the user data in the service processing request belongs to neither the user data in the trusted user list nor the user data in the risk user list, the user data carried in the service processing request may continue to be used. The historical behavior data of the user performs fast risk identification on the service processing request by performing user behavior data comparison, and if the user behavior data comparison can confirm whether the business processing request is a security request or a risk request, The service processing request is processed based on the result of the rapid risk identification, otherwise the process proceeds to S102.

For example, first check whether the IP address currently used by the user initiating the service processing request is a trusted IP address that is frequently used by the user (where the account can be used to identify the user), and if so, the current service processing request is considered. no risk. If not, it is checked whether the IP address is a risk IP address, and if so, the current business processing request is at risk. If not, the current operation may be determined to be risky based on a preset rule model for performing user behavior data comparison, for example, by comparing the difference between the current operation behavior of the user and the historical habitual operation behavior, for example, in the rule. In the model, it can be determined whether the user's current operation time is within the user's historical custom operation time period, the user's current transaction item type matches the user's historical transaction interest, and the user inputs the password's keyboard speed and user history. Habitual matching situation, etc. Here, the user's historical habitual operation behavior may refer to an operation behavior in which the number of occurrences in the user's security history operation record is above a set threshold. If the judgment result of the rule model is that the difference between the user's current operation behavior and the historical habitual operation behavior is too large, the current business processing request is considered to be risky, and if the difference is small, the current business processing request is considered to be safe. If the difference is between the difference between the existing risk and the non-existent risk, it is impossible to confirm whether the current business processing request is a security request or a risk request. At this time, the deep risk identification is entered.

According to statistics, at least 80% of all user behaviors can obtain risk identification results through the rapid risk identification layer. Since the amount of data and the amount of calculation required by the rapid risk identification layer are small, the system computing resources and storage resources are also consumed, so that the risk analysis performance can be greatly improved and the unnecessary resource consumption can be reduced.

S102: If, after the fast risk identification is performed, the service processing request cannot be determined to be a security request or a risk request, the depth risk identification layer-based recognition algorithm performs depth risk identification on the service processing request; wherein, the depth is performed. The amount of data used for risk identification is greater than the amount of data used for rapid risk identification, and the length of identification used for deep risk identification is greater than the length of identification used for rapid risk identification.

Compared with rapid risk identification, a more refined risk analysis in deep risk identification, in order to match a more refined rule model, deep risk identification uses more data, for example, the information used includes business processing type information ( Such as transfer, payment, red envelopes and other business processing types), business scenario information (such as instant arrival, secured transactions and other transaction type information, such as balance payment, fast payment, online banking payment and other payment pipeline information, such as physical transactions, virtual Logistics type information such as transactions, self-operated, external merchants and other transaction source information).

Specifically, the following steps may be performed: Step 1: Select at least one risk theme from preset multiple risk topics according to the service processing type of the service processing request.

Here, risk topics include, for example, stolen account risk (theft of application registration accounts), stolen card risk (theft of bank cards), fraud risk (such as modifying other bank card passwords). For example, when the type of business processing is payment, the risks involved may include the risk of stolen accounts, the risk of stolen cards, and the risk of fraud. Therefore, when dealing with payment services, three risk themes of stolen account risk, stolen card risk, and fraud risk can be automatically selected. . For another example, when the business processing type is transfer, two risk themes of stolen account risk and stolen card risk can be automatically selected.

Step 2: Select a rule model for performing deep risk identification based on the service scenario information corresponding to the service processing request under each selected risk topic.

Here, the rule models for deep risk identification corresponding to different business scenarios are different; under different risk topics, even the rule models for deep risk identification corresponding to the same business scenario may be different. of. For example, the risk of instant arrival and secured transactions (such as cash on delivery) is different, so the corresponding rule model for deep risk identification is different, and the balance payment and quick payment are used for depth. The rule model for risk identification is also different; in the case of stolen account risk and stolen card risk, it is also a secured transaction, and the corresponding rule model for deep risk identification is also different.

Step 3: Perform deep risk identification on the service processing request based on the selected rule model.

Here, the data of the matching rule model when performing the deep risk identification may include information such as whether the user operates in a different place, the business status information of the merchant, and the like.

In this step, a rule model for performing deep risk identification is selected for each risk topic selected. If there are multiple risk topics selected, the deep risk identification is performed for each risk topic separately. If the risk identification result under any one of the risk topics is that the current business processing request is a risk request, the current business processing request is considered as Risk request.

S103: Process the service processing request according to the result of performing the depth risk identification.

Deep risk identification can use the system resources saved by rapid risk identification to perform more detailed data calculation and obtain more accurate risk identification results. Since the deep risk identification only needs to identify the risk of the business processing request that cannot identify the recognition result by the rapid risk identification, the risk leakage probability can be reduced under the premise of ensuring the saving of system resources.

 Embodiment 2  

In the second embodiment of the present application, in order to further improve the accuracy of risk identification, a comprehensive risk identification layer is designed, which is performed asynchronously with rapid risk identification and deep risk identification, that is, does not affect the business processing process. The results of comprehensive risk identification can be used to optimize user data and rule models for performing rapid risk identification and deep risk identification.

As shown in FIG. 2, a flowchart of a risk identification method provided in Embodiment 2 of the present application includes: S201: After receiving a service processing request of a user, the service server is based on a trusted user list/risk user list/user behavior data. The comparison performs fast risk identification on the service processing request. If the step can determine that the service processing request is a security request or a risk request, go to S202, otherwise go to S203.

In a specific implementation, first determining, according to the user data carried in the service processing request, whether the user data belongs to a pre-stored trusted user list or a user data in a risk user list; And determining, by the user data in the trusted user list, the service processing request is a security request, and if the user data is the user data in the risk user list, determining that the service processing request is a risk request. If the user data does not belong to the user data in the pre-stored trusted user list, and does not belong to the user data in the pre-stored risk user list, based on the user data carried in the service processing request And determining, by the user, historical behavior data, and a rule model for performing user behavior data comparison, determining whether the current operation behavior of the user indicated by the service processing request matches the historical habitual operation behavior of the user, If yes, the service processing request is determined to be a security request, and if not, the service processing request is determined to be a risk request. Here, the historical habitual operation behavior of the user may refer to an operation behavior in which the number of occurrences in the user's security history operation record is above a set threshold.

S202: Process the service processing request according to the result of performing fast risk identification.

In a specific implementation, if it is determined that the service processing request is a security request, responding to the service processing request, providing a service service for the user, and if the service processing request is determined to be a risk request, the service processing request may be rejected. .

S203: If, after the fast risk identification is performed, the service processing request cannot be determined to be a security request or a risk request, selecting at least one risk theme from the preset multiple risk topics according to the service processing type of the service processing request, And selecting, according to the business scenario information corresponding to the service processing request, a rule model for performing deep risk identification, and performing deep risk identification on the service processing request based on the selected rule model.

S204: Process the service processing request according to the result of performing the depth risk identification.

Here, the rapid risk identification and the deep risk identification are both online recognition processes. If the fast risk identification layer does not confirm that the service processing request is a security request or a risk request, the service processing request is confirmed at the deep risk identification layer. Whether it is a security request or a risk request, in order to process the business processing request based on the recognition result. However, due to the response time, the data used for rapid risk identification and deep risk identification are basically online, and there will still be risks. For example, if the list of trusted users is abnormal, it will cause errors in the recognition result of performing rapid risk identification for subsequent large number of business processing requests. In order to perform more comprehensive risk mining, the embodiment of the present application performs comprehensive risk identification asynchronously, and the comprehensive risk identification may be performed after the processing of the service processing request is completed, or may be performed in the process of processing the service processing request. , does not affect the execution process of the business processing request.

S205: Perform comprehensive risk identification on the service processing request based on a comprehensive risk identification layer identification algorithm, where the comprehensive risk identification is performed asynchronously with the rapid risk identification and depth risk identification, and is used for comprehensive risk identification. The amount of data is greater than the amount of data used for rapid risk identification and deep risk identification, and the length of identification used for comprehensive risk identification is greater than the length of recognition used for rapid risk identification and deep risk identification.

In the case of comprehensive risk identification, it is possible to calculate and mine richer data features by obtaining some data of users on other service websites from other service servers. Comprehensive risk identification Compared to rapid risk identification and deep risk identification, risk calculation and analysis is more comprehensive and complex, and takes longer.

For example, the process of comprehensive risk identification may be: obtaining user data of users on other service websites from other service servers, and calculating user relationship network data, user cumulative behavior data, etc.; Comprehensive risk identification for user data on other service websites, calculated user relationship network data, user cumulative behavior data, and user data used for rapid risk identification and deep risk identification; here, comprehensive risk The algorithm for recognition can be the same as the algorithm for deep risk identification, with the difference that the user data used is different. The user data obtained from other service servers may include transaction and payment information of the user on the external service website, information indicating whether the user has abnormal operation on the external service website, and the user relationship network information includes the indication user. Whether the data has direct or indirect relationship with other users, the user cumulative behavior data may include the number of logins of the same IP address by the user within the set time period, and the total amount of off-site payment within the set time length.

S206: Update one or more of the following information based on the result of performing comprehensive risk identification: a preset trusted user list; a preset risk user list; the user's historical behavior data; and a preset rule model.

Here, the results of comprehensive risk identification can be used to optimize user data and rule models for rapid risk identification and deep risk identification. For example, when processing a request for a certain service, the result of comprehensive risk identification is that the service processing request is a risk request, and the application account involved in the service processing request may be extracted and listed in the risk user list; for example, for the corresponding The IP address is included in a service processing request in the risk user list. If the result of the comprehensive risk identification is that the service processing request is a security request, the IP address is removed from the risk user list; for example, The statistical user cumulative behavior data is included in the user's historical behavior data; for example, if based on a plurality of business processing requests, the original recognition result of the rule model output for comparing the user behavior data is calculated, and / If the recognition result output by the rule model for deep risk identification is poorly matched with the result of comprehensive risk identification, the above rule model can be optimized based on the result of comprehensive risk identification to make it more comprehensive. The result of risk identification.

Based on the same inventive concept, the risk identification device corresponding to the risk identification method is also provided in the embodiment of the present application. Since the principle of solving the problem is similar to the risk identification method in the embodiment of the present application, the implementation of the device can refer to the method. Implementation, repetition will not be repeated.

As shown in FIG. 3 , a schematic diagram of a structure of a risk identification apparatus provided by an embodiment of the present application includes: a first identification module 31, configured to perform a recognition algorithm based on a fast risk identification layer after receiving a service processing request of a user, Performing fast risk identification on the service processing request; the second identification module 32 is configured to: if the service processing request cannot be determined to be risky after performing rapid risk identification, the recognition algorithm based on the depth risk identification layer, Performing deep risk identification on the service processing request; wherein the amount of data used for deep risk identification is greater than the amount of data used for rapid risk identification, and the identification time used for deep risk identification is greater than that for performing rapid risk identification The recognition duration used; the processing module 33 is configured to process the service processing request according to the result of performing the depth risk identification.

Optionally, the first identification module 31 is configured to: determine, according to user data carried in the service processing request, whether the user data belongs to a pre-stored trusted user list or a risk user list. User data; if the user data is user data in the trusted user list, determining that the service processing request is a security request, and if the user data is user data in the risk user list, determining The service processing request is a risk request.

Optionally, the first identification module 31 is specifically configured to: if the user data does not belong to the user data in the pre-stored trusted user list, and is not used in the pre-stored risk user list. And determining, according to the user data carried in the service processing request, the historical behavior data of the user, and a rule model for performing user behavior data comparison, determining the user indicated by the service processing request Whether the current operation behavior matches the historical habitual operation behavior of the user; if it matches, the service processing request is determined to be a security request, and if not, the service processing request is determined to be a risk request.

Optionally, the second identification module 32 is configured to: select at least one risk theme from a preset plurality of risk topics according to the service processing type of the service processing request; and under each selected risk topic, And selecting, according to the service scenario information corresponding to the service processing request, a rule model for performing deep risk identification; and performing deep risk identification on the service processing request based on the selected rule model.

Optionally, the device further includes: a third identification module 34, configured to perform comprehensive risk identification on the service processing request based on a recognition algorithm of the comprehensive risk identification layer; wherein the comprehensive risk identification and the Rapid risk identification and deep risk identification are performed asynchronously. The amount of data used for comprehensive risk identification is greater than the amount of data used for rapid risk identification and deep risk identification, and the identification time used for comprehensive risk identification is greater than the rapid risk. Identification time used for identification and depth risk identification; based on the results of comprehensive risk identification, update one or more of the following information: a preset list of trusted users; a list of preset risk users; the history of the users Behavioral data; a preset rule model.

Those skilled in the art will appreciate that embodiments of the present application can be provided as a method, system, or computer program product. Thus, the present application can take the form of a fully hardware embodiment, a fully software embodiment, or an embodiment combining the software and hardware. Moreover, the present application can take the form of a computer program product implemented on one or more computer usable storage media (including but not limited to disk memory, CD-ROM, optical memory, etc.) containing computer usable code therein. .

The present application is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (system), and computer program products according to embodiments of the present application. It will be understood that each flow and/or block of the flowchart illustrations and/or FIG. These computer program instructions can be provided to a processor of a general purpose computer, a special purpose computer, an embedded processor or other programmable data processing device to produce a machine that executes instructions executed by a processor of a computer or other programmable data processing device Means are provided for implementing the functions specified in one or more of the flow or in one or more blocks of the flow chart.

The computer program instructions can also be stored in a computer readable memory that can boot a computer or other programmable data processing device to operate in a particular manner, such that instructions stored in the computer readable memory produce an article of manufacture including the instruction device. The instruction means implements the functions specified in one or more blocks of the flow or in a flow or block diagram of the flowchart.

These computer program instructions can also be loaded onto a computer or other programmable data processing device to perform a series of operational steps on a computer or other programmable device to produce computer-implemented processing on a computer or other programmable device. The instructions executed above provide steps for implementing the functions specified in one or more blocks of the flowchart or in a block or blocks of the flowchart.

While the preferred embodiment of the present application has been described, it will be apparent that those skilled in the art can make further changes and modifications to the embodiments. Therefore, the scope of the appended claims is intended to be construed as a

It will be apparent to those skilled in the art that various modifications and changes can be made in the present application without departing from the spirit and scope of the application. Thus, it is intended that the present invention cover the modifications and variations of the present invention.

Claims (10)

 A service processing method, comprising: after receiving a service processing request of a user, performing a rapid risk identification on the service processing request based on a recognition algorithm of a fast risk identification layer; if performing fast risk identification If it is not determined whether the service processing request is a security request or a risk request, the deep risk identification is performed on the service processing request based on the identification algorithm of the deep risk identification layer; wherein the amount of data used for deep risk identification is greater than the rapid risk The amount of data used is identified, and the recognition duration used for depth risk identification is greater than the recognition duration used for rapid risk identification; the business processing request is processed according to the result of performing the depth risk identification.    The method of claim 1, wherein the rapid risk identification layer based algorithm performs fast risk identification on the service processing request, including: determining the user data based on the service processing request Whether the user data belongs to the pre-stored trusted user list or the user data in the risk user list; if the user data is the user data in the trusted user list, it is determined that the service processing request is a security request, if The user data is the user data in the risk user list, and the service processing request is determined to be a risk request.    The method of claim 2, wherein if the user data does not belong to the user data in the pre-stored trusted user list, and does not belong to the user data in the pre-stored risk user list, And the fast risk identification is performed on the service processing request, and the method further includes: based on the user data carried in the service processing request, the historical behavior data of the user, and used to perform the user The behavioral data comparison rule model determines whether the current operation behavior of the user indicated by the service processing request matches the historical habitual operation behavior of the user; if it matches, the service processing request is determined to be a security request, if not, then Determine that the business processing request is a risk request.    The method of claim 1, wherein the deep risk identification is performed on the service processing request based on the identification algorithm of the deep risk identification layer, including: according to the service processing type of the service processing request, from the preset Selecting at least one risk theme among the plurality of risk topics; selecting, according to the business scenario information corresponding to the business processing request, a rule model for performing deep risk identification; and selecting the rule based on the selected rule model Process requests for deep risk identification.    The method of any one of claims 1 to 4, wherein the method further comprises: performing comprehensive risk identification on the service processing request based on a comprehensive algorithm of the risk identification layer; wherein the comprehensive risk identification In parallel with the rapid risk identification and deep risk identification, the amount of data used for comprehensive risk identification is greater than the amount of data used for rapid risk identification and deep risk identification, and the identification time used for comprehensive risk identification is greater than that performed. Identification time used for rapid risk identification and deep risk identification; based on the results of comprehensive risk identification, update one or more of the following information: a preset list of trusted users; a list of preset risk users; Historical behavior data; a preset rule model.    A service processing device, comprising: a first identification module, configured to perform fast risk identification on the service processing request after receiving a service processing request of the user, based on a recognition algorithm of a fast risk identification layer a second identification module, configured to perform a deep risk identification on the service processing request based on a recognition algorithm of the depth risk identification layer if the risk detection request cannot be determined after the rapid risk identification is performed; The amount of data used for deep risk identification is greater than the amount of data used for rapid risk identification, and the recognition time used for deep risk identification is greater than the recognition duration used for rapid risk identification; the processing module is used to The result of the deep risk identification is processed to process the business processing request.    The device of claim 6, wherein the first identification module is configured to: determine, according to the user data carried in the service processing request, whether the user data belongs to a pre-stored trusted user list. Or the user data in the risk user list; if the user data is the user data in the trusted user list, determining that the business processing request is a security request, and if the user data is the user data in the risk user list And determine that the business processing request is a risk request.    The device of claim 7, wherein the first identification module is specifically configured to: if the user data does not belong to the user data in the pre-stored trusted user list, and does not belong to the prior The user data in the stored risk user list is determined based on the user data carried in the business processing request, the historical behavior data of the user, and a rule model for comparing user behavior data. Whether the current operation behavior of the user indicated by the request matches the historical habitual operation behavior of the user; if it matches, the service processing request is determined to be a security request, and if not, the service processing request is determined to be a risk request.    The device of claim 6, wherein the second identification module is configured to: select at least one risk theme from a preset plurality of risk topics according to a service processing type of the service processing request; Under each risk topic, based on the business scenario information corresponding to the service processing request, a rule model for performing deep risk identification is selected; and based on the selected rule model, the business process request is subjected to deep risk identification.    The device of claim 6, wherein the device further comprises: a third identification module, configured to perform comprehensive risk identification on the service processing request based on a comprehensive algorithm of the risk identification layer; wherein Comprehensive risk identification and non-synchronous execution of the rapid risk identification and deep risk identification. The amount of data used for comprehensive risk identification is greater than the amount of data used for rapid risk identification and deep risk identification, and the identification used for comprehensive risk identification. The length of time is greater than the recognition duration used for rapid risk identification and deep risk identification; the update module is used to update one or more of the following information based on the results of comprehensive risk identification: a preset list of trusted users; List of risk users; historical behavior data of the user; preset rule model.