CN110728436B

CN110728436B - Risk identification method and device, electronic equipment and system

Info

Publication number: CN110728436B
Application number: CN201910906378.0A
Authority: CN
Inventors: 窦方钰; 陈荣伟; 岳汉; 沈涛; 叶建娣
Original assignee: Alipay Hangzhou Information Technology Co Ltd
Current assignee: Alipay Hangzhou Information Technology Co Ltd
Priority date: 2019-09-24
Filing date: 2019-09-24
Publication date: 2022-06-10
Anticipated expiration: 2039-09-24
Also published as: CN110728436A

Abstract

The embodiment of the specification relates to a risk identification method, a risk identification device, a risk identification system and electronic equipment. One of the methods comprises: responding to a risk identification request of a business system for user operation, and starting synchronous identification for identifying whether the user operation has risks; and under the condition that the synchronous identification fails, returning a set identification result corresponding to the user operation to the service system, and starting asynchronous identification for identifying whether the user operation has risks. The risk identification method can reduce the influence on normal business caused by the jitter of the risk control platform.

Description

Risk identification method and device, electronic equipment and system

Technical Field

Embodiments of the present disclosure relate to the field of information processing, and more particularly, to a risk identification method, a risk identification device, an electronic device, a risk identification system, and a computer-readable storage medium.

Background

At present, the operations of the terminal devices in the business scenes of login operation, transfer operation, payment operation and the like have become the main operation channels of people, and in the actual scenes, in order to guarantee the safety of user account information and transaction information involved in the processes of login operation, transfer operation, payment operation and the like, each transaction platform develops a wind control platform for identifying risks so as to reduce business risks.

The bottom layer of the wind control platform depends on a large amount of data to calculate rules and models, and the bottom layer service has burr shaking phenomenon due to unstable network or damage of a hard disk and the like. And the bottom data that the wind accuse platform used when a risk analysis probably reaches up to several hundreds or even thousands of to, the burr of because the bottom service shakes and leads to the overtime problem of wind accuse analysis can be outstanding in the wind accuse field very much. However, most of the current business scenarios have no risk by default for the time-out of the wind control, and the user is allowed to continue executing, which results in a certain risk being passed. Therefore, the conventional wind control platform has low risk identification accuracy, and a new method needs to be provided to improve the risk identification accuracy and further reduce the business risk.

Disclosure of Invention

The embodiment of the specification provides a new technical scheme for risk identification.

According to a first aspect of the present description, there is provided an embodiment of a risk identification method, comprising:

responding to a risk identification request of a business system for user operation, and starting synchronous identification for identifying whether the user operation has risks;

and under the condition that the synchronous identification fails, returning a set identification result corresponding to the user operation to the service system, and starting asynchronous identification for identifying whether the user operation has risks.

Optionally, the method further comprises:

under the condition that the asynchronous recognition is successful, judging whether the set recognition result is consistent with the recognition result of the asynchronous recognition;

in the case of an inconsistency, an additional process is performed for the user operation that matches the recognition result of the asynchronous recognition.

Optionally, the performing, for the user operation, an appending process of the recognition result matched to the asynchronous recognition includes:

acquiring a service scene to which the user operation belongs;

and performing additional processing on the user operation according to an additional processing mode matched with the service scene.

Optionally, the failure of the synchronous identification includes that the synchronous identification does not obtain an identification result within a set time.

Optionally, the returning, to the service system, a set identification result corresponding to the user operation includes:

and returning the set identification result without risk of the user operation to the service system.

Optionally, the method further comprises:

under the condition that the synchronous identification fails, judging whether the reason causing the synchronous identification failure allows the asynchronous identification to be started or not;

and in the case of allowing the asynchronous recognition to be started, executing the operation of starting the asynchronous recognition to recognize whether the user operation has a risk.

Optionally, the method further comprises:

under the condition that the synchronous identification fails, judging whether the service scene to which the user operation belongs allows the asynchronous identification to be started or not;

and in the case of allowing the asynchronous recognition to be started, re-executing the operation of starting the asynchronous recognition for re-recognizing whether the user operation has risks.

Optionally, the method further comprises:

responding to a request for carrying out asynchronous identification configuration, and providing a configuration inlet for inputting configuration information, wherein the configuration information comprises a service scene allowing asynchronous identification to be started and an additional processing mode matched with the service scene;

and acquiring and storing the configuration information input through the configuration entrance.

Optionally, the re-identifying asynchronous identification of whether the user operation is at risk includes:

acquiring a first setting characteristic extracted when the user operation is synchronously identified;

extracting a second setting feature in the asynchronous recognition for the user operation;

identifying whether the user operation has risks or not according to the first setting characteristic and the second setting characteristic;

wherein the first setting characteristic is a characteristic that does not occur with time and the second setting characteristic is a characteristic that varies with time.

Optionally, the step of asynchronously identifying whether the user operation is at risk comprises:

under the condition that the current asynchronous recognition fails, calculating the accumulated times of the asynchronous recognition failure;

performing the next asynchronous recognition under the condition that the accumulated times are less than or equal to the set times;

and ending the asynchronous recognition under the condition that the accumulated times are greater than the set times.

Optionally, the further performing asynchronous identification of whether the user operation is at risk further includes:

and printing the log for implementing the asynchronous recognition when the accumulated number of times is greater than the set number of times.

According to a second aspect of the present description, there is also provided another embodiment of a risk identification method, comprising:

responding to a set user operation triggered by a user in the service system, and sending a risk identification request for identifying whether the user operation has risks to a server;

performing current processing on the user operation according to a synchronous identification result returned by the server responding to the risk identification request to perform synchronous identification on the user operation; the synchronous identification result is a set identification result corresponding to the synchronous identification failure, and the synchronous identification result is returned within a set time after the server receives the risk identification request;

Responding to the additional processing initiated by the server for the user operation after the synchronous identification result is returned, and executing corresponding additional processing operation; and determining an additional processing mode of the additional processing by the server according to an asynchronous identification result of asynchronous identification for identifying whether the user operation has risks or not, wherein the asynchronous identification is started after the synchronous identification fails.

Optionally, after executing the corresponding additional processing operation, the method further includes:

an alert is made that the additional processing operation has been performed.

According to a third aspect of the present specification, there is also provided a risk identification device comprising:

the synchronous identification module is used for responding to a risk identification request of a business system for user operation and starting synchronous identification for identifying whether the user operation has risks; and the number of the first and second groups,

and the asynchronous identification module is used for returning a set identification result corresponding to the user operation to the service system under the condition that the synchronous identification fails, and starting to perform asynchronous identification for identifying whether the user operation has risks.

According to a fourth aspect of the present specification, there is also provided an embodiment of an electronic device, including the risk identification apparatus according to the third aspect of the present specification, or the electronic device including:

A memory for storing executable commands;

a processor for executing the risk identification method according to the first aspect or the second aspect of the present description under the control of the executable command.

According to a fifth aspect of the present description, there is also provided an embodiment of a risk identification system, comprising:

a server comprising a memory and a processor, the memory of the server for storing executable commands; the processor of the server is configured to perform the risk identification method according to the first aspect of the present specification under the control of the executable command; and the number of the first and second groups,

the terminal equipment comprises a memory and a processor, wherein the memory of the terminal equipment is used for storing executable commands; the processor of the terminal device is configured to execute the risk identification method according to the second aspect of the present specification under the control of the executable command.

According to a sixth aspect of the present description, there is also provided an embodiment of a computer readable storage medium storing executable instructions that, when executed by a processor, perform the method according to the first or second aspect of the present description.

In one embodiment, the risk identification method can reduce the influence of the shaking of the wind control platform on normal services. In another embodiment, the risk identification method can improve the accuracy of risk identification and further reduce business risks.

Other features of the present description and advantages thereof will become apparent from the following detailed description of exemplary embodiments thereof, which proceeds with reference to the accompanying drawings.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments of the specification and together with the description, serve to explain the principles of the specification.

FIG. 1a is a schematic diagram of a scenario in which a risk identification method of an embodiment may be implemented;

FIG. 1b is a block diagram of a hardware configuration of a risk identification system that may be used to implement the risk identification method of one embodiment;

FIG. 2 is a flow chart of a risk identification method according to a first embodiment;

FIG. 3 is a flow chart of a risk identification method according to a second embodiment;

FIG. 4a is a flow chart of a risk identification method according to a third embodiment;

FIG. 4b is a flow chart of a risk identification method according to a fourth embodiment;

FIG. 5 is a flow chart of a risk identification method according to a fifth embodiment;

FIG. 6 is a flow chart of a risk identification method according to a sixth embodiment;

FIG. 7 is a functional block diagram of a risk identification device according to one embodiment;

FIG. 8 is a functional block diagram of an electronic device according to one embodiment;

FIG. 9 is a hardware architecture diagram of a risk identification system according to one embodiment.

Detailed Description

Various exemplary embodiments of the present specification will now be described in detail with reference to the accompanying drawings.

The following description of at least one exemplary embodiment is merely illustrative in nature and is in no way intended to limit the disclosure, its application, or uses.

It should be noted that: like reference numbers and letters refer to like items in the following figures, and thus, once an item is defined in one figure, further discussion thereof is not required in subsequent figures.

< hardware configuration >

Fig. 1a is a schematic view of an actual scene of a risk identification method according to an embodiment of the present disclosure.

Referring to fig. 1a, a login interface of a service system in a terminal device 1200 is a page a, when the user enters the phone number and password on page a and performs a click operation for the "login" button, the terminal device 1200 may transmit a risk identification request identifying whether the click operation is risky to the server 1100 in response to the click operation performed by the user in the business system, the server 1100 receives the risk identification request, and starts synchronous identification identifying whether the click operation is risky, further, when the synchronous identification fails, for example, when the identification result is not obtained within a set time, the identification result without risk of the click operation is returned to the service system of the terminal device 1200, so that the user can log in normally, for example, page C shown in fig. 1a may be displayed, so as to reduce the influence on the login operation caused by the shaking of the wind-controlled platform.

Meanwhile, the server 1100 starts asynchronous recognition for recognizing whether the click operation is risky again, and performs additional processing matching the recognition result of the asynchronous recognition for the click operation when the asynchronous recognition is successful, for example, the click operation is risky, for example, the server may forcibly log out to the initial login interface, that is, the page a, and display "the operation is risky, and forcibly log out for ensuring that the security application will be logged out", that is, display the page D as shown in fig. 1a, thereby improving the accuracy of risk recognition and further reducing the login risk.

Fig. 1b is a schematic structural diagram of a risk identification system to which the risk identification method according to an embodiment of the present disclosure may be applied.

As shown in fig. 1b, the risk identification system 1000 of the present embodiment includes a server 1100, a terminal device 1200, and a network 1300.

The server 1100 may be, for example, a blade server, a rack server, or the like, and the server 1100 may also be a server cluster deployed in a cloud, which is not limited herein.

As shown in FIG. 1, server 1100 may include a processor 1110, a memory 1120, an interface device 1130, a communication device 1140, a display device 1150, and an input device 1160. The processor 1110 may be, for example, a central processing unit CPU or the like. The memory 1120 includes, for example, a ROM (read only memory), a RAM (random access memory), a nonvolatile memory such as a hard disk, and the like. The interface device 1130 includes, for example, a USB interface, a serial interface, and the like. The communication device 1140 is capable of wired or wireless communication, for example. The display device 1150 is, for example, a liquid crystal display panel. Input devices 1160 may include, for example, a touch screen, a keyboard, and the like.

In this embodiment, memory 1120 of server 1100 is configured to store instructions for controlling processor 1110 to operate to perform a method of risk identification. The skilled person can design the instructions according to the solution disclosed in the present specification. How the instructions control the operation of the processor is well known in the art and will not be described in detail herein.

Those skilled in the art will appreciate that although a number of devices are shown in FIG. 1b for the server 1100, the server 1100 of embodiments of the present specification may refer to only some of the devices, for example, the processor 1110 and the memory 1120.

As shown in fig. 1b, the terminal apparatus 1200 may include a processor 1210, a memory 1220, an interface device 1230, a communication device 1240, a display device 1250, an input device 1260, an audio output device 1270, an audio input device 1280, and the like. The processor 1210 may be a central processing unit CPU, a microprocessor MCU, or the like. The memory 1220 includes, for example, a ROM (read only memory), a RAM (random access memory), a nonvolatile memory such as a hard disk, and the like. The interface device 1230 includes, for example, a USB interface, a headphone interface, and the like. The communication device 1240 can perform wired or wireless communication, for example. The display device 1250 is, for example, a liquid crystal display, a touch display, or the like. The input device 1260 may include, for example, a touch screen, a keyboard, and the like. The terminal apparatus 1200 may output the audio information through the audio output device 1270, the audio output device 1270 including a speaker, for example. The terminal apparatus 1200 may pick up voice information input by the user through the audio pickup device 1280, and the audio pickup device 1280 includes, for example, a microphone.

The terminal device 1200 may be any device that can support operation of a service system, such as a smart phone, a portable computer, a desktop computer, and a tablet computer.

In this embodiment, the terminal device 1200 may respond to a set user operation triggered by a user in the service system, and send a risk identification request for identifying whether the user operation has a risk to the server 1100, so that the server 1100 starts synchronous identification for identifying whether the user operation has a risk, and returns a set identification result corresponding to the user operation to the service system and starts asynchronous identification for identifying whether the user operation has a risk in case of a failure of the synchronous identification.

In this embodiment, the memory 1220 of the terminal device 1200 is configured to store instructions for controlling the processor 1210 to operate so as to support implementation of the risk identification method according to any embodiment of the present disclosure. The skilled person can design the instructions according to the solution disclosed in the present specification. How the instructions control the operation of the processor is well known in the art and will not be described in detail here.

It should be understood by those skilled in the art that although a plurality of devices of the terminal device 1200 are shown in fig. 1b, the terminal device 1200 of the present embodiment may refer to only some of the devices, for example, only the processor 1210, the memory 1220, the display device 1250, the input device 1260 and the like.

The communication network 1300 may be a wireless network, a wired network, a local area network, or a wide area network. The terminal apparatus 1200 can communicate with the server 1100 through the communication network 1300.

The risk identification system 1000 shown in FIG. 1b is merely illustrative and is in no way intended to limit the present description, its applications, or uses. For example, although fig. 1b shows only one server 1100 and one terminal device 1200, it is not meant to limit the respective numbers, and multiple servers 1100 and/or multiple terminal devices 1200 may be included in the risk identification system 1000.

< method example 1>

The present embodiment provides a risk identification method, which may be implemented by a server, for example, the server may be the server 1100 shown in fig. 1a or fig. 1 b. As shown in fig. 2, the method includes the following steps S2100 to S2200:

step S2100, in response to a risk identification request of the business system for the user operation, starts synchronous identification for identifying whether the user operation has a risk.

The business system may be a system for realizing the user requirement, and the business system may be, for example, a food ordering system, a financial system, a money transfer system, a personnel system, and the like, which are not limited herein. The system service may be installed in the terminal device 1200, and for example, an icon of the service system may be displayed on a display interface of the terminal device 1200, so that the user can enter the corresponding service system by clicking the icon, thereby implementing the corresponding user requirement.

In this embodiment, a user operation capable of triggering the wind control analysis may be preset in the server 1100, so that when the user operation is received, synchronous identification for identifying whether the user operation has a risk is started. The user operation may be, for example, a login operation, a payment operation, a deletion operation, and the like, which is not limited herein.

The risk identification request carries at least data for enabling risk identification by the server 1100, which may be at least one of operation data and business data, for example. In this embodiment, the risk identification performed in response to the risk identification request of the business system for the user operation may be referred to as synchronous identification, and after receiving the risk identification request of the business system for the user operation, the server 1100 may start synchronous identification for identifying whether the user operation has a risk with respect to the risk identification request, for example, feature extraction may be performed on data carried in the risk identification request by using a rule and/or a machine learning model, so as to process the extracted features, and further obtain an identification result of the synchronous identification.

The machine learning model may be a neural network model, such as but not limited to a bp (back propagation) neural network model, a convolutional neural network model, and the like, and of course, the machine learning model may also be a logistic regression model, and the machine learning model is not specifically limited herein.

In this embodiment, for example, a user may perform a click operation on an icon of a certain ordering system on a display interface in the terminal device 1200, and then enter a login interface of the ordering system, where the login interface may be, for example, a page a shown in fig. 1a, and when the user inputs a mobile phone number and a password and clicks "login", the terminal device 1200 sends a risk identification request for identifying whether the user operation is risky to the server 1100 in response to the user operation, so that the server 1100 starts synchronous identification for identifying whether the user operation is risky, and further obtains an identification result of the synchronous identification.

Step S2200, under the condition that the synchronous identification fails, returning a set identification result corresponding to the user operation to the service system, and starting asynchronous identification for identifying whether the user operation has risks.

The failure of synchronous identification comprises that the synchronous identification does not obtain an identification result within a set time.

In one example, the set time may be a fixed value, and the fixed value is set for all service scenarios. The set number may be selected in consideration of the accuracy of judging the synchronous recognition and the user experience.

In one example, the server 1100 may set the setting time corresponding to each service scenario, and the setting time corresponding to each service scenario may be the same or different.

In this example, the server 1100 may set the corresponding set time according to the preset response time in the service scenario, where the set time may be the same value as the preset response time in the service scenario, or may be a value that is larger than the response time by a certain range, which is not limited herein. The preset response time may be set according to a specific application scenario and a specific requirement, for example, the response time corresponding to a service scenario may be set according to user experience and a service success rate.

For example, the response time preset in the payment scenario is 300ms, and here, the set time corresponding to the payment scenario may also be set to 300ms, or of course, the set time of the payment scenario may also be set to 320 ms.

For another example, the preset response time in the lottery scene is 500ms, and here, the setting time for the corresponding lottery scene may be 500ms, or of course, the setting time for the lottery scene may be 520 ms.

In this embodiment, the step S2200 of returning the setting identification result corresponding to the user operation to the service system may further include:

and returning the set identification result without risk of user operation to the service system.

In this embodiment, for most user operations, for example, a login operation performed by a user on a login page of a certain ordering system, or a rating operation performed by the user on a rating interface of the ordering system, the operation often does not involve fund interaction, and for such user operations, when a synchronous identification failure, for example, an identification result is not known within a set time, it is generally considered that no risk exists, and here, a set identification result with no risk of the user operation may be returned to a corresponding business system.

It is understood that for a small number of user operations, such as a payment operation performed by a user for a payment interface of a certain ordering system, or a transfer operation performed by a user for a transfer interface of the ordering system, the operation is often related to fund interaction, and for such user operations, in a case that a synchronization recognition failure is, for example, an identification result is not known within a set time, it is generally considered to be risky, and here, a set identification result that the user operation is risky may be returned to a corresponding business system. At this time, it is necessary to perform a user operation on the business system again, for example, to perform a payment operation on a payment interface of the ordering system again by the user, or to perform a transfer operation on a transfer page of the ordering system by the user, so that the server 1100 responds to a risk identification request of the business system for the user operation again, and restarts the synchronous identification for identifying whether the user operation has a risk, thereby obtaining an identification result of the synchronous identification.

In an example of the present specification, the asynchronous recognition of recognizing whether the user operation is at risk in step S2200 may further include the following steps S2211a to SS2213 a:

in step S2211a, the first setting feature extracted when the user operation is recognized synchronously is acquired.

The first setting characteristic is a characteristic that does not occur with time. The first setting characteristic may be, for example, account information of the user, including account name, account password, and the like, and may also include attribute information of the registered user, including attribute information such as user age, user gender, and user academic calendar.

In step S2211a, after receiving the risk identification request of the business system for the user operation, the server 1100 may start synchronous identification for identifying whether the user operation has a risk, and extract a feature that does not change with time from the data carried in the risk identification request as the first setting feature.

Illustratively, for example, a user performs a payment operation on a payment interface of a certain ordering system, the server 1100 responds to a risk identification request of the ordering system for the payment operation, starts synchronous identification for identifying whether the payment operation is at risk, and extracts account information of the user and attribute information of the user from data carried by the risk identification request.

In step S2212a, the second setting feature at the time of the asynchronous recognition is extracted for the user operation.

The second setting characteristic is a characteristic that varies with time. The second setting characteristic may be account balance information of the user or order information of the user, for example.

In step S2212a, since asynchronous recognition lags synchronous recognition, some features included in the data carried in the risk recognition request may have changed over time, and if asynchronous recognition for recognizing whether the user operation is risky is performed again based on all the features extracted when the user operation is synchronously recognized, the accuracy of asynchronous recognition may be reduced. Here, in step S2212a, a feature that changes with time is newly extracted from the data carried in the risk identification request as the second setting feature for the user operation, and asynchronous identification for identifying whether or not the user operation is at risk is performed in combination with the first setting feature extracted in step S2211 a.

Continuing with the above example, server 1100 may extract account balance information for the user at the time of asynchronous identification of the payment operation.

And step S2213a, identifying whether the user operation is in risk or not according to the first setting characteristic and the second setting characteristic.

Asynchronous recognition, which recognizes whether there is a risk of a user operation, can be performed again according to the present step SS2213a by acquiring the first setting feature at the time of synchronous recognition of a user operation according to the above step S2211a and extracting the second setting feature at the time of asynchronous recognition for a user operation according to the above step S2212 a.

Continuing with the above example, the server 1100 may perform asynchronous identification that identifies whether the payment operation is risky based on the account information of the user, the attribute information of the user, and the like, and the account balance information of the user.

According to the above steps S2211a to S2213a, it is possible to extract the feature that does not change with time when performing synchronous recognition and the feature that changes with time when performing asynchronous recognition with respect to the user operation, and then perform asynchronous recognition for recognizing whether the user operation is risky, thereby improving the accuracy of the asynchronous recognition.

In another example of the present specification, the asynchronous recognition of re-recognizing whether the user operation is at risk in step S2200 may further include the following steps S2211b to SS2213 b:

In step S2211b, in the case where the current asynchronous recognition fails, the cumulative number of times of occurrence of asynchronous recognition failure is calculated.

The accumulated times of the asynchronous identification failure can be respectively accumulated according to the types of the reasons causing the asynchronous identification failure, or can be uniformly accumulated without distinguishing the types of the reasons causing the asynchronous identification failure.

For example, after asynchronous recognition that identifies whether a payment operation performed by a user for a payment interface of a certain ordering system is risky is started for the first time, whether the first asynchronous recognition is successful or not is judged, and in the case that the first asynchronous recognition fails, the accumulated number of times of occurrence of asynchronous recognition failure is determined to be 1.

In step S2212b, when the cumulative count is less than or equal to the set count, the next asynchronous recognition is performed.

The set number may be a parameter set according to network performance, for example, the set number may be 2, and of course, the set number may be other values, which is not limited herein.

Continuing with the example of step S2211b, the cumulative number of occurrences of the asynchronous recognition failure is determined to be 1 time according to step S2211b, and the cumulative number (1 time) and the set number (2 times) are compared according to step S2212b, and if the cumulative number is smaller than the set number, the next asynchronous recognition is performed.

In step S2213b, when the cumulative count is greater than the set count, the asynchronous recognition is ended.

According to the above steps S2211b to S2213b, when performing the asynchronous recognition, the accumulated number of times of asynchronous recognition failure is compared with the set number of times, so that the asynchronous recognition is not ended until the accumulated number of times is greater than the set number of times, and the asynchronous recognition is repeatedly performed until the accumulated number of times is greater than the set number of times when the accumulated number of times is less than the set number of times, thereby improving the accuracy of the asynchronous recognition.

In another example of the present specification, the step S2200 of performing asynchronous recognition for recognizing whether the user operation is at risk may further include a step S2211c of:

in step S2211c, when the cumulative count is greater than the set count, a log for performing asynchronous recognition is printed.

In step S2211c, for example, when the cumulative count (3 times) is greater than the set count (2 times), a log for performing asynchronous recognition may be printed, and the log may display information such as at least the cause of each asynchronous recognition and the time at which each asynchronous recognition fails.

According to the above step S2211c, in the case where the accumulated number of times is greater than the set number of times, the log for performing asynchronous recognition is printed, thereby facilitating the programmer to analyze the cause of the asynchronous recognition failure based on the printed log.

The method of the embodiment can return the set identification result in time under the condition that the risk identification performed on the risk identification request operated by the user by the service system fails, so as to reduce the influence of the shaking of the wind control platform on the normal service, and can continuously start the asynchronous identification under the condition that the risk identification request operated by the user by the service system fails, so as to perform additional processing according to the asynchronous identification result, which obviously improves the accuracy of the risk identification and further reduces the service risk.

In one embodiment, referring to fig. 3, the method for identifying risks in this specification may further include the following steps S3100 to S3200:

step S3100, when the asynchronous recognition is successful, determines whether or not the set recognition result matches the recognition result of the asynchronous recognition.

The set recognition result includes a recognition result without risk.

In this embodiment, for example, when the user successfully performs asynchronous recognition on the payment operation performed on the payment interface of a certain ordering system, it may be further determined whether there is no risk in the recognition result of the asynchronous recognition on the payment operation.

In step S3200, if the user operation is not matched, additional processing is performed to match the recognition result of the asynchronous recognition.

Continuing with the example of step S3100, if it is found in step S3200 that the recognition result of the asynchronous recognition is a risk of the payment operation, that is, if the recognition result of the asynchronous recognition does not match the set recognition result, an additional process matching the recognition result of the asynchronous recognition is performed for the user operation, for example, the account may be frozen.

In this embodiment, the additional processing of performing the recognition result matching the asynchronous recognition for the user operation in step S3200 may further include steps S3210 to S3220 as follows:

step S3210, acquiring a service scenario to which the user operation belongs.

In step S3210, the server 1100 may preset an additional processing mode corresponding to the service scenario, and the additional processing modes corresponding to different service scenarios may be the same or different, which is not limited herein.

For example, the service scenario is a payment scenario, and the corresponding additional processing manner may be to freeze an account. For example, the service scenario is a login scenario, and the corresponding additional processing method may be restricted login or the like.

Step S3220 performs an addition process on the user operation according to an addition processing method matched to the service scenario.

For example, the user operation may be a payment operation performed by the user for a payment interface of a certain ordering system, where the service scenario to which the payment operation belongs is obtained in step S3210 is a payment scenario, and the additional processing mode matched with the payment scenario obtained in step S3210 is a frozen account, and then an operation of freezing the account is performed for the payment operation.

According to the above steps S3100 to S3200, when the asynchronous recognition result indicates that there is a risk of the user operation, the user operation can be subjected to the additional processing matching the asynchronous recognition result, thereby reducing the business risk.

In one embodiment, referring to fig. 4a, the risk identification method of this embodiment may further include the following steps S4100a to S4200 a:

step S4100a judges whether or not the cause of the failure of the synchronous recognition allows the start of the asynchronous recognition when the synchronous recognition fails.

In this embodiment, when the user fails to perform synchronous identification on the payment operation performed on the payment interface of a certain ordering system, for example, when an identification result is not obtained within a set time, it may be further determined whether to allow starting of asynchronous identification due to the synchronous identification failure, for example, when the cause of the synchronous identification failure is glitch, the asynchronous identification may be allowed to be started, or when the cause of the synchronous identification failure is current-limiting interception of the underlying service, the asynchronous identification may not be allowed to be started.

In step S4200a, if the start of the asynchronous recognition is permitted, the operation of starting the asynchronous recognition for recognizing whether or not the user operation is risky is executed again.

Continuing with the example of step S4100a, for example, if the cause of the synchronous identification failure is glitch, the asynchronous identification is allowed to be started, and if the asynchronous identification is allowed to be started, the operation of starting the asynchronous identification to identify whether the payment operation is at risk is executed again according to the present step S4200 a.

According to the embodiment, on the basis that synchronous identification fails and the reason causing the synchronous identification failure is determined to allow the asynchronous identification to be started, the asynchronous identification operation for starting and then identifying whether the user operation has risks is executed, so that the asynchronous identification operation aiming at the user operation is also executed under the condition that problems occur due to a bottom layer service system and the like is eliminated.

In one embodiment, referring to fig. 4b, the risk identification method of this embodiment may further include the following steps S4100b to S4200 b:

step S4100b, when the synchronous recognition fails, determines whether the service scenario to which the user operation belongs allows the asynchronous recognition to be started.

In step S4100a, the server 1100 may preset an identifier indicating whether the service scenario allows the asynchronous recognition to be started.

In one example, the flag may be a number, e.g., the service scenario allows for initiating asynchronous recognition, the flag may be set to "1", and e.g., the service scenario does not allow for initiating asynchronous recognition, the flag may be set to "0".

For example, the service scenario is a payment scenario, and the flag corresponding to whether to allow the asynchronous recognition to be started is "1", that is, the payment scenario allows the asynchronous recognition to be started.

In one example, the flag may also be a word, for example, if the service scenario allows starting asynchronous recognition, the flag may be set to "yes", and for example, if the service scenario does not allow starting asynchronous recognition, the flag may be set to "no". The start asynchronous identification is not limited as long as the start asynchronous identification is allowed and the start asynchronous identification is not allowed according to the convention.

For example, the service scenario is a payment scenario, and the flag corresponding to whether the asynchronous recognition is allowed to be started is yes, i.e., the payment scenario allows the asynchronous recognition to be started.

For example, when a user fails to perform synchronous identification on a payment operation performed on a payment interface of a certain ordering system, for example, when an identification result is not obtained within a set time, it may be determined whether to allow starting of asynchronous identification for a reason causing the synchronous identification failure, for example, when the reason causing the synchronous identification failure is glitch, it may be determined that starting of asynchronous identification is allowed, and when the asynchronous identification is allowed, a service scenario to which the payment operation belongs is further acquired, for example, the acquired service scenario to which the payment operation belongs is a payment scenario, where it is determined whether to allow starting of asynchronous identification for the payment scenario.

In step S4200b, if the start of the asynchronous recognition is permitted, the operation of starting the asynchronous recognition for recognizing whether the user operation is at risk is executed again.

Continuing with the example of step S4100b described above, in the event that it is determined from step S4100b above that the payment scenario allows for the initiation of asynchronous recognition, then an operation is initiated according to this step S4200b to re-perform asynchronous recognition that identifies whether the payment operation is at risk.

According to the embodiment, on the basis that synchronous identification fails and the fact that the business scene to which the user operation belongs allows asynchronous identification to be started is determined, the asynchronous identification operation for starting and then identifying whether the user operation has risks is executed, and customized design is achieved.

In one embodiment, referring to fig. 5, the risk identification method of this embodiment may further include the following steps S5100 to S5200:

in step S5100, in response to a request for performing asynchronous identification configuration, a configuration entry for inputting configuration information is provided.

The configuration information includes a service scenario allowing the start of asynchronous recognition and an additional processing mode matched with the service scenario.

The configuration entry may be an input box, a drop-down list, a voice input, etc., for example, a programmer may input the identification information of a service scenario through the input box and an additional processing mode matched with the service scenario; for another example, the programmer may select the identification information of the service scenario and the additional processing mode matched with the service scenario through a pull-down list; for another example, the programmer may input the identification information of the service scenario and the additional processing mode matching the service scenario by voice.

The identity identification information is used for uniquely identifying the service scene and has uniqueness, and the identity identification information can be a number of the service scene, a name of the service scene, or other identification codes having a mapping relation with the number or the name.

In step S5200, the configuration information input through the configuration entry is acquired and saved.

For example, the "payment scene" may be input through the input box and the "frozen account" corresponding to the payment scene and the "payment scene" corresponding to the payment scene may be acquired and stored by the server 1100.

For example, the "login scene" may be input through the input box and the "restricted login" may be an additional processing method corresponding to the login scene, and the server 1100 may acquire and store the "login scene" input through the input box and the "restricted login" may be an additional processing method corresponding to the login scene.

According to the embodiment, the example provides a man-machine interaction interface to support a programmer to perform asynchronous identification of an application scene according to current actual needs and an additional processing mode matched with a service scene, so as to realize customized design.

< method example 2>

Fig. 6 is a flowchart of a risk identification method according to another embodiment of the present disclosure, where this embodiment is implemented by a terminal device, for example, a terminal device 1200 that installs a business system.

As shown in fig. 6, the method of the present embodiment may include the following steps S6100 to S6300:

step S6100, in response to a set user operation triggered by the user in the service system, sends a risk identification request for identifying whether the user operation is risky to the server 1100.

In this embodiment, a user operation capable of triggering the wind control analysis may be preset in the terminal device 1200, so that when the user operation is received, a risk identification request for identifying whether the user operation has a risk is sent to the server 1100. The user operation may be, for example, a login operation, a payment operation, a deletion operation, and the like, which is not limited herein.

Step S6200, perform current processing on the user operation according to a synchronous recognition result returned by the server 1100 performing synchronous recognition on the user operation in response to the risk recognition request.

In this embodiment, the step of the server 1100 performing synchronous identification on the user operation in response to the risk identification request may refer to the above method embodiment, and is not described herein again.

The synchronous recognition result is a set recognition result corresponding to the synchronous recognition failure, and the synchronous recognition result is returned within a set time after the server 1100 receives the risk recognition request. For the description of the setting time, reference may be made to the above method embodiments, and details are not described herein.

In this embodiment, after receiving a risk identification request of the service system for the user operation, the server 1100 starts synchronous identification for identifying whether the user operation has a risk, and returns a synchronous identification result within a set time. For example, when receiving the risk identification request for the login operation from the ordering system, the server 1100 may start synchronous identification for identifying whether the login operation is risky, and return the set identification result without risk within a set time, and after receiving the set identification result without risk, the terminal device 1200 may continue the next operation, that is, display the page C with successful login as shown in fig. 1 a.

Step S6300, in response to the addition processing initiated by the server 1100 for the user operation after returning the synchronization recognition result, executes a corresponding addition processing operation.

The manner of the additional processing is determined by the server 1100 according to the asynchronous recognition result of the asynchronous recognition that recognizes whether the user operation is risky again, and the asynchronous recognition is started after the synchronous recognition fails.

In this embodiment, for the step of performing asynchronous identification on the user operation by the server 1100 in response to the risk identification request and the additional processing initiated by the user operation, reference may be made to the above method embodiment for performing the corresponding additional processing operation, which is not described herein again.

In this embodiment, the server 1100 starts asynchronous recognition for re-recognizing whether there is a risk in the user operation when the synchronous recognition fails, determines whether the set recognition result is consistent with the asynchronous recognition result when the asynchronous recognition succeeds, and performs additional processing of the recognition result matching the asynchronous recognition on the user operation when the set recognition result is inconsistent with the asynchronous recognition result. For example, in the case where the synchronous recognition of the login operation fails (the recognition result is not known within the set time), the server 1100 starts asynchronous recognition for recognizing whether the login operation is risky, and if the asynchronous recognition is risky, that is, the set recognition result (no risk) does not match the asynchronous recognition result, performs a corresponding additional processing operation, for example, a frozen account.

In an embodiment, after performing the corresponding additional processing operation, the risk identification method of this embodiment further includes:

an alert is made that additional processing operations have been performed.

For example, the corresponding processing result may be displayed on the display interface of the terminal device 1200, and for example, "frozen account" may be displayed.

< apparatus embodiment >

The present embodiment provides a risk identification apparatus, such as risk identification apparatus 7000 shown in fig. 7, where risk identification apparatus 7000 includes synchronous identification module 7100 and asynchronous identification module 7200.

The synchronous identification module 7100 is configured to, in response to a risk identification request of a business system for a user operation, start synchronous identification for identifying whether the user operation has a risk.

The asynchronous recognition module 7200 is configured to, when the synchronous recognition fails, return a set recognition result corresponding to the user operation to the service system, and start to perform asynchronous recognition for recognizing whether the user operation is risky.

In an embodiment, the asynchronous identification module 7200 is further configured to determine whether the set identification result is consistent with the identification result of the asynchronous identification if the asynchronous identification is successful;

In the case of an inconsistency, an additional process is performed for the user operation, which is matched to the recognition result of the asynchronous recognition.

In an embodiment, the asynchronous identification module 7200 is further configured to obtain a service scenario to which the user operation belongs;

In one embodiment, the failure of the synchronous recognition includes that the synchronous recognition does not obtain a recognition result within a set time.

In an embodiment, the asynchronous identification module 7200 is further configured to return a set identification result that the user operation does not risk to the service system.

In an embodiment, the asynchronous identification module 7200 is further configured to determine, when the synchronous identification fails, whether a cause causing the synchronous identification to fail allows the asynchronous identification to be started;

In an embodiment, the asynchronous identification module 7200 is further configured to, when the synchronous identification fails, determine whether the service scenario to which the user operation belongs allows the asynchronous identification to be started;

In one embodiment, the risk identification device 7000 further comprises an asynchronous identification configuration module (not shown in the figure).

The asynchronous identification configuration module is used for responding to a request for carrying out asynchronous identification configuration and providing a configuration inlet for inputting configuration information, wherein the configuration information comprises a service scene allowing asynchronous identification to be started and an additional processing mode matched with the service scene;

In one embodiment, the asynchronous recognition module 7200 is further configured to obtain a first setting characteristic extracted when the user operation is synchronously recognized;

wherein the first setting characteristic is a characteristic that does not occur with time, and the second setting characteristic is a characteristic that varies with time.

In one embodiment, the asynchronous recognition module 7200 is further configured to count the cumulative number of times of occurrence of the asynchronous recognition failure in the case that the current asynchronous recognition fails;

In one embodiment, the asynchronous identification module 7200 is further configured to print a log implementing the asynchronous identification if the accumulated number of times is greater than the set number of times.

< apparatus embodiment >

In this embodiment, an electronic device is further provided, where the electronic device includes the identification apparatus described in the apparatus embodiment of this specification; alternatively, the electronic device is the electronic device 8000 shown in fig. 8, and includes:

a memory 8100 for storing executable commands.

A processor 8200 for performing the methods described in any of the method embodiments herein, under control of executable instructions stored by memory 8100.

The implementation subject of the embodiment of the method executed in the electronic equipment can be a server or a terminal device.

In one embodiment, any of the modules in the above device embodiments may be implemented by the processor 8200.

< System embodiment >

In this embodiment, there is also provided a risk identification system 9000, as shown in fig. 9, including:

server 9100, which may be, for example, server 1100 as shown in fig. 1.

The server 9100 comprises a memory and a processor, the memory of the server 9100 is used for storing executable commands; the processor of server 9100 is configured to perform the risk identification method according to any of the embodiments of the present specification under the control of executable commands.

In this embodiment, the risk identification system 9000 further includes a terminal device 9200, and the terminal device 9200 may be the terminal device 1200 shown in fig. 1.

The terminal device 9200 includes a memory and a processor, the memory of the terminal device 9200 is used to store executable commands; the processor of the terminal device 9200 is configured to perform the risk identification method according to any of the embodiments of the present specification under the control of the executable command.

< computer-readable storage Medium embodiment >

The present embodiments provide a computer-readable storage medium having stored therein an executable command that, when executed by a processor, performs a method described in any of the method embodiments of the present specification.

One or more embodiments of the present description may be a system, method, and/or computer program product. The computer program product may include a computer-readable storage medium having computer-readable program instructions embodied thereon for causing a processor to implement various aspects of the specification.

The computer readable storage medium may be a tangible device that can hold and store the instructions for use by the instruction execution device. The computer readable storage medium may be, for example, but not limited to, an electronic memory device, a magnetic memory device, an optical memory device, an electromagnetic memory device, a semiconductor memory device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer readable storage medium would include the following: a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a Static Random Access Memory (SRAM), a portable compact disc read-only memory (CD-ROM), a Digital Versatile Disc (DVD), a memory stick, a floppy disk, a mechanical coding device, such as punch cards or in-groove projection structures having instructions stored thereon, and any suitable combination of the foregoing. Computer-readable storage media as used herein is not to be construed as transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission medium (e.g., optical pulses through a fiber optic cable), or electrical signals transmitted through electrical wires.

The computer-readable program instructions described herein may be downloaded from a computer-readable storage medium to a respective computing/processing device, or to an external computer or external storage device via a network, such as the internet, a local area network, a wide area network, and/or a wireless network. The network may include copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers and/or edge servers. The network adapter card or network interface in each computing/processing device receives computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in a computer-readable storage medium in the respective computing/processing device.

The computer program instructions for carrying out operations for embodiments of the present description may be assembly instructions, Instruction Set Architecture (ISA) instructions, machine related instructions, microcode, firmware instructions, state setting data, or source code or object code written in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, C + + or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet service provider). In some embodiments, an electronic circuit, such as a programmable logic circuit, a Field Programmable Gate Array (FPGA), or a Programmable Logic Array (PLA), can execute computer-readable program instructions to implement various aspects of the present description by utilizing state information of the computer-readable program instructions to personalize the electronic circuit.

Aspects of the present description are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the description. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer-readable program instructions.

These computer-readable program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks. These computer-readable program instructions may also be stored in a computer-readable storage medium that can direct a computer, programmable data processing apparatus, and/or other devices to function in a particular manner, such that the computer-readable medium storing the instructions comprises an article of manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block or blocks.

The computer readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the instructions which execute on the computer, other programmable apparatus or other devices implement the functions/acts specified in the flowchart and/or block diagram block or blocks.

The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present description. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions. It is well known to those skilled in the art that implementation by hardware, implementation by software, and implementation by a combination of software and hardware are equivalent.

The foregoing description of the embodiments of the present specification has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the embodiments disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is chosen in order to best explain the principles of the embodiments, the practical application, or improvements made to the technology in the marketplace, or to enable others of ordinary skill in the art to understand the embodiments disclosed herein. The scope of the application is defined by the appended claims.

Claims

1. A risk identification method, implemented by a server, comprising:

returning a set identification result corresponding to the user operation to the service system under the condition that the synchronous identification fails, starting asynchronous identification for identifying whether the user operation has risks or not,

the business system is used for realizing user requirements, the user operation is preset in a server and can trigger wind control analysis, the synchronous identification failure comprises synchronous identification, an identification result is not obtained within set time, the asynchronous identification for identifying whether the user operation has risks comprises obtaining a first set characteristic extracted when the user operation is synchronously identified, extracting a second set characteristic when the asynchronous identification is carried out aiming at the user operation, and identifying whether the user operation has risks according to the first set characteristic and the second set characteristic, wherein the first set characteristic is a characteristic which does not occur along with time, and the second set characteristic is a characteristic which changes along with time.

2. The method of claim 1, further comprising:

3. The method of claim 2, the performing, for the user operation, additional processing of recognition results that match the asynchronous recognition comprising:

acquiring a service scene to which the user operation belongs;

4. The method of claim 1, the synchronization recognition failure comprising the synchronization recognition failing to obtain a recognition result within a set time.

5. The method of claim 1, the returning to the business system a set identification corresponding to the user action, comprising:

6. The method of claim 1, further comprising:

7. The method of claim 1, further comprising:

8. The method of claim 3 or 7, further comprising:

9. The method of claim 1, the re-identifying asynchronous identification of whether the user operation is at risk, comprising:

10. The method of claim 9, the re-identifying asynchronously whether the user operation is at risk, further comprising:

11. A risk identification method is implemented by a terminal device for installing a business system, and comprises the following steps:

responding to user operation triggered by a user in the business system, and sending a risk identification request for identifying whether the user operation has risks to a server;

responding to the additional processing initiated by the server for the user operation after the synchronous identification result is returned, and executing corresponding additional processing operation; wherein an additional processing mode of the additional processing is determined by the server according to an asynchronous identification result of asynchronous identification for identifying whether the user operation is at risk or not, the asynchronous identification is started after the synchronous identification fails,

The business system is a system for realizing user requirements, the user operation is a user operation which is preset in a server and can trigger wind control analysis, and the asynchronous recognition for recognizing whether the user operation has risks comprises the steps of acquiring a first set characteristic extracted when the user operation is synchronously recognized, extracting a second set characteristic when the user operation is asynchronously recognized, and recognizing whether the user operation has risks according to the first set characteristic and the second set characteristic, wherein the first set characteristic is a characteristic which does not occur along with time, and the second set characteristic is a characteristic which changes along with time.

12. The method of claim 11, wherein the method, after performing the respective append processing operation, further comprises:

an alert is made that the additional processing operation has been performed.

13. A risk identification device comprising:

an asynchronous identification module, configured to, if the synchronous identification fails, return a set identification result corresponding to the user operation to the service system, and start to perform asynchronous identification for identifying whether the user operation is risky,

Wherein the service system is a system for realizing user requirements, the user operation is a user operation which is preset in the server and can trigger the wind control analysis, the synchronous identification failure comprises that the synchronous identification does not obtain an identification result within a set time,

the asynchronous identification module is further configured to: the method comprises the steps of acquiring a first setting feature extracted when the user operation is synchronously recognized, extracting a second setting feature extracted when the user operation is asynchronously recognized, and recognizing whether the user operation is at risk or not according to the first setting feature and the second setting feature, wherein the first setting feature is a feature which does not occur along with time, and the second setting feature is a feature which changes along with time.

14. An electronic device comprising the risk identification apparatus of claim 13, or comprising:

a memory for storing executable commands;

a processor for performing the risk identification method of any of claims 1-12 under control of the executable command.

15. A risk identification system, comprising:

a server comprising a memory and a processor, the memory of the server for storing executable commands; the processor of the server is configured to execute the risk identification method of any of claims 1-10 under control of the executable command; and the number of the first and second groups,

The terminal equipment comprises a memory and a processor, wherein the memory of the terminal equipment is used for storing executable commands; the processor of the terminal device is adapted to perform the risk identification method of claim 11 or 12 under control of the executable command.

16. A computer-readable storage medium storing executable instructions that, when executed by a processor, perform the risk identification method of any of claims 1-12.