WO2019196546A1

WO2019196546A1 - Method and apparatus for determining risk probability of service request event

Info

Publication number: WO2019196546A1
Application number: PCT/CN2019/073869
Authority: WO
Inventors: 王修坤; 陈岑; 杨新星
Original assignee: 阿里巴巴集团控股有限公司
Priority date: 2018-04-12
Filing date: 2019-01-30
Publication date: 2019-10-17
Also published as: CN108399509A; TW201944305A

Abstract

A method and an apparatus for determining the risk probability of a service request event, the method comprising: acquiring event characteristics of a service request event (21); acquiring user personal characteristics of the user to which the service request event relates (22); on the basis of a population relationship graph based on a specific population, determining user relationship characteristics (23); and, on the basis of the event characteristics, the user personal characteristics, and the user relationship characteristics, determining the risk probability of the service request event (24). Thus, the risk of the service request event can be comprehensively evaluated.

Description

Method and apparatus for determining risk probability of a business request event

Technical field

One or more embodiments of the present specification relate to the field of computer technology, and more particularly to a method and apparatus for determining a risk probability of a service request event by a computer.

Background technique

With the development of computer and Internet technologies, more and more businesses are realized through computing platforms, such as commodity transactions, money payments, financial lending, insurance claims, and so on. However, in the execution and processing of many services, if the background of the business requester and the requested business are not reviewed, it is likely to bring greater risks. For example, some criminals may use electronic platforms to implement financial fraud and lending. Cash, insurance, and so on.

In the conventional technology, in order to prevent and reduce the above risks, risk auditing is often performed manually. In some platforms, some simple rules are also set to assist with manual judgment. However, such an approach is inefficient and difficult to meet the needs of rapid business development; and the accuracy of identifying high-risk users and high-risk events depends on the experience of the manually audited salesperson, and the differences in the experience of different salesmen. Bringing operational risks, making auditing accuracy difficult to guarantee, often missing.

Therefore, it is desirable to have an improved solution to reduce the risk of business execution by efficiently and accurately determining the risk probability of business request events.

Summary of the invention

One or more embodiments of the present specification describe a method and apparatus for efficiently determining the risk probability of a service request event.

According to a first aspect, a method of determining a risk probability of a service request event is provided, comprising:

Obtain the event characteristics of the business request event;

Obtaining a user personal characteristic of at least one user involved in the service request event;

Determining a relationship characteristic of the at least one user based on a crowd relationship map of a specific group, wherein the specific group includes the at least one user;

Determining a risk probability of the service request event according to the event characteristic, the user personal characteristic of the at least one user, and the relationship characteristic of the at least one user.

In one embodiment, the event feature includes at least one of the following: a requested service amount, a service registration time, an event occurrence time, a time difference between the service registration time and the event occurrence time, and an event occurrence location.

In one embodiment, the at least one user includes the requestor of the service request event, and the beneficiary of the service request.

In one embodiment, the user personal characteristics described above include one or more of the following: a user basic attribute feature, a user behavior feature, and a user location feature.

Determining, according to an embodiment, the relationship feature vector of the at least one user, specifically: acquiring the specific crowd including the at least one user; acquiring a crowd relationship map of the specific crowd; and based on the crowd relationship map, A relationship characteristic of the at least one user is determined.

In an embodiment, the obtaining the specific group includes, in a plurality of pre-divided subsets of users, determining a subset of users to which the at least one user belongs, and using the subset of users as the specific group; or The at least one user is added to the pre-selected set of users, and the set of users is taken as the specific group of people.

In an embodiment, acquiring the crowd relationship map of the specific crowd further comprises: acquiring a first relationship map constructed for the pre-selected user set; acquiring an association relationship between the at least one user and the user in the pre-selected user set Adding the association relationship to the first relationship map as a crowd relationship map of the specific population.

According to one embodiment, the population relationship map of the specific population described above is established based on one or more of the following relationships: a transaction relationship, a device relationship, a capital relationship, and a social relationship.

In one embodiment, determining the relationship characteristics of the user comprises using a node-vector network structure feature extraction algorithm to convert the relationship map into a vector factor, and determining a relationship feature vector of the user based on the vector factor.

In one embodiment, a risk probability of a business request event is determined using a pre-trained evaluation model that is trained based on a gradient boost decision tree algorithm.

According to a second aspect, an apparatus for determining a risk probability of a service request event includes:

An event feature obtaining unit configured to acquire an event feature of the service request event;

a personal feature obtaining unit configured to acquire a user personal feature of at least one user involved in the service request event;

a relationship feature acquiring unit configured to determine a relationship feature of the at least one user based on a crowd relationship map of a specific group, wherein the specific group includes the at least one user;

The risk determining unit is configured to determine a risk probability of the service request event according to the event feature, the user personal feature of the at least one user, and the relationship feature of the at least one user.

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

According to a fourth aspect, there is provided a computing device comprising a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, implementing the method of the first aspect .

Through the method and apparatus provided by the embodiments of the present specification, based on the event characteristics of the service request event, the user's personal characteristics of the user involved, and the relationship characteristics of the involved users, the risk probability of the service request event is comprehensively determined, thereby making the risk determination more efficient. And accurate.

DRAWINGS

In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the description of the embodiments will be briefly described below. It is obvious that the drawings in the following description are only some embodiments of the present invention, Those skilled in the art can also obtain other drawings based on these drawings without any creative work.

FIG. 1 is a schematic diagram showing an implementation scenario of an embodiment disclosed in the present specification;

2 illustrates a method flow diagram for determining a risk probability of a service request event, in accordance with one embodiment;

FIG. 3 illustrates a flow of steps for determining a relationship feature of a related user, according to one embodiment;

4 illustrates an example of a crowd relationship map in accordance with one embodiment;

Figure 5 shows a schematic block diagram of a risk determining device in accordance with one embodiment.

detailed description

The solution provided in this specification will be described below with reference to the accompanying drawings.

FIG. 1 is a schematic diagram of an implementation scenario of an embodiment disclosed in the present specification. In this implementation scenario, a risk review of a business request event is performed by a computing platform. Users can send business request events to the computing platform, such as applying for a loan, applying for insurance claims, and so on. After the computing platform obtains such a business request, it needs to obtain a variety of information to comprehensively evaluate the risk probability of the event. This multifaceted information includes event information for the business request event, as well as the user's personal characteristics of the user involved in the business request event. In addition, the computing platform also puts the users involved in the event into a specific group of people to obtain the relationship characteristics of the user in the crowd relationship map. On this basis, based on the above event characteristics, user personal characteristics, and user relationship characteristics, comprehensively assess the risk probability of the business request event. The specific execution process of the above scenario will be described below.

2 illustrates a method flow diagram for determining a risk probability of a service request event, in accordance with one embodiment. The execution body of the method may be any system, device, device, platform or server with computing and processing capabilities, such as the computing platform shown in FIG. 1 , more specifically, for example, various backgrounds that need to analyze and manage business risks. Servers, such as Alipay servers, insurance business servers, financial approval servers, etc. As shown in FIG. 2, the method includes the following steps: Step 21: Acquire an event feature of a service request event; Step 22: Acquire a user personal feature of at least one user involved in the service request event; Step 23, based on a specific crowd relationship a map determining a relationship characteristic of the at least one user, wherein the specific group of people includes the at least one user; step 24, according to the event feature, a user profile of the at least one user, and the at least one user A relationship feature that determines a risk probability of the service request event. The manner in which the above various steps are performed will be described below.

First, in step 21, event characteristics of the service request event to be evaluated are obtained. It can be understood that the business request event to be evaluated may be an event for requesting various businesses that may be at risk, for example, applying for a loan, applying for a credit service, applying for insurance claims, and the like. Correspondingly, the event characteristics related to the service request event may include one or more of the following: the requested service type, the requested amount, the time when the request occurred, the service registration time, the time difference between the registration time and the request time, and the event occurrence place. Wait. More specifically, in a specific example, the foregoing service request event is an event for applying for insurance claims, and correspondingly, the event characteristics may include: the requested insurance type, the request settlement amount, the application settlement time, the insurance application time, the insurance application time, and the claim time. Time difference, place of occurrence, etc. In another example, the service request event is an event for applying for a loan, and correspondingly, the event feature may include: a request amount, an application time, a registration time, a time difference between the registration time and the application time, a place of occurrence, and the like.

In addition, at step 22, the user's personal characteristics of the relevant user involved in the service request event are also obtained. In one embodiment, the relevant user involved in the service request event is the service requester. In another embodiment, the relevant users involved in the business request event also include other stakeholders other than the requester. For example, in the event of applying for a loan business, the relevant users involved may include a guarantor, etc., in addition to the loan requester. In the event of applying for insurance claims, the relevant users involved may include, in addition to the claims claimant, insurance beneficiaries. Therefore, the related user involved in the business request event can be multiple users. For each of the related users involved, at step 22, the user's personal characteristics of these users are obtained.

In one embodiment, the user's personal characteristics include basic attributes of the user, such as gender, age, registration duration, contact details, and the like.

In one embodiment, the user personal characteristics include user behavior characteristics. More specifically, the user behavior characteristics may include behavior information related to the user's historical business operations, such as the number of transactions, the average transaction amount, the number of application claims, the number of claims approved, the average claim amount, and the like.

In one embodiment, the user personal characteristics also include user location characteristics, such as where each historical business operation occurs, a range of location changes, and the like.

In further embodiments, the user personal characteristics may also include more aspects of the user characteristics. It can be understood that the user's personal characteristics are only dependent on some characteristics of a certain user, characterizing the user's own attribute characteristics, operating characteristics, and the like. According to the embodiment of the present specification, in addition to acquiring the personal characteristics of the individual user, the user is placed in a certain crowd, thereby discovering the relationship characteristics of the user in the crowd relationship network, so as to perform a more comprehensive analysis based on the relationship feature. And assessment.

Then, in step 23, for each of the related users mentioned in step 22, the relationship characteristics of the respective users are determined based on the crowd relationship map of the specific group, wherein the specific group includes the related users. FIG. 3 illustrates a flow of steps for determining a relationship feature of a related user, ie, a sub-step of step 23, in accordance with one embodiment. As shown in FIG. 3, in order to determine the relationship characteristics of each related user, in step 31, a specific crowd including related users is acquired.

In one embodiment, a sufficiently large set of users is predetermined such that the set of users contains relevant users of the service request event to be evaluated, and the set of users can then be considered as a specific group of people. For example, in the case where the business request event is an application for insurance claims, a collection of all insured persons may be taken as the above specific group.

In one embodiment, the set of full users is divided into a plurality of subsets of users based on certain characteristics of the user. In step 31, a subset of users to which the related user related to the service request event belongs is determined, and the subset of users is used as the specific group.

In one embodiment, a portion of users having certain similarities or associations are pre-selected to form a set of users. For example, in the case that the business request event is an application for insurance claims, all users who have applied for claims may be pre-selected to form a user set. Then, in step 31, it is judged whether the relevant user of the current event is in the above-mentioned user set, and if not, it is added to the user set, and the added user set is taken as the specific crowd.

The above specific population can also be obtained by other means as long as the specific population is included in the relevant user to be analyzed.

Next, at step 32, a population relationship map of the specific population described above is obtained.

In one embodiment, the step includes reconstructing a population relationship map for the particular population described above.

In another embodiment, the particular population is selected from a predetermined set of users, and the system has previously built a crowd relationship map for the set of users. For example, in the example described above, a specific group of people may be selected from a full amount of users, or a subset of users based on a full amount of users, and the system may pre-establish a crowd relationship map for a full amount of users, or establish a subset of each user. The crowd relationship map. At this time, in step 32, the pre-built crowd relationship map may be directly obtained, or the part related to the specific crowd may be extracted from the pre-built crowd relationship map for a larger range of users, as the specific population Crowd relationship map.

In another embodiment, the particular population described above is formed by adding related users to a pre-selected set of users. If the system has constructed a crowd relationship map for the pre-selected set of users, step 32 may include first obtaining a relationship map constructed for the pre-selected set of users; obtaining the user in the related user and the pre-selected set of users The association relationship; then, the above relationship is added to the above relationship map as a population relationship map of the specific group.

Whether pre-built or rebuilt on-site, the construction of crowd relationship maps can be based on multiple relationships.

In one embodiment, the crowd relationship map is established based on the trading relationship of the crowd. For example, if a product purchase transaction is reached between two users, a transaction association is established between the two users. The transaction relationship between users can be determined by acquiring and analyzing the transaction records of a large number of users, thereby establishing a crowd relationship map.

In one embodiment, the crowd relationship map is established based on the device relationship of the crowd. For example, when two or more user accounts log in using the same terminal device, it can be determined that there is a device association between the two or more user accounts. There are two or more user accounts associated with the device, which may be multiple accounts registered by the same entity user, or may be accounts corresponding to multiple users who have close associations (such as family members, colleagues, etc.). The device relationship can be determined by obtaining the entity terminal information corresponding to the user when logging in to the account.

In one embodiment, the crowd relationship map is established based on the funding relationship. For example, when there is a fund transfer operation such as transfer, collection, etc. between two users, a fund association is established between the two users. The relationship between the users can be determined by obtaining and analyzing the records of the user's operation using the electronic wallet, and then the relationship map is established based on the capital relationship.

In one embodiment, the crowd relationship map is established based on social relationships. Nowadays people are increasingly using social applications to interact. For example, two users can interact through social applications such as chatting, red packets, file transfer, etc., so that social connections can be established between the two users. A social relationship between the crowds can be determined based on a large number of social interactions captured by the social application, thereby establishing a crowd relationship map.

Although a few examples are given above, it will be appreciated that a population relationship map can also be established based on a greater variety of population associations. Moreover, the population relationship map can be established based on several kinds of population associations at the same time.

In one embodiment, the crowd relationship map can be formed in the form of a network of nodes. In this form, the crowd relationship map includes a plurality of nodes, each node corresponding to one user, and the nodes having the associated relationship are connected to each other. In one embodiment, the connections between the nodes may have various attributes, such as connection type, connection strength, etc., where the connection types include, for example, a capital connection (a connection based on a capital relationship), a social connection (a social interaction based connection) Etc.), the connection strength can also include, for example, strong connections, weak connections, and the like.

Figure 4 illustrates an example of a crowd relationship map in accordance with one embodiment. As shown in FIG. 4, in this example, the crowd relationship map includes a plurality of nodes, and each node corresponds to one user. The connection between nodes indicates that there is an association between users. It is assumed that the crowd relationship map of FIG. 4 is established based on the capital relationship and social relationship of the crowd. Accordingly, the connection between the nodes can be a capital connection or a social connection. In the example of FIG. 4, different connection types are shown in different line types, that is, the social connections between the nodes are shown in broken lines, and the capital connections between the nodes are shown in solid lines. Also, the strength of the connection is shown by the thickness of the connecting line. For example, thick lines show strong connections and thin lines show weak connections. More specifically, the thick solid line may show a stronger capital connection (eg, the capital interaction exceeds a threshold value of $10,000, for example, 10,000 yuan), and the thin line shows a weaker fund connection (eg, the capital interaction does not exceed the above amount) Threshold); thick dashed lines may show strong social connections (eg, the frequency of interactions exceeds a frequency threshold, eg 10 times per day), thin dotted lines show weaker social connections (eg, the frequency of interaction does not exceed the above frequency threshold) ).

It will be appreciated that in further embodiments, the crowd relationship map may also be characterized in other forms, such as forms, graphics, and the like.

Returning to FIG. 3, based on the acquisition of the population relationship map constructed for a specific population, in step 33, based on the crowd relationship map, the relationship characteristics of the relevant users involved in the current event are determined.

As mentioned earlier, in the crowd relationship map, users with associated relationships are connected to each other. Correspondingly, in one embodiment, for a certain user, features of the connection related to the user, such as the number of connections, the type of connection, the strength of the connection, and other connected to, may be extracted from the crowd relationship map. The user, etc., takes such a connection feature as a relationship feature of the user.

In another embodiment, a crowd learning map is analyzed and characterized using a machine learning aid. In fact, the crowd relationship map can be understood as a network that contains a certain number of nodes (corresponding to users) and the connection relationship between nodes (the relationship between users). Compared to text and images, network information is more difficult to structure into standard data, so it is difficult to apply to machine learning. Recently, several network representation learning algorithms have been proposed to characterize and analyze network structures. The goal of these algorithms is to represent nodes with semantic relationships in the network with low-dimensional, dense, real-valued vectors, which facilitates computational storage without the need to manually extract features and project heterogeneous information into the same low-dimensional space. For easy downstream calculations.

According to the network representation learning algorithm, the network is embedded into a geometric space, and the spatial coordinates of each node are regarded as the characteristics of the node, so that they are put into the neural network for learning and training. Correspondingly, for the crowd relationship map, the map can be mapped into the geometric space, and the spatial coordinates of each user node are calculated as the relationship feature vector. For the calculation of the spatial coordinates of the network nodes, various algorithms can be employed.

In one embodiment, the DeepWalk algorithm is used to determine a vector representation of each node in the network corresponding to the population relationship map. According to the DeepWalk algorithm, a large number of random walk particles are released on the network, and these particles will go out of a sequence of nodes in a given time. If a node is treated as a word, the resulting sequence constitutes a sentence, and thus a "language" in which the node is composed of a sequence can be obtained. Then, using the word vector conversion (Word2Vec) algorithm, a vector representation of each word "word" can be calculated.

In one embodiment, a node-vector (node2vec) structural feature extraction algorithm is employed to convert the population relationship map into a form of a vector factor. The Node2vec node-vector structure feature extraction algorithm improves the random walk strategy in DeepWalk, achieving a balance between Depth-First Search (DFS) and Breadth-First Search (BFS). At the same time, consider local and macro information to optimize the vector generation method. In this way, the user node in the crowd relationship map can be converted into a form of vector representation, so that the vector expression of the user involved in the current event in the crowd relationship map can be determined as its relationship feature vector.

In other embodiments, more ways may be adopted to obtain a relationship feature vector of the current event related to the user from the crowd relationship map. According to different construction methods and different representation modes of the population relationship map, the dimensions and elements of the obtained relationship feature vectors will be different. However, it can be understood that the relationship feature vector comprehensively represents the relationship between the user and other users in the crowd relationship network by characterizing the position of the node corresponding to the user in the crowd relationship map and the connection relationship with other nodes.

Based on the event characteristics acquired in step 21, the user personal characteristics acquired in step 22, and the user relationship characteristics acquired in step 23 as described above, in step 24, the above various features are combined to determine the risk probability of the service request event.

In a specific embodiment, determining a first evaluation score of the service request event based on the event feature; determining a second evaluation score of the service request event based on the user personal characteristic; determining a third evaluation score of the service request event based on the user relationship feature Finally, the first, second, and third evaluation scores are weighted and summed to determine the risk probability score of the service request event. The manner in which the first, second, and third evaluation scores are determined may be performed by a pre-trained model algorithm and model parameters.

In another embodiment, both the user personal characteristics and the user relationship features are represented in the form of a vector. In step 24, the feature vector of the user's personal feature and the feature vector of the user relationship feature are first spliced to obtain a user integrated feature. Then, based on the user comprehensive feature, determining a first evaluation score of the service request event, determining a second evaluation score of the event based on the event feature of the service request event, and finally determining a service request event based on the first and second evaluation scores Risk probability score. The manner in which the first and second evaluation scores are determined may be performed by a pre-trained model algorithm and model parameters.

In another embodiment, an evaluation model is pre-trained that evaluates the risk probability of a business request event based directly on event characteristics, user personal characteristics, and user relationship characteristics. It will be appreciated that the evaluation model is based on training data sets that have been calibrated. In practice, for a business request event whose risk probability is known, such as a manual sample to determine a negative sample event as a claims fraud, or a manual review of a positive sample event determined to be a normal claim, the event characteristics of the event are acquired, and the user involved in the event User personal characteristics. In addition, the user will be involved in the crowd to obtain the relationship characteristics of the user in the crowd relationship map, especially the relationship feature vector. Add the above data to the training data set. In this way, a certain model algorithm and model parameters can be used, and the risk probability of the event is determined based on the event characteristics, the user's personal characteristics and the user relationship characteristics in the training data set, and the risk probability of an event is obtained. Then, based on the obtained risk probability and the actual known risk probability of the event (ie, the loss function), the model algorithm and the model parameters are continuously optimized, thereby training the above evaluation model.

The above evaluation model can employ a variety of specific model algorithms. In one embodiment, the above evaluation model is trained using a Gradient Boosting Decision Tree (GBDT) method.

As known to those skilled in the art, the gradient boost decision tree GBDT method is a supervised method of integrated learning. In the integrated learning method, a plurality of learners are used to separately learn the training sample set, and the final model is a synthesis of the above plurality of learners. The two main methods of integrated learning are Bagging and Boosting. According to the Boosting algorithm, there are sequential orders between learners, and they have different weights. At the same time, weights are assigned to each sample. Initially, each sample has the same weight. After learning the training sample with a certain learner, the weight of the wrong sample is increased, the weight of the correct sample is reduced, and then the subsequent learner is used to learn. Thus, the final prediction is the combination of multiple learner results. On this basis, gradient model can be used to optimize the model function based on the prediction result. This method is called Gradient Boost method.

Under the Gradient Boost framework, each base learner uses the classification regression tree algorithm to form the gradient decision tree GBDT model. The classification regression tree algorithm is a binary learning machine learning algorithm. In the gradient lifting decision tree GBDT algorithm, since a plurality of such classification regression trees are integrated as a learner, the accuracy and coverage of the model are more effective.

More specifically, according to the GBDT algorithm, a plurality of learners using a classification regression tree can be trained for various features, including event features, user personal features, and user relationship features, thereby forming the above-described evaluation model.

In other embodiments, the above evaluation model may also be implemented by other algorithms, such as the aforementioned bagging algorithm in integrated learning, a learner using other algorithms, and the like.

After the evaluation model training is completed, in step 24, the evaluation model can be directly used to determine the risk probability of the current business request event.

In this way, by synthesizing the event characteristics, user personal characteristics and user relationship characteristics of a service request event, the risk probability of the service request event can be comprehensively evaluated, thereby controlling the business execution risk more efficiently and accurately.

According to another embodiment, an apparatus for determining a risk probability of a service request event is also provided. Figure 5 shows a schematic block diagram of a risk determining device in accordance with one embodiment. As shown in FIG. 5, the risk determining apparatus 500 includes: an event feature acquiring unit 510 configured to acquire an event feature of a service request event; and a personal feature obtaining unit 520 configured to acquire at least one user involved in the service request event. a user personal feature; the relationship feature obtaining unit 530 is configured to determine a relationship feature of the at least one user based on a crowd relationship map of a specific group, wherein the specific group includes the at least one user; and the risk determining unit 540 is configured to The event feature, the user profile of the at least one user, and the relationship feature of the at least one user determine a risk probability of the service request event.

In one embodiment, the event feature acquired by the event feature acquiring unit 510 includes at least one of the following: a request for a business amount, a service registration time, an event occurrence time, a time difference between a service registration time and an event occurrence time, and an event occurrence location.

According to one embodiment, at least one user involved in the service request event includes a requestor of the service request event, and a beneficiary of the service request.

In one embodiment, the personal characteristics of the user acquired by the personal feature acquisition unit 520 include one or more of the following: a user basic attribute feature, a user behavior feature, and a user location feature.

According to an embodiment, the relationship feature obtaining unit 530 includes: a crowd obtaining module 531 configured to acquire a specific crowd including the at least one user; and a map acquiring module 532 configured to acquire a crowd relationship map of the specific crowd; The obtaining module 533 is configured to determine a relationship feature of the at least one user based on the crowd relationship map.

In an embodiment, the crowd obtaining module 531 is configured to determine, in a plurality of pre-divided subsets of users, a subset of users to which the at least one user belongs, and use the subset of users as the specific group.

In another embodiment, the crowd acquisition module 531 is configured to add the at least one user to a pre-selected set of users, the set of users being the particular group of people.

Further, in an embodiment, the map acquisition module 532 is configured to: acquire a first relationship map constructed for the pre-selected user set; and acquire the at least one user and the user in the pre-selected user set An association relationship is added to the first relationship map as a crowd relationship map of the specific group of people.

According to one embodiment, a population relationship map for a particular population is established based on one or more of the following relationships: transaction relationships, device relationships, funding relationships, social relationships.

In an embodiment, the relationship feature obtaining unit 530 is configured to: convert the relationship map into a vector factor by using a node-vector network structure feature extraction algorithm, and determine a relationship feature vector of the at least one user based on the vector factor .

In one embodiment, the risk determination unit 540 is configured to determine a risk probability of the service request event using a pre-trained evaluation model that is trained based on a gradient boost decision tree algorithm.

Through the above device, the event characteristics, the user's personal characteristics and the user relationship characteristics of a service request event are integrated, and the risk probability of the service request event is comprehensively evaluated, thereby controlling the business execution risk more efficiently and accurately.

According to another embodiment, there is also provided a computer readable storage medium having stored thereon a computer program for causing a computer to perform the method described in connection with FIG. 2 when the computer program is executed in a computer.

According to still another embodiment, there is also provided a computing device comprising a memory and a processor, the memory storing executable code, and when the processor executes the executable code, implementing the method described in connection with FIG. 2 method.

Those skilled in the art will appreciate that in one or more examples described above, the functions described herein can be implemented in hardware, software, firmware, or any combination thereof. When implemented in software, the functions may be stored in a computer readable medium or transmitted as one or more instructions or code on a computer readable medium.

The specific embodiments of the present invention have been described in detail with reference to the preferred embodiments of the present invention. The scope of the protection, any modifications, equivalent substitutions, improvements, etc., which are made on the basis of the technical solutions of the present invention, are included in the scope of the present invention.

Claims

A method of determining a risk probability of a business request event, comprising:

Obtain the event characteristics of the business request event;

Obtaining a user personal characteristic of at least one user involved in the service request event;

Determining a relationship characteristic of the at least one user based on a crowd relationship map of a specific group, wherein the specific group includes the at least one user;

Determining a risk probability of the service request event according to the event feature, the user personal characteristic of the at least one user, and the relationship feature of the at least one user.
The method of claim 1, wherein the event characteristic comprises at least one of: a request for a business amount, a service registration time, an event occurrence time, a time difference between a service registration time and an event occurrence time, and an event occurrence location.
The method of claim 1 wherein said at least one user comprises a requestor of said business request event and a beneficiary of a business request.
The method of claim 1 wherein said user personal characteristics comprise one or more of the following: user basic attribute characteristics, user behavior characteristics, user location characteristics.
The method of claim 1, wherein determining the relationship feature vector of the at least one user based on a population relationship map of a specific population comprises:

Obtaining the specific crowd of the at least one user;

Obtaining a population relationship map of the specific population;

Determining a relationship characteristic of the at least one user based on the crowd relationship map.
The method of claim 5, wherein the obtaining the specific crowd comprising the at least one user comprises, in a plurality of pre-divided subsets of users, determining a subset of users to which the at least one user belongs, the user The subset serves as the specific population mentioned above.
The method of claim 5 wherein obtaining the particular population comprising the at least one user comprises adding the at least one user to a pre-selected set of users, the set of users being the particular population.
The method of claim 7 wherein obtaining a population relationship map for said particular population comprises:

Acquiring a first relationship map constructed for the pre-selected set of users;

Obtaining an association relationship between the at least one user and a user in the pre-selected user set;

Adding the association relationship to the first relationship map as a crowd relationship map of the specific group of people.
The method of claim 1 wherein the population relationship map for the particular population is established based on one or more of the following relationships: transaction relationships, device relationships, financial relationships, social relationships.
The method of claim 1, wherein determining the relationship characteristic of the at least one user comprises using a node-vector network structure feature extraction algorithm to convert the relationship map into a vector factor, the at least determining the at least one based on the vector factor A relationship vector of a user.
The method of claim 1 wherein determining the risk probability of the service request event comprises determining a risk probability of the service request event using a pre-trained evaluation model, the evaluation model being trained based on a gradient boost decision tree algorithm.
An apparatus for determining a risk probability of a service request event, comprising:

An event feature obtaining unit configured to acquire an event feature of the service request event;

a personal feature obtaining unit configured to acquire a user personal feature of at least one user involved in the service request event;

a relationship feature acquiring unit, configured to determine a relationship feature of the at least one user based on a crowd relationship map of a specific group, wherein the specific group includes the at least one user;

The risk determining unit is configured to determine a risk probability of the service request event according to the event feature, the user personal feature of the at least one user, and the relationship feature of the at least one user.
The apparatus of claim 12, wherein the event characteristic comprises at least one of: a request for a business amount, a service registration time, an event occurrence time, a time difference between a service registration time and an event occurrence time, and an event occurrence location.
The apparatus of claim 12 wherein said at least one user comprises a requestor of said service request event and a beneficiary of a service request.
The apparatus of claim 12, wherein the user personal characteristics comprise one or more of the following: a user basic attribute feature, a user behavior feature, a user location feature.
The apparatus of claim 12, wherein the relationship feature acquisition unit comprises:

a crowd acquisition module configured to obtain the specific crowd including the at least one user;

a map acquisition module configured to acquire a population relationship map of the specific population;

And a feature acquiring module configured to determine a relationship feature of the at least one user based on the crowd relationship map.
The apparatus according to claim 16, wherein the crowd obtaining module is configured to determine, in a plurality of pre-divided subsets of users, a subset of users to which the at least one user belongs, the subset of users being the specific group of people .
The apparatus of claim 16, wherein the crowd acquisition module is configured to add the at least one user to a pre-selected set of users, the set of users being the particular group of people.
The apparatus of claim 18 wherein said map acquisition module is configured to:

Acquiring a first relationship map constructed for the pre-selected set of users;

Obtaining an association relationship between the at least one user and a user in the pre-selected user set;

Adding the association relationship to the first relationship map as a crowd relationship map of the specific group of people.
The apparatus of claim 12, wherein the population relationship map of the particular population is established based on one or more of the following relationships: a transaction relationship, a device relationship, a funding relationship, a social relationship.
The apparatus according to claim 12, wherein said relationship feature obtaining unit is configured to convert said relationship map into a vector factor using a node-vector network structure feature extraction algorithm, and determine said at least one user based on said vector factor Relational feature vector.
The apparatus of claim 12, wherein the risk determination unit is configured to determine a risk probability of the service request event using a pre-trained evaluation model, the evaluation model being trained based on a gradient boost decision tree algorithm.
A computer readable storage medium having stored thereon a computer program for causing a computer to perform the method of any of claims 1-11 when the computer program is executed in a computer.
A computing device, comprising a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, implementing the method of any one of claims 1-11 method.