CN112766977B

CN112766977B - Risk identification method, device and system

Info

Publication number: CN112766977B
Application number: CN202110110521.2A
Authority: CN
Inventors: 姚磊; 赵华; 郑亮
Original assignee: Alipay Hangzhou Information Technology Co Ltd
Current assignee: Alipay Hangzhou Information Technology Co Ltd
Priority date: 2021-01-27
Filing date: 2021-01-27
Publication date: 2022-06-28
Anticipated expiration: 2041-01-27
Also published as: CN112766977A

Abstract

The embodiment of the specification provides a risk identification system, method and device. In the risk identification system, various data are converged into a data pool through a data bus in one-way transmission, and risk algorithms in various clients are converged into an algorithm pool through an algorithm bus in one-way transmission. Therefore, for a certain business event, on the premise of keeping the safety isolation of each client, the data in the data pool can be comprehensively processed by using various risk algorithms in the algorithm pool, and a more comprehensive risk identification result can be obtained.

Description

Risk identification method, device and system

Technical Field

The embodiment of the specification relates to the technical field of data security, in particular to a risk identification method and device.

Background

With the continuous development of science and technology, a variety of clients are developed to meet the requirements of users in different aspects of social contact, shopping, entertainment, instant messaging, payment and the like.

On one hand, the client meets partial requirements of users, and on the other hand, the client can also become a medium for lawless persons to implement illegal behaviors. For example, Zhang III obtains the sales information of a certain commodity through a social platform client, then Zhang III adopts an instant messaging client to contact with a publisher (lawbreaker) of the sales information and reach a transaction consensus, and then payment is carried out on the transaction through a payment client. Therefore, the exchange has more links, and the clients involved in each link are different, so that difficulty is brought to risk identification.

Disclosure of Invention

The embodiment of the specification provides a risk identification method and a risk identification device, and the risk identification capability is effectively improved.

According to a first aspect, a risk identification method is provided, which is applied to a risk identification system in a user terminal device; the risk identification system includes: the system comprises a data pool, an algorithm pool, a first bus and a second bus, wherein the first bus is used for transmitting data to the data pool in a unidirectional mode, and the second bus is used for transmitting algorithms to the algorithm pool in a unidirectional mode; the method comprises the following steps:

acquiring target data from a plurality of items of data stored in the data pool aiming at a current event, wherein the plurality of items of data are transmitted through the first bus, and at least comprise business data related to risk determination in a plurality of clients installed on the user terminal equipment;

processing the target data by using a target algorithm in a plurality of risk algorithms stored in the algorithm pool to obtain a to-be-determined identification result corresponding to the target algorithm, wherein the risk algorithms are obtained by transmitting algorithms used by the clients for determining risks through the second bus;

and according to the undetermined identification results corresponding to the risk algorithms, identifying the risk of the current event.

According to one embodiment, the plurality of items of data in the data pool further comprise non-service data, said non-service data being data in said user terminal device other than service data specific to said number of clients.

According to one embodiment, the method further comprises: acquiring newly added data transmitted through the first bus; and updating the data pool according to the newly added data.

Further, according to an embodiment, the obtaining of the new data transmitted through the first bus may include: acquiring newly generated service data of the plurality of clients; and/or; and acquiring the updated non-service data in the user terminal equipment.

In one embodiment, the data pool further stores metadata, and the metadata includes a plurality of description information identifiers; the metadata shows the storage positions of the fields of the items of data corresponding to the description information identification in the data pool.

In the case that metadata is stored, the step of obtaining target data from the plurality of items of data stored in the data pool may include: determining a description information identifier corresponding to the data required by the target algorithm as a target identifier; determining a storage location of a field corresponding to the target identification in the data pool by querying the metadata; and reading the field content as target data according to the storage position.

In the case that metadata is stored, the step of updating the data pool according to the new data may include: for each field of the newly added data, determining a description information identifier corresponding to the field in each description information identifier of the metadata; storing the newly added data to a data pool; and adding the storage position of each field to the record identified by the description information corresponding to the field so as to update the metadata.

According to an embodiment, after obtaining the to-be-determined recognition result corresponding to the target algorithm, the method further includes: and inputting the obtained undetermined identification result into the data pool.

In an embodiment of the foregoing implementation, the obtaining target data from a plurality of items of data stored in the data pool may specifically include: and determining the pending recognition result matched with the current event from the generated pending recognition results stored in the data pool, and classifying the pending recognition result into the target data.

According to one embodiment, the method further comprises: acquiring a new algorithm through the second bus; and updating the algorithm pool according to the newly added algorithm.

Further, in an embodiment, when a first client newly installed in the user terminal device is detected, a connection may be established with the first client, and a first risk algorithm for determining a risk in the first client is obtained as the new-added algorithm through the second bus; the first risk algorithm is then added to the algorithm pool.

In another embodiment, when it is detected that an installed second client performs program update on an original second risk algorithm, an updated third risk algorithm may be obtained from the second client as a new algorithm through the second bus; then, in the algorithm pool, the original second risk algorithm is replaced with a third risk algorithm.

According to an embodiment, according to the undetermined recognition results corresponding to the risk algorithms, the risk recognition for the current event specifically includes: according to the weights of the risk algorithms, carrying out weighted fusion on the to-be-determined identification results corresponding to the risk algorithms; the weight is obtained according to the accuracy of the to-be-determined identification result generated in the history by the risk algorithms; and determining a risk identification result of the current event according to a result obtained by the weighted fusion.

Optionally, in an embodiment, after determining the risk identification result of the current event, the method further includes: if the risk identification result shows that the risk is high risk, a first alarm strategy is adopted; if the risk identification result shows that the risk is low, adopting a second alarm strategy; the first alarm policy comprises: interrupting execution of the current event; the second alarm policy includes: and sending out alarm information.

Optionally, in another embodiment, after determining the risk identification result of the current event, the method further includes: acquiring a reference result corresponding to a current event; the reference result is obtained by other entities except the risk identification system and the plurality of clients according to the risk of the current event; and adjusting the weights corresponding to the risk algorithms according to the matching degrees of the undetermined identification results corresponding to the risk algorithms and the reference results.

Further, in one example, obtaining the reference result corresponding to the current event includes: generating confirmation information according to the risk identification result, and displaying the confirmation information to the user triggering the current event; and determining the reference result according to the feedback of the user aiming at the confirmation information.

According to one embodiment, the risk includes a plurality of risk types; the weights comprise sub-weights corresponding to the plurality of risk types; the to-be-determined identification result corresponding to the target algorithm comprises the identified target risk type and a first risk degree corresponding to the target risk type. After obtaining the reference result corresponding to the current event, the method further comprises: determining a second risk level in the reference result corresponding to the target risk type; and when the matching degree of the first risk degree and the second risk degree is greater than a preset matching degree threshold value, improving the sub-weight of the target algorithm corresponding to the target risk type.

According to one embodiment, the user terminal device comprises a secure area, and the risk identification system is deployed in the secure area.

According to a second aspect, there is provided a risk identification apparatus, the apparatus being deployed in a risk identification system; the risk identification system includes: the system comprises a data pool, an algorithm pool, a first bus and a second bus, wherein the first bus is used for transmitting data to the data pool in a unidirectional mode, and the second bus is used for transmitting algorithms to the algorithm pool in a unidirectional mode; the device comprises:

a data pool control module configured to acquire target data from a plurality of items of data stored in the data pool for a current event, wherein the plurality of items of data are transmitted through the first bus, and at least include business data related to risk determination in a plurality of clients installed on the user terminal device;

the algorithm pool control module is configured to process the target data by using a target algorithm in a plurality of risk algorithms stored in the algorithm pool to obtain a to-be-determined identification result corresponding to the target algorithm, wherein the risk algorithms are obtained by transmitting the algorithms used by the clients for determining risks through the second bus;

And the risk merging module is configured to identify risks aiming at the current event according to the undetermined identification results corresponding to the risk algorithms.

According to a third aspect, there is provided a risk identification system deployed in a user terminal device, comprising: the system comprises a data pool, an algorithm pool, a first bus and a second bus, wherein the first bus is used for transmitting data to the data pool in a unidirectional mode, and the second bus is used for transmitting algorithms to the algorithm pool in a unidirectional mode; the risk identification system further comprises a risk identification device as described in the second aspect.

According to a fourth aspect, there is provided a computer readable storage medium having stored thereon a computer program which, when executed in a computer, causes the computer to perform the method of the first aspect.

According to a fifth aspect, there is provided a computing device comprising a memory and a processor, wherein the memory has stored therein executable code, and the processor, when executing the executable code, implements the method of the first aspect.

According to the method and the device provided by one embodiment of the specification, various data in the terminal equipment are gathered to the data pool, and risk algorithms of various clients are gathered to the algorithm pool. Therefore, for the event occurring in the user terminal equipment, the full-link and cross-application comprehensive risk assessment can be performed on the event by utilizing various algorithms in the algorithm pool based on the data with rich sources in the data pool, and the accuracy of risk identification is improved.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings needed to be used in the description of the embodiments are briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments of the present invention, and it is obvious for those skilled in the art to obtain other drawings based on these drawings without creative efforts.

FIG. 1 illustrates a schematic diagram of existing client-based risk identification;

FIG. 2 illustrates a risk identification timeline according to one embodiment;

FIG. 3 illustrates a risk identification system architecture diagram according to one embodiment;

fig. 4 shows a schematic diagram of updating a data pool according to traffic data, non-traffic data and pending identification results, according to an embodiment;

FIG. 5 illustrates a flow diagram of a risk identification method according to one embodiment of the present description;

FIG. 6 illustrates a schematic diagram of determining target data in a data pool, according to one embodiment;

FIG. 7 illustrates a schematic structural diagram of a risk identification device deployed in a risk identification system, according to one embodiment;

FIG. 8 illustrates a schematic diagram of an electronic terminal according to one embodiment.

Detailed Description

The present specification will be described in further detail with reference to the accompanying drawings and examples. It is to be understood that the specific embodiments described herein are merely illustrative of the invention and are not to be construed as limiting the invention. The described embodiments are only a subset of the embodiments described herein and not all embodiments described herein. All other embodiments obtained by a person skilled in the art based on the embodiments in the present specification without any inventive step are within the scope of the present application.

As used in this specification and the appended claims, the terms "a," "an," "the," and/or "the" are not intended to be inclusive in the singular, but rather are intended to be inclusive in the plural, unless the context clearly dictates otherwise. In general, the terms "comprises" and "comprising" merely indicate that steps and elements are included which are explicitly identified, that the steps and elements do not form an exclusive list, and that a method or apparatus may include other steps or elements.

It should be noted that, for convenience of description, only the portions related to the related invention are shown in the drawings. The embodiments and features of the embodiments in the present description may be combined with each other without conflict.

Flow charts are used in this description to illustrate operations performed by a system according to embodiments of the present description. It should be understood that the preceding or following operations are not necessarily performed in the exact order in which they are performed. Rather, the various steps may be processed in reverse order or simultaneously. Meanwhile, other operations may be added to the processes, or a certain step or several steps of operations may be removed from the processes.

The existing risk identification algorithm is mostly completed by a client. For example, in the scenario shown in fig. 1, the terminals have clients 1 to n installed thereon. The terminal captures the operation of the user, and when the current user operation is directed to the client 1, the client 1 performs corresponding operation according to the operation of the user. The client 1 comprises a risk algorithm and m other algorithms than the risk algorithm (e.g. m traffic related algorithms). When the current operation of the user meets the risk identification triggering condition of the client 1, the client 1 adopts the risk algorithm to determine the risk corresponding to the current operation of the user, and takes corresponding measures.

Assuming that the client 1 is a payment client, the operation currently performed by the user is a payment operation, and the client 1 can only identify the risk of the payment service according to the payment operation behavior of the user. Before this, as shown in fig. 2, the user communicates with the lawbreaker corresponding to the payment service through the instant messaging client in fig. 1, and due to the limitation of the operating system of the terminal, the clients are kept isolated from each other, and the payment client cannot know the communication situation between the user and the lawbreaker through the instant messaging client.

As can be seen, when the client 1 identifies the risk, it cannot be combined with other operations that are performed by other clients (for example, the clients 2 to n in fig. 1) related to the payment operation in the history by the user, so that the client 1 may judge the risk of the current payment service in a single aspect.

In view of this, the embodiments of the present specification provide a risk identification system and a risk identification method based on the risk identification system. In the risk identification system, various data are gathered in a data pool through a data bus with unidirectional transmission, and risk algorithms in various clients are gathered in an algorithm pool through an algorithm bus with unidirectional transmission. Therefore, on the premise of keeping the safety isolation of each client, the data in the data pool are comprehensively processed by using various risk algorithms in the algorithm pool, and a more comprehensive risk identification result is obtained.

FIG. 3 shows a schematic diagram of a risk identification system according to one embodiment. The risk identification system can be typically deployed in a user terminal device, and a plurality of clients can be further installed on the user terminal device, and the risk identification system is used for performing comprehensive risk assessment on a user operation event in the user terminal device. The specification does not specifically limit the type of the user terminal device, and the terminal device may be a mobile phone, a tablet computer, a Personal computer, a notebook computer, a Personal Digital Assistant (PDA), a wearable terminal (e.g., smart glasses, smart watches), and the like.

In one embodiment of the present specification, the risk identification System may be an Operating System (OS) of the terminal device, and the client may be an Application (APP) installed on the Operating System. In another embodiment, the risk identification system may be an underlying application on top of the operating system with a higher privilege level than the normal client App. For convenience of description, the risk identification system is exemplified as an operating system of the user terminal device.

As shown in fig. 3, the risk identification system at least comprises a data pool, an algorithm pool, a first bus and a second bus, wherein the first bus is used for transmitting data to the data pool in a unidirectional mode, and the second bus is used for transmitting the algorithm to the algorithm pool in a unidirectional mode. Although not shown, it is understood that the risk identification system also has its operational logic, including at least a data pool control module that controls reading, writing, and updating of the data pool, and an algorithm pool control module that controls updating and operation of the algorithm pool.

The data pool is used for storing various data gathered through the first bus. In an alternative scenario where security requirements are high, only the risk identification system has access to the data pool. The specification does not limit the specific form of the data pool. For example, the data pool may be a higher security area in the storage area of the terminal device.

The data stored in the data pool at least includes the service data of each client, which may also be referred to as the proprietary data of the client. For example, assuming that the user terminal device of fig. 3 has n clients installed, each client i transmits and stores its service data i to the data pool through the first bus. In addition, in one embodiment, the data pool further stores non-service data, that is, data in the user terminal device other than the service data specific to the client, which may also be referred to as terminal public data. The traffic data and non-traffic data are further explained below.

A service in this specification refers to a transaction processed by a client. The traffic data may include: under the condition of self risk identification, the client is used for determining data required by a risk algorithm of the risk. It can be seen that the service data in this specification may be at least one of data acquired by the client indicating the operating system when processing the service, and intermediate data generated by the client when processing the service.

Taking a payment client as an example, as shown in fig. 4, when a user pays by using the payment client, the client sends a facial data acquisition instruction to an operating system for identity authentication and risk identification, the operating system controls an image acquisition device of a terminal to acquire facial data according to the facial data acquisition instruction, and then, under the control of the operating system, facial data a of the user acquired by the image acquisition device is sent to the payment client, so that the facial data a can be used as data acquired by the payment client and indicating the operating system. After the face data a is collected, the payment client compares the face data a with the face standard data obtained in advance (the comparison is optionally performed by the face data processing module of the payment client), and the obtained face data comparison result can be used as intermediate data. The face data a acquired by the payment client indicating the operating system and/or the comparison result of the face data can be used as the business data of the payment client.

And the service data is transmitted by the corresponding client through the first bus and is stored in the data pool.

The non-service data is data except service data specific to each client in the user terminal device, and is terminal public data. The terminal public data can be collected through data collection instructions generated by other programs (which can include the risk identification system) besides the various clients.

For example, as described above, if a user performs payment by using a payment client, the payment client collects face data a of the user, where the face data a is related to a service executed by the payment client, and the face data a is service data.

If the user terminal device collects the face data b of the user when the user is self-shooting, at this time, the face data b is for self-shooting, is completed under the control of the operating system of the mobile phone, and does not relate to the business executed by the client installed in the mobile phone, then the face data b is non-business data.

Typically, in the case that the user terminal device is a smart phone, the terminal public data may include a short message, positioning data, a browsing record, collected image data (such as facial data), a call record, and the like. The public data of the terminal can be transmitted and stored to the data pool through the first bus under the control of the operating system.

The updating of data in the data pool may be triggered in a variety of situations. For example, in one embodiment, when a client generates new service data, the client transmits the newly generated service data as new data to the data pool through the first bus, that is, updates the service data in real time. For example, the thick solid line in fig. 4 shows the data flow direction of updating the data pool according to the service data. In another embodiment, when new non-service data (terminal public data) is generated in the user terminal device, the risk identification system acquires the new non-service data as new data through the first bus, thereby updating the non-service data in real time. For example, the data flow direction for updating the data pool according to the non-traffic data is shown in fig. 4 with a gray solid line. In another embodiment, for both the service data and the non-service data, the new data may be transmitted to the data pool in a manner of periodically reporting at regular intervals, so as to update the data pool.

Due to the one-way transmission characteristic of the first bus, the client can only transmit the service data to the data pool and cannot read the data from the data pool, so that the safety isolation among the clients is ensured, and the risk that the client reads the data in a range which is not the authority of the client is avoided.

As described above, the data pool is populated with proprietary service data from each client and terminal public data in the user terminal device. It is to be understood that in an actual scenario, developers of different clients may be different, and data from different clients in the data pool may follow different protocols, having different data formats or data structures. In order to enable the data pool to effectively store the non-service data and the service data from different clients and enable the data in the data pool to meet different requirements of different risk algorithms in the following, in one embodiment of the present specification, a process of writing the data in the data pool and writing the data into the data pool is standardized.

In an alternative embodiment, the metadata of the data pool may be predetermined, and the metadata includes several description information identifiers; the metadata may show the storage location of any data in the data pool corresponding to the field identified by the aforementioned description information in the data pool. For example, the description information identification may include at least one of: business object identification (e.g., cell phone number, name, account number of the shopping platform, etc.), business identification (e.g., order number, etc.), business content (e.g., name of goods involved in the business, etc., shipping address, amount of money).

In the case that the metadata is included in the data pool, when the data pool is updated, newly added data (including at least one of the aforementioned business data and non-business data) to be written into the data pool may be first acquired. Then, for each field of the newly added data, in each description information identifier of the metadata, a description information identifier corresponding to the field is determined. After the newly added data is stored in the data pool, the storage position of the field is also added to the record identified by the description information corresponding to the field, so as to update the metadata.

Therefore, in the description, the process of writing the newly added data into the data pool according to the metadata can store the data from different sources in a unified and standard manner, so that the follow-up data can be more efficiently inquired and used.

In addition to the data pools described above, another important storage component in a risk identification system is the algorithm pool. The algorithm pool is used for storing various risk algorithms converged through the second bus, the risk algorithms are algorithms adopted in the client side when risk assessment is carried out by the client side, and the risk algorithms are transmitted to the algorithm pool through the second bus by the client sides.

The present specification does not specifically limit which clients in the terminal device contribute risk algorithms to the risk identification system and which clients contribute business data. One client only contributes one of risk algorithm and business data; there may also be another client contributing both risk algorithms and business data, or there may be yet another client contributing multiple risk algorithms.

Due to the one-way transmission characteristic of the second bus, the client can only transmit the risk algorithm to the algorithm pool and cannot read the algorithm from the algorithm pool, so that the safety isolation among the clients is ensured, and the risk that one client acquires the risk algorithms of other clients is avoided.

The risk algorithms in the algorithm pool may be continuously updated dynamically. Specifically, the newly added algorithm may be obtained through the second bus, and then the algorithm pool is updated according to the newly added algorithm. The updating of the above algorithm pool may be triggered in a variety of situations.

For example, in one embodiment, when a newly installed client (referred to as a first client for simplicity) in the user terminal device is detected, a connection is established with the first client, and a first risk algorithm for determining risk in the first client is acquired through the second bus. The first risk algorithm may then be added to the algorithm pool as a new algorithm.

In another embodiment, when it is detected that the installed second client performs program update for its original second risk algorithm, the updated third risk algorithm is obtained from the second client through the second bus. And then, replacing the original second risk algorithm with a third risk algorithm in the algorithm pool, so as to update the corresponding risk algorithm.

In another embodiment, the risk identification system may also check whether a new client is present in the user terminal device and whether an existing client has performed algorithm update at predetermined time intervals, so as to determine whether a new algorithm exists. And under the condition that the newly added algorithm is determined to appear, updating the algorithm pool according to the newly added algorithm.

Thus, in the risk identification system of fig. 3, various data are converged through the data pool, and various risk algorithms are converged through the algorithm pool, thereby providing a basis for cross-application comprehensive risk identification.

When the risk identification system is an operating system of the terminal and the client is an application installed in the terminal, a secure area, such as a trusted execution environment, may be set in the terminal so that operations performed by the risk identification system related to risk identification are all performed in the secure area, and the aforementioned data pool and/or algorithm pool are also set in the secure area to achieve privacy protection during the entire operation of the risk identification system. In addition, the security area is isolated from an area used for installing the client in the terminal, so that data and algorithms in the security area are prevented from being acquired by the client.

The following describes a process of risk identification based on the above risk identification system, with reference to the system architecture of fig. 3 and the flowchart of fig. 5.

Fig. 5 shows a flowchart of a risk identification method according to an embodiment of the present specification, the method flow being performed by the risk identification system described above. As shown in fig. 5, the method flow includes the following steps.

In step S51, for the current event, target data is acquired from the plurality of items of data stored in the data pool; and in step S52, processing the target data by using a target algorithm of the risk algorithms stored in the algorithm pool to obtain a to-be-determined recognition result corresponding to the target algorithm.

It should be noted that the object of risk identification may be a current event, and the current event may include a series of operations performed by the user through the user terminal device. For example, a user communicates with a newly added contact person through a social client, and then receives a short message; and then the user enters the payment client side and opens a payment page to prepare payment. This series of operational sequences, which occur in the terminal device, possibly across platforms and applications, collectively constitute the current event.

Risk identification of a current event may be triggered in a number of ways. In one embodiment, when the operating system detects that the user performs a predetermined high-risk operation, such as transfer, payment, etc., the risk identification system is triggered to perform comprehensive risk identification on the current event. In another embodiment, when any client installed in the user terminal equipment starts a risk algorithm carried by the client for risk assessment, the client simultaneously sends a request to the risk identification system; the risk identification system initiates a comprehensive risk identification of the current event in response to such a request.

In order to perform comprehensive risk identification on the current event, as shown in step S51, target data is first obtained from a plurality of items of data stored in a data pool. The above target data is data required for the target algorithm mentioned in step S52 to perform risk calculation. In one embodiment, the steps S51-S52 may be performed with each risk algorithm stored in the algorithm pool as the target algorithm in turn; in another embodiment, the steps S51-S52 may be performed by using risk algorithms corresponding to several clients involved in the current event as target algorithms respectively. In other embodiments, other ways of determining the target algorithm may also be used.

The target data required by the target algorithm is different according to the target algorithm, and the target algorithm may include the aforementioned traffic data and/or non-traffic data. As mentioned above, the business data may further include intermediate data generated by each algorithm in performing risk calculation, for example, a comparison result obtained by comparing the collected facial data a and the facial standard data by the payment client may be transmitted to the data pool as intermediate data. Such intermediate data may be input to other algorithms and thereby be invoked by the other algorithms for further calculations. It should be noted that such data "calling" or multiplexing is performed through a data pool. The data pool is used as a unique bridge for data calling, and each risk algorithm can only read data from the data pool but cannot read data from other clients, so that the safety isolation among the clients is ensured.

In one embodiment, after each risk algorithm derives the pending recognition result based on its algorithm logic, the pending recognition result is also written back to the data pool for reference and use by other risk algorithms. For example, the data flow of the update process is shown in fig. 4 with a thin solid line. In such a case, the target data obtained for the current target algorithm may further include a generated pending recognition result stored in the data pool that matches the current event. Correspondingly, the step S51 of obtaining the target data may further include determining a pending recognition result matching the current event from the generated pending recognition results stored in the data pool, and including the pending recognition result in the target data.

Specifically, in an optional embodiment of this specification, a service identifier corresponding to service data may be determined according to the service data used by a current target algorithm to perform risk identification for a current event, and an undetermined identification result matched with the service identifier is determined in each undetermined identification result stored in the data pool as the target data. The way of determining whether there is a match may be: and judging whether the service identifier of the service corresponding to the to-be-determined identification result is the same as the service identifier corresponding to the service data. Generally, the pending recognition result of the match determined in this way is a pending recognition result generated by other clients for the current event, or a pending recognition result generated by each client for a historically similar event.

For example, in a scene with a false transaction risk, a risk algorithm a of a communication client is used as a target algorithm to generate a pre-pending recognition result a, where a service identifier corresponding to the pending recognition result a may be at least one of a phone number, an account number of an instant communication client, an item name and a connection related to the false transaction, which are related to a user when the user uses the instant communication client to communicate. The algorithm B that paid the client contribution is then taken as the target algorithm. At this time, if the phone number in the previously pending identification result a is searched in the service identifier corresponding to the service data adopted by the algorithm B, the two are matched. The previously pending recognition result a can then be determined as target data for the target algorithm B.

Similar to the invocation of the intermediate data, the invocation of the pending recognition result is also performed through the data pool. Any client cannot directly obtain the undetermined identification result of the risk algorithm of the other client, and safety isolation is kept among the clients.

As can be seen from the foregoing, the target data in the present specification may be at least one of traffic data, non-traffic data, and pending identification results. As shown in fig. 6, in one example, for a certain target algorithm, the traffic data B1, the non-traffic data C1, the non-traffic data C2 and the pending recognition result R2 together constitute target data.

In the case where metadata is set in the data pool, it is possible to more efficiently locate desired target data based on the metadata. Specifically, in an optional embodiment of the present specification, the process of obtaining the target data based on the metadata of the data pool may include determining a description information identifier corresponding to data required by the target algorithm for performing the risk calculation, as the target identifier. And determining the storage position of the field content corresponding to the target identification in the data pool by inquiring the metadata, and reading the field content as target data according to the storage position.

After the target data is obtained, in step S52, the target data is input into the target algorithm, and the target data is calculated and processed by using the calculation logic of the target algorithm, so as to obtain a to-be-determined recognition result corresponding to the target algorithm. By respectively processing a plurality of algorithms in the algorithm pool as target algorithms, undetermined recognition results corresponding to the plurality of algorithms can be obtained.

In the above process, data is read from the data pool and input to the corresponding target algorithm in the algorithm pool for processing. Data in the data pool is not in contact with all the clients, so that isolation between the data in the data pool and the clients is guaranteed, and privacy protection is facilitated to be enhanced.

On the basis that the plurality of risk algorithms respectively obtain the corresponding undetermined recognition results, in step S53, risk recognition is performed on the current event according to the undetermined recognition results corresponding to the plurality of risk algorithms. This step may be performed by a risk merging module in the risk identification system shown in fig. 3.

In one embodiment, the risk merging module determines the risk identification result for the current event in a weighted voting manner. Specifically, each risk algorithm may be given a certain weight. Therefore, the respective pending recognition results can be weighted and fused according to the weights corresponding to the risk algorithms. And determining a risk identification result of the current event according to a result obtained by the weighted fusion. In one embodiment, the weights are set by the risk identification system after the accuracy of each risk algorithm is evaluated in advance, and are kept unchanged in the subsequent identification process. In another embodiment, the risk identification system sets an initial value for each risk algorithm in an average manner or a random manner; and in the subsequent identification process, dynamically adjusting the corresponding weight according to the accuracy of the identification result to be determined generated by each risk algorithm.

In one embodiment, in the risk identification process, the risk is classified into a plurality of risk types, e.g., fraud risk, cash-over risk, and so forth. Accordingly, the pending identification result of a certain risk algorithm may comprise a plurality of sub-results, each sub-result having the form of a risk type-risk degree (or risk probability). For example, the pending identification of a current event by a risk algorithm may be: "the probability of suspected fraud risk of the current event is 30% and the probability of suspected theft risk is 12%". One risk algorithm may give the identification of the risk degree or risk probability for all risk types or may give the identification for only part of the risk types.

Under the condition of distinguishing the risk types, according to an embodiment, when merging the undetermined recognition results, for each algorithm i, each risk degree value in the undetermined recognition result obtained by the algorithm i may be first multiplied by the weight wi corresponding to the algorithm i, and then, the weighted degree values of different algorithms for the same risk type are summed to be the final risk degree of the risk type, so that the final risk degree of each risk type is obtained to be the final risk recognition result.

In another embodiment, in the case of differentiating the risk types, the weight corresponding to each risk algorithm may further include a plurality of sub-weights corresponding to the plurality of risk types. In this embodiment, when merging each pending recognition result, for a plurality of sub-results in the pending recognition result obtained by a certain risk algorithm, weighting may be performed on the risk degree value in each sub-result directly based on a plurality of sub-weights corresponding to the risk algorithm. And then, integrating weighted values of the risk degrees given by different algorithms under the same risk type to serve as the final risk degree of the risk type, thereby obtaining a final risk identification result.

After determining the risk identification result, optionally, the risk identification system may further alarm the user based on the risk identification result. The alarm process may be performed by a decision module of the risk identification system shown in fig. 3. Specifically, if the risk identification result shows that the risk is high risk, a first alarm strategy is adopted. If the risk identification result shows that the risk is low, adopting a second alarm strategy; wherein the first alert policy is stronger than the second alert policy. Specifically, for example, the first alarm policy may include: interrupting execution of the current event; the second alert policy may include: and sending out alarm information.

The risk identification result shows whether the risk is high or not, and can be obtained according to the risk degree. Optionally, if the risk degree of at least one risk type shown by the risk identification result is greater than a first threshold of risk degree corresponding to the risk type, determining that the risk identification result shows that the risk is a high risk; if the risk degree of any one risk type shown by the risk identification result is not greater than the first risk degree threshold corresponding to the risk type, and the risk degree of at least one risk type is between the first risk degree threshold corresponding to the risk type and the second risk degree threshold corresponding to the risk type (the first risk degree threshold corresponding to the risk type is greater than the second risk degree threshold corresponding to the risk type), the risk identification result shows that the risk is low risk; and if the risk degree of any one risk type shown by the risk identification result is not greater than the second threshold of the risk degree corresponding to the risk type, determining that no risk exists and not giving an alarm.

Therefore, the mode adopted by the risk identification system in the specification when the alarm is given can be determined according to the risk degree. Events with higher risk degree can be stopped in time, and adverse consequences can be avoided to a greater extent; the event with low risk degree is effectively warned, the risk condition of the event can be prompted to a user, meanwhile, the execution of the service can be prevented from being disturbed excessively, and the improvement of user experience is facilitated.

In an optional embodiment of this specification, the first alarm policy may specifically be: and cutting off the communication network adopted for carrying out the business processing of the current event. For example, if a user is currently performing voice communication with a lawbreaker about a high-risk business event through a user terminal controlled by a risk identification system, a communication network used for the communication can be cut off; for another example, if the user communicates with a lawbreaker about a high-risk business event through the instant messaging client, the internet used for the communication can be cut off. As can be seen, the first alarm strategy can timely suspend the execution of the current event.

The second alarm policy may specifically be: and prompting the current risk condition of the user through sound information, light information, graphic information, vibration and the like. For example, if the user is currently communicating with a lawbreaker about a high-risk business event by voice through a user terminal controlled by a risk recognition system, a prompt tone may be added to the voice message received by the user or the terminal may be caused to emit a vibration prompt. For another example, if the user communicates with a lawbreaker about a high-risk business event through the instant messaging client, the screen of the terminal may flash, or a pop-up window in which prompt information is recorded may be added when the information is displayed to the user. It can be seen that the second alert policy, although not capable of aborting the execution of the current event, can mention a role of prompting the user.

The above describes the process of risk identification and risk handling (alerting) of the risk identification system for the current event. Optionally, the risk fusion policy and the alarm policy in the risk identification system are not invariant. After the risk identification result and the alarm strategy of the current event are output, the risk fusion strategy and/or the alarm strategy can be adjusted according to the reference result and/or the user feedback.

As described above, in the risk fusion process, the risk merging module performs weighted fusion on the respective pending identification results according to the weights corresponding to the risk algorithms to obtain the risk identification results. The weight of each risk algorithm may be dynamically adjusted according to the accuracy of the pending identification result it generates. The adjustment of the weights may be performed by a risk identification optimization module of the risk identification system in the present specification, as shown in fig. 3. Specifically, the risk identification optimization module may determine the accuracy of the identification result to be determined by comparing the identification result to be determined generated by a certain risk algorithm with the real reference result, and then adjust the weight of the risk algorithm according to the accuracy.

More specifically, the process of adjusting the weight of the risk algorithm by the risk identification optimization module may be: after risk identification is carried out on a current event, a reference result corresponding to the current event is obtained; and the reference result is obtained by other entities except the risk identification system and the plurality of clients according to the risk of the current event. And for the undetermined recognition result obtained by a certain risk algorithm aiming at the current event, if the matching degree of the undetermined recognition result and the reference result is greater than a preset matching degree threshold value, the weight of the risk algorithm is increased.

It should be noted that the reference result is obtained by neither the risk identification system nor the client connected to the risk identification system, and the reference result can be embodied as a risk judgment result of the current event, which is more objective with the identity of the bystander, outside the computing environment where the risk identification system is located. In order to improve the objectivity of the reference result, a result obtained by collecting the execution result of the current event after the risk identification is optionally used as the reference result.

For example, in a scenario where the current event involves a transaction, the pending identification result obtained by a risk algorithm for the current event is "probability of fraud risk 5%". However, after that, the user corresponding to the transaction service reports that the transaction service is suspected of fraud, which indicates that the transaction service does have fraud risk. In this case, the fact of reporting can be used as a reference result. Comparing the undetermined recognition result with the reference result, it can be known that the matching degree of the two determinations for the risk degree is lower, and the matching degree does not reach the preset matching degree threshold, that is, the prediction accuracy of the risk algorithm for the risk is lower, and the weight of the risk algorithm should be reduced. On the contrary, if the matching degree of the pending identification result and the reference result is higher, the prediction accuracy of the risk algorithm is higher, and the weight of the risk algorithm can be improved.

In an alternative embodiment of the present description, the reference result may also be generated manually. Specifically, the process of generating the reference result may be: and generating confirmation information according to the risk identification result of the risk identification system aiming at the current event, and displaying the confirmation information to the user triggering the current event. And determining the reference result of the current event according to the feedback of the user aiming at the confirmation information.

As previously described, in one embodiment, risk identification may include identification for multiple risk types, and the weight corresponding to each risk algorithm may be further refined into multiple sub-weights corresponding to the multiple risk types. In fact, there may be cases where the prediction accuracy of the same risk algorithm for different risk types varies. For this reason, according to one embodiment, when the weights are adjusted for the risk algorithms, it is also possible to refine to adjust the sub-weights corresponding to the respective risk types for the respective risk algorithms.

Specifically, it is assumed that the predetermined recognition result corresponding to the target algorithm includes a certain recognized risk type, such as a fraud risk, and a first risk degree corresponding to the risk type. And correspondingly determining the obtained reference result of the current event, wherein the reference result corresponds to the second risk degree of the risk type. And when the matching degree of the first risk degree and the second risk degree is greater than a preset matching degree threshold value, increasing the sub-weight of the target algorithm corresponding to the target risk type, and/or when the matching degree of the first risk degree and the second risk degree is less than the preset matching degree threshold value, reducing the sub-weight of the target algorithm corresponding to the target risk type. The above process may be performed for each sub-result in the to-be-identified result output by each risk algorithm, so that the sub-weights corresponding to each risk type of each risk algorithm are correspondingly adjusted.

Therefore, the process of adjusting the weight by the risk identification optimization module aims to duplicate the risk identification result according to the reference result. Therefore, the risk identification result is closer to the reference result, and the accuracy of risk identification is improved. In this specification, the timing of the adjustment of the weight by the risk identification optimization module is not particularly limited. For example, the weights of the various risk algorithms may be adjusted periodically.

Reviewing the above contents, the risk identification system in the present specification summarizes rich data from various sources through the data pool, and summarizes risk algorithms of a plurality of clients through the algorithm pool, so that under the condition of ensuring security isolation among clients, comprehensive risk assessment of a full link and a cross-platform is performed on events occurring in the terminal device, and efficient and accurate risk identification is realized while data privacy security is protected.

Based on the same idea, the embodiment of the present specification further provides a risk identification device corresponding to the process shown in fig. 5, where the risk identification device is deployed in a risk identification system and is used for controlling an operation process in the risk identification system. As mentioned above, the risk identification system is located in a user terminal device, and includes: the system comprises a data pool, an algorithm pool, a first bus used for transmitting data to the data pool in a unidirectional mode, and a second bus used for transmitting algorithms to the algorithm pool in a unidirectional mode. Fig. 7 shows a schematic structural diagram of a risk identification device deployed in the risk identification system described above according to one embodiment. As shown in fig. 7, the risk identifying apparatus 700 includes:

A data pool control module 71, configured to, for a current event, obtain target data from multiple items of data stored in a data pool, where the multiple items of data are transmitted through the first bus, and at least include business data related to risk determination in a plurality of clients installed on the user terminal device;

an algorithm pool control module 72 configured to process the target data by using a target algorithm of a plurality of risk algorithms stored in an algorithm pool to obtain a to-be-determined identification result corresponding to the target algorithm, wherein the risk algorithms are obtained by transmitting algorithms used by the clients for determining risks through the second bus;

and the risk merging module 73 is configured to perform risk identification on the current event according to the pending identification result corresponding to each of the risk algorithms.

According to one embodiment, the plurality of items of data stored in the data pool further include non-service data, which is data in the user terminal device other than the client-specific service data.

According to one embodiment, the data pool control module 71 is further configured to obtain new data transmitted via the first bus; and updating the data pool according to the newly added data.

In a specific embodiment, the data pool control module 71 obtains new data transmitted through the first bus, specifically, obtains newly generated service data of the plurality of clients; and/or; and acquiring the updated non-service data in the user terminal equipment.

In the presence of metadata, the data pool control module 71 obtains target data from a plurality of items of data stored in the data pool, and specifically may include: determining a description information identifier corresponding to the data required by the target algorithm as a target identifier; determining a storage location of a field corresponding to the target identification in the data pool by querying the metadata; and reading the field content as target data according to the storage position.

In the presence of metadata, the data pool control module 71 updates the data pool according to the new data, which may specifically include: for each field of the newly added data, determining a description information identifier corresponding to the field in each description information identifier of the metadata; storing the newly added data to a data pool; and adding the storage position of each field to the record identified by the description information corresponding to the field so as to update the metadata.

According to an embodiment, after the algorithm pool control module 72 obtains the to-be-determined recognition result corresponding to the target algorithm, the obtained to-be-determined recognition result is also input into the data pool.

According to another embodiment, the acquiring of the target data by the data pool control module 71 specifically includes: and determining the pending recognition result matched with the current event from the generated pending recognition results stored in the data pool, and classifying the pending recognition result into the target data.

According to one embodiment, the algorithm pool control module 72 is further configured to: acquiring a new algorithm through the second bus; and updating the algorithm pool according to the newly added algorithm.

In a specific embodiment, the algorithm pool control module 72 may establish a connection with a first client newly installed in the user terminal device when detecting that the first client is newly installed, and obtain a first risk algorithm for determining risk in the first client through the second bus; the first risk algorithm is then added to the algorithm pool.

In another specific embodiment, the algorithm pool control module 72 may obtain, through the second bus, an updated third risk algorithm from the second client when detecting that the installed second client performs a program update for the original second risk algorithm; then, in the algorithm pool, the original second risk algorithm is replaced with a third risk algorithm.

According to one embodiment, the risk merging module 73 is specifically configured to: according to the weights of the risk algorithms, carrying out weighted fusion on the to-be-determined identification results corresponding to the risk algorithms; the weight is obtained according to the accuracy of the to-be-determined identification result generated in the history by the risk algorithms; and determining a risk identification result of the current event according to a result obtained by the weighted fusion.

According to one embodiment, the apparatus further comprises a decision module 74 configured to apply a first alarm strategy if the risk identification result shows that the risk is high risk; if the risk identification result shows that the risk is low, adopting a second alarm strategy; the first alarm policy comprises: interrupting execution of the current event; the second alarm policy includes: and sending out alarm information.

According to yet another embodiment, the apparatus further comprises a risk identification optimization module 75 configured to: acquiring a reference result corresponding to a current event; the reference result is obtained by other entities except the risk identification system and the plurality of clients according to the risk of the current event; and adjusting the weights corresponding to the risk algorithms according to the matching degrees of the undetermined identification results corresponding to the risk algorithms and the reference result.

In a specific embodiment, the obtaining of the reference result corresponding to the current event by the risk identification optimization module 75 may specifically include: generating confirmation information according to the risk identification result, and displaying the confirmation information to the user triggering the current event; and determining the reference result according to the feedback of the user aiming at the confirmation information.

According to one embodiment, the risk may include a plurality of risk types; the weights comprise sub-weights corresponding to the plurality of risk types; the to-be-determined identification result corresponding to the target algorithm comprises the identified target risk type and a first risk degree corresponding to the target risk type. In such a case, risk identification optimization module 75 may determine a second degree of risk in the reference result corresponding to the target risk type; and when the matching degree of the first risk degree and the second risk degree is greater than a preset matching degree threshold value, improving the sub-weight of the target algorithm corresponding to the target risk type.

Through the risk identification device, risk identification is carried out in the risk identification system.

Embodiments of the present specification also provide a computer-readable storage medium, which stores a computer program, where the computer program is operable to execute any one of the above-mentioned risk identification processes.

The embodiment of the present specification also proposes a schematic structural diagram of the electronic device shown in fig. 8. As shown in fig. 8, at the hardware level, the electronic device may include a processor, an internal bus, a network interface, a memory, and a non-volatile memory, and may also include hardware required for other services. The processor reads the corresponding computer program from the non-volatile memory into the memory and then runs the computer program to realize any one of the above risk identification processes.

Of course, besides the software implementation, this specification does not exclude other implementations, such as a combination of logic devices or software and hardware, and the like, that is, the execution subject of the above processing flow is not limited to each logic unit, and may also be hardware or a logic device.

As will be appreciated by one skilled in the art, embodiments of the present invention may be provided as a method, system, or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present invention may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.

The present invention is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, 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 specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.

The above description is only an example of the present specification, and is not intended to limit the present specification. Various modifications and alterations to this description will become apparent to those skilled in the art. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present specification should be included in the scope of the claims of the present specification.

Claims

1. A risk identification method is applied to a risk identification system in user terminal equipment; the risk identification system includes: the system comprises a data pool, an algorithm pool, a first bus and a second bus, wherein the first bus is used for transmitting data to the data pool in a unidirectional mode, and the second bus is used for transmitting algorithms to the algorithm pool in a unidirectional mode; the method comprises the following steps:

aiming at a current event, acquiring target data from a plurality of items of data stored in the data pool, wherein the plurality of items of data are transmitted through the first bus, and at least comprise business data related to risk determination in a plurality of clients installed on the user terminal equipment;

2. The method of claim 1, wherein the plurality of items of data further comprise non-business data, the non-business data being data in the user terminal device other than the client-specific business data.

3. The method of claim 1, further comprising:

acquiring newly added data transmitted through the first bus;

and updating the data pool according to the newly added data.

4. The method of claim 3, wherein obtaining the new data transmitted over the first bus comprises:

acquiring newly generated service data of the plurality of clients; and/or;

and acquiring the updated non-service data in the user terminal equipment.

5. The method of claim 1, wherein the data pool further stores metadata, and the metadata comprises a plurality of description information identifiers; the metadata shows the storage positions of the fields of the items of data corresponding to the description information identifications in the data pool;

obtaining target data from a plurality of items of data stored in the data pool, including:

determining a description information identifier corresponding to the data required by the target algorithm as a target identifier;

determining a storage location of a field corresponding to the target identification in the data pool by querying the metadata; and reading the field content as target data according to the storage position.

6. The method of claim 3, wherein the data pool further stores metadata, and the metadata comprises a plurality of description information identifiers; the metadata shows the storage positions of the fields of the items of data corresponding to the description information identifications in the data pool;

The updating the data pool according to the newly added data includes:

for each field of the newly added data, determining a description information identifier corresponding to the field in each description information identifier of the metadata;

storing the newly added data to a data pool;

and adding the storage position of each field to the record identified by the description information corresponding to the field so as to update the metadata.

7. The method of claim 1, wherein after obtaining the result of the target algorithm to be identified, the method further comprises: and inputting the obtained undetermined recognition result into the data pool.

8. The method of claim 7, wherein obtaining target data from the plurality of items of data stored in the data pool comprises:

and determining the pending recognition result matched with the current event from the generated pending recognition results stored in the data pool, and classifying the pending recognition result into the target data.

9. The method of claim 1, further comprising:

acquiring a new algorithm through the second bus;

and updating the algorithm pool according to the new algorithm.

10. The method of claim 9, wherein,

acquiring a new algorithm through the second bus, including: when a first client newly installed in the user terminal equipment is detected, connection is established with the first client, and a first risk algorithm for determining risk in the first client is obtained through the second bus;

Updating the algorithm pool according to the new algorithm, comprising: adding the first risk algorithm to the algorithm pool.

11. The method of claim 9, wherein,

acquiring a new algorithm through the second bus, including: when detecting that an installed second client performs program updating on an original second risk algorithm, acquiring an updated third risk algorithm from the second client through the second bus;

updating the algorithm pool according to the new algorithm, comprising: and replacing the original second risk algorithm with a third risk algorithm in the algorithm pool.

12. The method of claim 1, wherein identifying a risk for a current event based on the pending identification results corresponding to each of the plurality of risk algorithms comprises:

according to the weights of the risk algorithms, carrying out weighted fusion on the to-be-determined identification results corresponding to the risk algorithms; the weight is obtained according to the accuracy of the to-be-determined identification result generated in the history by the risk algorithms;

and determining a risk identification result of the current event according to a result obtained by the weighted fusion.

13. The method of claim 12, wherein after determining a risk identification of a current event, the method further comprises:

If the risk identification result shows that the risk is high risk, a first alarm strategy is adopted; if the risk identification result shows that the risk is low risk, adopting a second alarm strategy; the first alarm policy comprises: interrupting execution of the current event; the second alarm policy includes: and sending out alarm information.

14. The method of claim 12, wherein after determining a risk identification of a current event, the method further comprises:

acquiring a reference result corresponding to the current event; the reference result is obtained by other entities except the risk identification system and the plurality of clients according to the risk of the current event;

and adjusting the weights corresponding to the risk algorithms according to the matching degrees of the undetermined identification results corresponding to the risk algorithms and the reference results.

15. The method of claim 14, wherein obtaining a reference result corresponding to a current event comprises:

generating confirmation information according to the risk identification result, and displaying the confirmation information to the user triggering the current event;

and determining the reference result according to the feedback of the user aiming at the confirmation information.

16. The method of claim 14, wherein the risk comprises a plurality of risk types; the weights comprise sub-weights corresponding to the plurality of risk types; the to-be-determined identification result corresponding to the target algorithm comprises an identified target risk type and a first risk degree corresponding to the target risk type; after obtaining the reference result corresponding to the current event, the method further comprises: determining a second risk degree in the reference result corresponding to the target risk type;

adjusting the weights corresponding to the risk algorithms according to the matching degrees of the undetermined identification results corresponding to the risk algorithms and the reference result, specifically comprising: and when the matching degree of the first risk degree and the second risk degree is greater than a preset matching degree threshold value, improving the sub-weight of the target algorithm corresponding to the target risk type.

17. The method of claim 1, wherein the user terminal device comprises a secure area, the risk identification system being deployed in the secure area.

18. A risk identification apparatus deployed in a risk identification system in a user terminal device; the risk identification system includes: the system comprises a data pool, an algorithm pool, a first bus and a second bus, wherein the first bus is used for transmitting data to the data pool in a unidirectional mode, and the second bus is used for transmitting algorithms to the algorithm pool in a unidirectional mode; the device comprises:

19. A risk identification system deployed in a user terminal device, comprising: the system comprises a data pool, an algorithm pool, a first bus and a second bus, wherein the first bus is used for transmitting data to the data pool in a unidirectional mode, and the second bus is used for transmitting algorithms to the algorithm pool in a unidirectional mode; the risk identification system further comprises a risk identification device according to claim 18.

20. A computer-readable storage medium, having stored thereon a computer program which, when executed in a computer, causes the computer to perform the method of any of claims 1-17.

21. A computing device comprising a memory and a processor, wherein the memory has stored therein executable code that, when executed by the processor, performs the method of any of claims 1-17.