CN111489098B

CN111489098B - Suspected risk business decision method, device and processing equipment

Info

Publication number: CN111489098B
Application number: CN202010305303.XA
Authority: CN
Inventors: 龚和; 赵云; 周悦; 张俊; 邵华杰; 张国开
Original assignee: Alipay Hangzhou Information Technology Co Ltd
Current assignee: Alipay Hangzhou Information Technology Co Ltd
Priority date: 2020-04-17
Filing date: 2020-04-17
Publication date: 2022-10-25
Anticipated expiration: 2040-04-17
Also published as: CN111489098A

Abstract

The present specification provides a suspected risk service decision method, a suspected risk service decision device, and a suspected risk service processing device, which are configured to extract key feature parameters of a suspected risk service request, match the extracted key feature parameters with a tag library constructed based on a manually-examined historical suspected risk service request, construct a matching tag set corresponding to the suspected risk service request according to a matched result, and determine a risk decision result of the suspected risk service request based on risk tags in the matching tag set. The tag library constructed based on the experience information abstracted from the manual auditing data is used for matching and making a decision on the new service request, so that the capability of making a semi-automatic decision on the new request based on the historical auditing case is realized, the workload of manual auditing is greatly reduced, and the auditing efficiency is improved.

Description

Suspected risk business decision method, device and processing equipment

Technical Field

The present disclosure relates to the field of computer technologies, and in particular, to a method and an apparatus for making a decision on suspected risk service, and a processing device.

Background

With the development of internet and computer technologies, the number of service types is continuously increasing, and how to ensure the security of services is more and more emphasized. Generally, after a service request is received, risk identification is performed on the service request, if it is identified that the service request has no risk, the service request is directly released, and if it is identified that the service request has a risk, a corresponding risk control policy is adopted, but some service requests may not determine whether a risk exists or not during risk identification, and such a service request may be referred to as a suspected risk service. Generally, for suspected risk services, professional auditors perform manual audits, a large amount of manpower is consumed, decision-making judgment cannot be performed on service requests quickly and effectively, and service flows need to be blocked and cannot meet requirements of real-time services.

Disclosure of Invention

Embodiments of the present specification aim to provide a method, an apparatus, and a processing device for making a decision on a suspected risk service, which improve the efficiency of making a decision on a suspected risk service.

In one aspect, an embodiment of the present specification provides a method for making a decision on suspected risk business, where the method includes:

acquiring key characteristic parameters of a received suspected risk service request;

matching the key characteristic parameters with risk labels in a label library to determine a matching label set corresponding to the suspected risk service request; the label library is constructed based on the manual management data of the historical suspected risk service requests, the label library comprises risk labels of all the historical suspected risk service requests determined according to the manual management result, and each risk label corresponds to summary information determined based on key characteristic parameters of the historical suspected risk service requests;

and determining a risk decision result of the suspected risk service request according to the risk label in the matching label set.

In another aspect, the present specification provides a suspected risk service decision device, including:

the characteristic parameter acquisition module is used for acquiring key characteristic parameters of the received suspected risk service request;

the label matching module is used for matching the key characteristic parameters with risk labels in a label library and determining a matching label set corresponding to the suspected risk service request; the label library is constructed based on the manual management data of the historical suspected risk service requests, the label library comprises risk labels of all the historical suspected risk service requests determined according to the manual management result, and each risk label corresponds to summary information determined based on key characteristic parameters of the historical suspected risk service requests;

and the risk decision module is used for determining a risk decision result of the suspected risk service request according to the risk label in the matching label set.

In a further aspect, an embodiment of the present specification provides a suspected risk service decision processing device, including at least one processor and a memory for storing processor-executable instructions, where the processor executes the instructions to implement the above suspected risk service decision method.

The suspected risk service decision method, the suspected risk service decision device and the suspected risk service processing equipment provided by the specification extract key feature parameters of a suspected risk service request, match the extracted key feature parameters with a tag library constructed based on a manually checked historical suspected risk service request, construct a matching tag set corresponding to the suspected risk service request according to the matched result, and determine a risk decision result of the suspected risk service request based on risk tags in the matching tag set. The tag library constructed based on the experience information abstracted from the manual auditing data is used for matching and making a decision on the new service request, so that the capability of making a semi-automatic decision on the new request based on the historical auditing case is realized, the workload of manual auditing is greatly reduced, and the auditing efficiency is improved. Especially for the risk business with less manual data, the training of the machine learning model can not be accurately carried out without a large amount of data. The method provided by the embodiment of the specification can be used for constructing the label library based on a small amount of manual audit data, has clear key characteristic parameter information and higher interpretability, and can meet the regulatory compliance requirements.

Drawings

In order to more clearly illustrate the embodiments of the present specification or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the description below are only some embodiments described in the present specification, and for those skilled in the art, other drawings may be obtained according to these drawings without creative efforts.

Fig. 1 is a schematic flowchart of an embodiment of a method for making a decision on suspected risk business provided in an embodiment of the present disclosure;

FIG. 2 is a schematic flow chart of a suspected risk business decision method in another embodiment of the present disclosure;

FIG. 3 is a block diagram of an embodiment of a suspected risk service decision device provided in the present specification;

fig. 4 is a block diagram of a hardware structure of a decision server of suspected risk service in one embodiment of the present specification.

Detailed Description

In order to make those skilled in the art better understand the technical solutions in the present specification, the technical solutions in the embodiments of the present specification will be clearly and completely described below with reference to the drawings in the embodiments of the present specification, and it is obvious that the described embodiments are only a part of the embodiments of the present specification, and not all of the embodiments. All other embodiments obtained by a person of ordinary skill in the art based on the embodiments in the present specification without making any creative effort shall fall within the protection scope of the present specification.

With the development of science and technology, the types and handling forms of services are more and more, and the management of the security of the services is more and more important. Some lawbreakers may use a computer network to perform illegal services, identify whether the services belong to the illegal services and have risks, and ensure that the services are safely performed, which is an important task of service security management. Risk identification for a business may not be able to determine whether the business is safe, and for such a business, which may be generally referred to as a suspected risk business, a manual review is required to determine whether a risk exists.

The method for deciding the suspected risk service provided by the specification can be used for intelligently identifying and deciding the suspected risk service, such as: can be applied to the risk identification process of the money laundering business. Some lawbreakers may utilize network transaction and other means to carry out money laundering so as to obtain legal income, and in the design of the anti-money laundering sanction system, for the request of an upstream business party, due to the reasons of duplicate names, fuzzy matching, errors and the like, many normal business requests are considered to be suspected to hit a sanction list. For these requests suspected of hitting the sanctioned list, manual audit intervention is often required. In the manual examination process, a large amount of manpower is consumed by professional anti-money laundering examiners to conduct manual examination, whether a service request really hits an anti-money laundering sanction list or not can not be judged quickly and effectively, and the request of an upstream service party needs to be blocked to wait for a manual decision result, so that the requirement of real-time service cannot be met.

Fig. 1 is a schematic flowchart of an embodiment of a method for making a decision on suspected risk business provided in an embodiment of the present disclosure. Although the present specification provides the method steps or apparatus structures as shown in the following examples or figures, more or less steps or modules may be included in the method or apparatus structures based on conventional or non-inventive efforts. In the case of steps or structures which do not logically have the necessary cause-and-effect relationship, the execution order of the steps or the module structure of the apparatus is not limited to the execution order or the module structure shown in the embodiment or the drawings of this specification. When the described method or module structure is applied to a device, a server or an end product in practice, the method or module structure may be executed sequentially or in parallel according to the embodiments or the method or module structure shown in the drawings (for example, in the environment of parallel processors or multi-thread processing, or even in the environment of distributed processing and server cluster).

In a specific embodiment of the method for deciding suspected risk service provided in this specification, as shown in fig. 1, the method may be applied to a client (e.g., a smart phone, a tablet computer, a vehicle-mounted device, an intelligent wearable device, etc.), a server, and other terminals, and the method may include the following steps:

and 102, acquiring key characteristic parameters of the received suspected risk service request.

In a specific implementation process, the suspected risk service request may represent a service request that may have a risk, and the service request may represent a request for performing service handling, such as: transaction requests, registration requests, login requests, and the like. When a service request is received by a service handling system or a network platform, risk identification can be performed on the service request firstly, such as: the risk prevention and control system performs risk identification on the service request or performs risk identification on the service request by using other methods, which is not specifically limited in the embodiments of the present specification. If the service request is determined to be risk-free, the service request is released, and if the service request is determined to be risk, a certain risk management and control strategy can be adopted, such as: reject requests, etc., there may be some service requests that may not be sure that there is a certain risk or that there is no certain risk, such as: many normal service requests may be considered to be at risk due to renaming, fuzzy matching, errors, and the like, and such service requests requiring further risk review may be referred to as suspected risk service requests. The key characteristic parameters can represent characteristic parameters which can reflect whether the business is at risk or not in the risk identification business, and can be determined by an intelligent learning model based on historical risk business identification data or determined based on manual trial experience. The key feature parameters may include attribute information of both sides of the service request, such as: the parameters of the name, the certificate number, the birthday, the nationality, the address, the account name, etc. of the two parties requesting the service may be included, and other characteristic parameters capable of identifying the risk of the service request may also be included according to the actual use requirement, which is not limited in this specification.

After receiving a suspected risk service request, the embodiments of the present specification may obtain key characteristic parameters of the suspected risk service request, such as: if the business request is a transaction request, parameters of names, certificate numbers, birthdays, nationalities, addresses, account names and the like of both transaction parties can be obtained and used as key characteristic parameters of the suspected risk business request.

In addition, in some embodiments of the present specification, the key feature parameters may include entry information in a suspected risk service request and matching record information that the suspected risk service request matches in a risk sanction list.

In a specific implementation process, the risk identification of the service request is usually first matched with a risk sanction list, that is, parameters of the service request such as: the name, the account name and the like are matched with the information in the risk sanction list, if the matching degree is greater than a certain threshold value, the service request can be considered to be risky, if the matching degree is smaller than the certain threshold value, the service request can be considered to be not risky, and the service request with the middle matching degree can be considered to be a suspected risk service request. The risk sanction list may be constructed based on historical risk identification data, which may include information on lists of users who are certain to be at risk, such as: personal information of users at risk such as: the name, the identification number, the account name, etc. may also include other information, and the embodiments of this specification are not particularly limited. For example: in risk identification for anti-money laundering business, business requests can be matched with an anti-money laundering sanctioning list, wherein the anti-money laundering sanctioning list can be marked by a specific international organization or national authority to make a "mark" for an individual, an entity, an activity or a country, and financial institutions or organizations within the authority must pay special attention to targets in the sanctioning list in daily business, such as finding objects involved in business and transaction are related to the targets in the sanctioning list, and must terminate the business and transaction and report to a regulatory body in time.

The key feature parameters in the embodiments of the present specification may include two parts; one is the entry information in the suspected risk service request, that is, the characteristic parameters of the suspected risk service request are as follows: the other is matching record information of the suspected risk service request matched with the risk sanction list, and the matching record information can be understood as the content matched between the service request and the risk sanction list, and the matching content can be complete matching or partial matching. For example: if the name of the user in the suspected risk service request is "zhang san", and one risk user in the risk sanfeng list is "zhang san feng", zhang san may be referred to as the entry information of the key feature parameter of the suspected risk service request, and "zhang san feng" may be referred to as the matching record information of the key feature parameter. Each key feature parameter may correspond to a parameter entry information and a matching record information, and if a certain key feature parameter is not matched with any information in the risk sanction list, the matching record information of the key feature parameter may be set to be null. The key characteristic parameter is constructed through the combination of the entry information and the matching record information, the entry information and the matching information respectively represent the attributes of the request and the risk list during subsequent risk identification, the entry information in the request and the matching information matched in the risk sanction list are comprehensively considered, and the accuracy of service risk identification is improved.

Step 104, matching the key characteristic parameters with risk labels in a label library to determine a matching label set corresponding to the suspected risk service request; the label library is constructed based on manual auditing data of historical suspected risk service requests, the label library comprises risk labels of the historical suspected risk service requests determined according to auditing conclusions of manual auditing, and each risk label corresponds to summary information determined based on key characteristic parameters of the historical suspected risk service requests.

In a specific implementation process, in some embodiments of the present specification, a tag library may be constructed in advance according to manual audit data of a historical suspected risk service request, where the tag library may include summary information determined based on key feature parameters of the historical suspected risk service request, and the summary information may represent summary information of risk attributes of the historical suspected risk service request. The key feature parameters of the historical suspected risk service request have the same meanings as those of the suspected risk service request described in the above embodiments, and are not described herein again. The tag library may further include risk tags of each historical suspected risk service request determined according to the trial result of manual trial, such as: historical suspected risk service requests of different audition conclusions can be set to different risk labels according to the manual audition conclusion, such as: white marks indicate no risk and black marks indicate risk. The label library can be understood as abstraction of a manual examination task conclusion of a historical suspected risk service request, represents abstract information of the manual examination task conclusion of each anti-money laundering sanctioning in history, and can be automatically generated based on the manual examination conclusion after each manual examination.

When a new suspected risk business request is received, key feature parameters corresponding to the suspected risk business request can be obtained, the obtained key feature parameters are matched with the tag library, a matching tag set corresponding to the suspected risk business request is determined, and the matching tag set can comprise a matched risk tag and summary information corresponding to the risk tag. Such as: the key characteristic parameters corresponding to the suspected risk service request can be matched with the summary information corresponding to each risk label in the label library, the summary information is determined based on the key characteristic parameters of the historical suspected risk service request, the same method can be adopted to calculate the summary information corresponding to the key characteristic parameters corresponding to the suspected risk service request, the calculated result is matched with the summary information of each risk label in the label library, and if the matching is successful, the risk label and the corresponding summary information are added into the matching label set.

And 106, determining a risk decision result of the suspected risk service request according to the risk label in the matching label set.

In a specific implementation process, after determining a matching tag set corresponding to a suspected risk service request, a risk decision result of a currently received suspected risk service request may be determined according to risk tags in the matching tag set, where the risk decision result includes: and if the conclusion of the risk labels in the matched label set is consistent (all the labels are white labels or all the labels are black labels), the label decision is considered to be successful, if all the labels are white labels, no risk can be released, if all the labels are black labels, the number of the white labels in the risk rejection is considered to be greater than the number of the black labels, the risk decision result of the currently received suspected risk service request can be considered to be no risk, and the risk decision result can be released. Or if the conclusion of the risk labels in the matched label set is consistent (all the white labels or all the black labels), the label decision is considered to be successful, if all the white labels are white labels, no risk is considered to be released, if all the black labels are black labels, the risk is considered to be rejected, if the conclusion of the labels is not consistent, the label decision is considered to be failed, and manual approval confirmation is required.

For example: the user submits a transaction request on a certain network platform, and the network platform sends the transaction request to the anti-money laundering sanctioning system to judge whether the transaction request has money laundering risks. The anti-money laundering sanctioning system matches the transaction request with the anti-money laundering sanctioning list, finds that some characteristics in the transaction are matched with the anti-money laundering sanctioning list, and does not determine whether money laundering risks exist. At this time, the transaction may be referred to as a suspected risk business request, and key characteristic parameters of the transaction request may be acquired, such as: requesting the name, certificate number, birthday, nationality, address and other parameters of both parties. And matching the acquired key characteristic parameters with a pre-constructed label library, if the key characteristic parameters can be matched with summary information corresponding to risk labels in the label library, assuming that the number of the matched key characteristic parameters is 3, and determining a risk decision result of a suspected risk service request based on the 3 risk labels which are successfully matched. Such as: if the 3 risk labels are white labels, the label decision is successful and no risk exists, and the label decision can be released; if 2 of the 3 risk labels are white labels and one is a black label, the label decision is considered to fail and needs to be manually checked and managed. Of course, there may be other decision-making ways to implement the embodiments of the present disclosure without specific limitations.

The suspected risk business decision method provided in the embodiment of the present specification extracts key feature parameters of a suspected risk business request, matches the extracted key feature parameters with a tag library constructed based on a historical suspected risk business request that is manually checked, constructs a matching tag set corresponding to the suspected risk business request according to a matched result, and determines a risk decision result of the suspected risk business request based on risk tags in the matching tag set. And extracting key characteristic parameters from the manual management data based on the historical suspected risk service request, so that the experience information of the manual management of the historical suspected risk service request is abstracted, and a tag library is constructed. And then, the new service request is matched and decided based on the labels, so that the capability of semi-automatically deciding the new request based on the historical auditing case is realized, the workload of manual auditing is greatly reduced, and the auditing efficiency is improved. Especially for the risk business with less manual auditing data, a large amount of data is not available, and the training of a machine learning model cannot be accurately carried out. The method provided by the embodiment of the specification can be used for constructing the label library based on a small amount of manual audit data, has clear key characteristic parameter information and higher interpretability, and can meet the regulatory compliance requirements.

On the basis of the above embodiments, in some embodiments of the present specification, the summary information of the risk label in the label library is obtained by performing hash calculation on the concatenated data of the key characteristic parameters of the historical suspected risk service request;

the matching the key feature parameters with risk tags in a tag library includes:

performing hash calculation on key characteristic parameters of the suspected risk service request to determine request summary information corresponding to the suspected risk service request;

and matching the request summary information with summary information corresponding to each risk label in the label library, wherein if the summary information is the same as the summary information corresponding to at least one risk label in the label library, the matching is successful.

In a specific implementation process, when a tag library is constructed, key characteristic parameters of historical suspected risk service requests can be spliced to obtain a spliced character string, and hash calculation is performed on spliced data, such as: the Murmur Hash algorithm (a non-encryption type Hash function) can be adopted to perform Hash calculation on the spliced key characteristic parameters, and the summary information corresponding to each historical suspected risk service request is determined. After receiving the suspected risk service request and acquiring the key feature parameters corresponding to the suspected risk service request, the key feature parameters of the acquired suspected risk service request may be spliced, and the same hash function is adopted as follows: and performing hash calculation on the spliced characters by using a MurmurHash algorithm to obtain request summary information corresponding to the suspected risk service request. And matching the request summary information with summary information corresponding to each risk label in the label library, if the request summary information is the same as the summary information content of at least one risk label in the label library, considering that the matching is successful, and adding the successfully matched risk label and the corresponding summary information into a matching label set.

In the embodiment of the description, the hash algorithm is used for performing hash calculation on the key characteristic parameters of the historical suspected risk service request and the newly received key characteristic parameters, and the summary information calculated based on the hash of the key characteristic parameters is accurately matched, so that accurate decision can be made even under the condition of few real cases. Meanwhile, the key characteristic parameter information is clear, has higher interpretability, and can meet the regulatory compliance requirement.

On the basis of the above embodiments, in some embodiments of the present specification, the tag library includes three tag types: full parameter label, address label, name label;

the hash calculation of the key characteristic parameters of the suspected risk service request to determine the request summary information corresponding to the suspected risk service request includes:

splicing all key characteristic parameters, address key characteristic parameters and name key characteristic parameters in the suspected risk service request respectively to obtain full-parameter splicing parameters, address splicing parameters and name splicing parameters corresponding to the suspected risk service request;

and respectively performing hash calculation on the full-parameter splicing parameter, the address splicing parameter and the name splicing parameter to respectively determine three request summary information corresponding to the suspected risk service request.

In a specific implementation process, in some embodiments of the present description, 3 types of tags, including a full-parameter tag, an address tag, and a name tag, are set according to attributes of key feature parameters when a tag library is constructed. The summary information of the full-parameter tag may be determined based on all key feature parameters in the historical suspected risk service request, such as: and splicing or carrying out hash calculation on all the characteristic parameters. The summary information of the address tag may be determined based on address key characteristic parameters in the historical suspected risky service request, such as: the address key feature parameters related to the address in the key feature parameters can be subjected to hash calculation after splicing. The summary information of the name tag is determined based on the name key feature parameters in the historical suspected risk service request, such as: the name key feature parameters related to the name in the key feature parameters can be subjected to hash calculation after splicing. A historical suspected risk service request may correspond to 3 summary information, and certainly if there is no address-related key feature parameter in the key feature parameters of a certain historical suspected risk service request, the address tag of the historical suspected risk service request may be null. Of course, any one or more of the 3 types of risk tags may be selected and combined according to actual needs, and the embodiments of the present specification are not particularly limited.

After a suspected risk service request is received and the key feature parameters of the suspected risk service request are obtained, the address key feature parameters and the name key feature parameters can be obtained according to the attributes of the key feature parameters, all the key feature parameters, the address key feature parameters and the name key feature parameters corresponding to the suspected risk service request are spliced respectively, and the full-parameter splicing parameters, the address splicing parameters and the name splicing parameters corresponding to the suspected risk service request are obtained. And carrying out Hash calculation on the full-parameter splicing parameter, the address splicing parameter and the name splicing parameter corresponding to the suspected risk service request by the sub-table to obtain three request summary information corresponding to the suspected risk service request. And matching the summary information of the 3 kinds of requests with summary information corresponding to each risk label in a label library to determine a matching label set corresponding to the received suspected risk service request. Risk tags in the tag library can be stored respectively according to tag types, and when the tags are matched, abstract information of the same tag type can be matched, such as: matching the full parameter labels corresponding to the suspected risk service request with the full parameter labels in the label library, matching the address labels corresponding to the suspected risk service request with the address labels in the label library, and matching the name labels corresponding to the suspected risk service request with the name labels in the label library.

In the embodiment of the specification, three different types of risk labels are designed, and key characteristic parameters in the risk labels are extracted from the manual management data of the historical suspected risk service request, so that the experience information of the historical suspected risk service request for manual management is abstracted; and then, the new service request is matched and decided based on the labels, so that the capability of semi-automatically deciding the new request based on the historical auditing case is realized, the workload of manual auditing is greatly reduced, and the auditing efficiency is improved. In addition, the three types of risk labels represent the attributes of three dimensions of the risk service respectively, the full-parameter label can represent the risk attribute of the service request comprehensively, but the required data volume is large, the requirement is more strict, the matching can be successful only if all the parameters are matched, and the phenomenon that the matching is empty can be caused. The address label and the name label require smaller data size, can represent certain service attributes, and can realize quick matching calculation.

Based on the foregoing embodiments, in some embodiments of the present specification, the method further includes filtering risk tags in the matching tag set according to a preset rule, where the preset rule includes at least one of:

selecting risk labels generated or modified within a reserved credible time range according to the generation or modification time of the risk labels in the label library;

and reserving the same risk label as the service type of the suspected risk service request and/or the corresponding user.

In a specific implementation process, after a matching tag set corresponding to a suspected risk service request is determined, risk tags in the matching tag set may be filtered by using a certain rule, for example: the label generated or modified within the trusted time range can be selectively set according to the generation or modification time of the risk label, wherein the trusted time range can be set according to actual needs, and the embodiment of the present specification is not specifically limited. And/or only keeping the same risk label as the service type and the user of the suspected risk service request. The auditing scales and auditing rules of the risk identification of the business request may be different at different times, and the filtering of the risk label is performed based on the generation or modification time of the risk label, so that the timeliness and the accuracy of the matched risk label are ensured. The auditing scale and the auditing rule of the same type of service request are similar, the reference value of the risk auditing data of the same user to the auditing of the subsequent service request is higher, the label filtering is carried out based on the service type and the user, the matched label can be more accurately found, and the accuracy of the risk decision result is improved.

On the basis of the foregoing embodiments, in some embodiments of the present specification, the matching the key feature parameter with a risk tag in a tag library to determine a matching tag set corresponding to the suspected risk service request includes:

selecting a matching rule according to the service type of the suspected risk service request, wherein the matching rule comprises a matching label type;

and selecting request summary information corresponding to the matching label type from the request summary information corresponding to the suspected risk service request according to the matching rule, matching the selected request summary information with summary information corresponding to the label type in the label library, and determining at least one matching label set.

In a specific implementation process, when there are multiple types of tags in the tag library, a matching rule may be selected according to the service type of the suspected risk service request, where the matching rule may include a matching tag type. Namely, one or more of the full parameter label, the address label and the name label can be selected to be matched with the summary information according to the service type of the suspected risk service request. Some service requests may have fewer or no address key feature parameters or name key feature parameters, and then a matching full parameter tag may be selected. And selecting request summary information corresponding to the matching tags in the matching rules from the request summary information corresponding to the suspected risk service request according to the matching rules, matching the selected request summary information with summary information corresponding to the tag types in the tag library, and determining at least one matching tag set. For example: if the matching label type is determined to be a full-parameter label in the matching rule, the request summary information of the suspected risk service request calculated based on all key characteristic parameters can be selected to be matched with the summary information corresponding to the full-parameter label in the label library, and the corresponding matching label set is determined.

Certainly, the matching tag type in the matching rule may be one or multiple, and specifically, according to whether the service type of the service request is applicable, the matching tag type may be a full-parameter tag by default, and if the key feature parameter corresponding to the service type of the service request is applicable to matching of the address tag and the name tag, the matching tag type may be set to 3 types. When there are multiple matching label types in the matching rule, there are multiple corresponding matching label sets.

Through the matching rule, the label type suitable for the suspected risk service request is selected for label matching, and the accuracy of the matching result can be improved.

On the basis of the foregoing embodiments, in some embodiments of the present specification, the determining a risk decision result of the suspected risk service request according to the risk label in the matching label set may include:

if the number of the matched label sets is one, determining a risk decision result of the suspected risk service request according to the risk type of the risk label in the matched label set;

if the number of the matching label sets is more than one, obtaining a risk decision result determined by each matching label set according to the risk type of the risk label in each matching label set, and comprehensively determining the risk decision result of the suspected risk service request according to the risk decision result determined by each matching label set.

In a specific implementation process, if the matching tag type in the matching rule is one, a matching tag set is correspondingly obtained, and a risk decision result of a suspected risk service request can be determined according to the risk type of a risk tag in the matching tag set, for example: if the matching tag sets have consistent results, the decision is considered to be successful, and the consistent results are used as decision results, and if the matching tag sets have inconsistent results, the decision failure is considered to be confirmed by manual examination, or other methods are used to determine risk decision results, which is not specifically limited in the embodiments of the present specification. If the matching label types in the matching rules are multiple, and multiple matching label sets are correspondingly obtained, multiple risk decision results of the suspected risk service request can be determined according to the risk types of the risk labels in the matching label sets. And integrating a plurality of risk decision results to determine a final risk decision result of the suspected risk service request.

For example: if the matching tag types in the matching rule are 2, namely, full-parameter tags and address tags, request summary information obtained by all key feature parameters in the suspected risk service request can be matched with summary information corresponding to the full-parameter tags in the tag library to obtain a matching tag set, and then the request summary information obtained by the address key feature parameters in the suspected risk service request is matched with the summary information corresponding to the address tags in the tag library to obtain a matching tag set. Determining two risk decision results by two matching label sets respectively, and then determining a final risk decision result by combining the two risk decision results, such as: if the two risk decision results are the same, determining that the final risk decision result of the suspected risk service request is the risk decision result determined by the two matching label sets; and if the two risk decision results are different, determining that the label decision of the suspected risk service request is invalid, and performing other risk decision processing.

And respectively performing label matching decision according to the label types, and then integrating the risk decision results corresponding to the label types to determine the final risk decision result so as to realize risk identification of the suspected risk service request from different dimensions.

In some embodiments of this specification, the determining a risk decision result of the suspected risk service request according to the tag in the matching tag set includes:

if the number of the tags in the matching tag set is empty or the risk types of the risk tags in the matching tag set are different, determining that the tag decision fails;

otherwise, determining that the label decision is successful, acquiring the risk type of the risk label in the matched label set, if the risk type of the risk label is safe, determining that the risk decision result is release, and if the risk type of the risk label is risk, determining that the risk decision result is risk control.

In a specific implementation process, after a matching tag set of a suspected risk service request is determined, if the number of tags in the set is null, that is, the summary information of none of the risk tags matches with the key feature parameters of the suspected risk service request, the tag decision may be considered to be failed. Or, if the risk types of the risk labels in the matching label set are different, that is, the risk labels in the risk label set have white labels and also have black labels, the label decision may be considered to fail. For the case of label decision failure, the risk decision result of the suspected risk service request cannot be determined, and further examination is required. In other cases, the tag decision may be considered to be successful, the risk type of the risk tag in the matching tag set is obtained, if the risk type of the risk tag is safe (e.g., white label), the risk decision result is determined to be released, and if the risk type of the risk tag is risk (e.g., black label), the risk decision result is determined to be risk management and control, for example: and rejecting the suspected risk service request, or performing right limitation on the suspected risk service request, and the like. The risk type of the risk label can be determined based on a manual audit conclusion of the historical suspected risk service request corresponding to the risk label, and if the manual audit conclusion is risk-free, the risk type is safe, and if the manual audit conclusion is risk-free, the risk type is risk. When the tags in the tag library have multiple tag types, the method may be used to determine a risk identification result corresponding to a matching tag set determined by a certain tag type in the above embodiment, and if there are multiple matching tag sets, the above steps may be repeated to determine risk decision results corresponding to the multiple matching tag sets, and then the multiple risk decision results are considered comprehensively to determine a final risk decision result, which is not specifically limited in the embodiments of the present specification.

For example: a certain transaction is confirmed as a suspected risk business request, and key characteristic parameters of the transaction request can be acquired as follows: requesting the name, certificate number, birthday, nationality, address and other parameters of both parties. And matching the acquired key characteristic parameters with a pre-constructed tag library, if the key characteristic parameters can be matched with summary information corresponding to risk tags in the tag library, assuming that the number of the matched key characteristic parameters is 3, and determining a risk decision result of the suspected risk service request based on the 3 risk tags which are successfully matched. Such as: if 2 of the 3 risk labels are white labels and one is black label, namely the risk types of the labels are different, the label decision is considered to be failed, manual examination is needed to confirm the decision result, and if the three risk labels are white labels, the risk decision result of the currently received suspected risk service request is determined to be risk-free and can be released. And if the three risk labels are black labels, determining that the risk decision result of the currently received suspected risk service request is risky and needing risk management and control. Whether the label decision is effective or not is determined by the risk types of the risk labels in the matched label set, the label decision is determined to be effective only when the risk types of the risk labels in the set are the same, and the risk decision result of the current suspected risk service request is further determined based on the risk types of the risk labels in the set, so that the purpose of quickly and accurately performing risk identification decision on the suspected risk service request is achieved.

On the basis of the above embodiments, in some embodiments of the present specification, the method further includes:

if the label decision fails, performing manual examination and management on the suspected risk service request, and reserving an examination and management conclusion corresponding to the manual examination and management;

and updating the label library according to the examination conclusion corresponding to the suspected risk service request.

In a specific implementation process, when a risk decision fails to be performed on a received suspected risk service request based on a risk label in a matching label set, the following steps are performed: and if the matching label set is an empty set or the risk types of the risk labels in the matching label set are different, and the like, the received suspected risk service request can be manually audited, the auditing conclusion corresponding to the manual auditing is reserved, and the label library is updated according to the auditing conclusion of the manual auditing. After the risk decision-making based on the tag library fails, the suspected risk service request can be further subjected to risk check by adopting manual examination, so that the accuracy of the risk decision-making is improved, meanwhile, the tag library is updated based on the examination conclusion of the manual examination, so that the tag library is continuously expanded, a pre-training process is not needed, the generation efficiency of the tag is greatly improved, and the risk decision-making efficiency of the suspected risk service request is improved.

On the basis of the foregoing embodiments, in some embodiments of the present specification, the updating the tag library according to the audit conclusion corresponding to the suspected risk service request includes:

if the suspected risk business request is subjected to first manual examination, creating a new risk label in an activated state according to key characteristic parameters of the suspected risk business request and an examination result corresponding to the suspected risk business request, and storing the risk label into a label library;

if the suspected risk business request is not manually checked for the first time, setting a history label corresponding to the suspected risk business request to be in an inactive state, creating a new risk label in an active state according to the key characteristic parameters of the suspected risk business request and the checking conclusion corresponding to the suspected risk business request, and labeling the risk label.

In a specific implementation process, after the label decision of the suspected risk service request fails and the received suspected risk service request is manually checked, the label library can be updated according to the manual checking result of the suspected risk service request. And if the suspected risk service request is the first manual examination, creating a new risk label in an activated state according to the key characteristic parameters of the suspected risk service request and the examination conclusion corresponding to the suspected risk service request, and storing the risk label into a label library. Namely, if the suspected risk business request is the first manual examination, the key feature parameters of the suspected risk business request can be obtained, the key feature parameters of the corresponding types are respectively extracted according to the types of the labels in the label library for splicing and hash calculation, the summary information corresponding to the suspected risk business request is determined, and meanwhile, the risk type of the risk label is determined based on the examination conclusion of the manual examination, such as: if the suspected risk business request is determined to be risk-free through manual management, the risk label can be determined to be a white label. And creating a risk label in an activated state in the label library, and associating the determined risk type and the calculated summary information of different label types on the created risk label. If the suspected risk service request is not the first manual examination (for example, the examination is performed again after the first manual examination is completed), the previously created tag may be set to the inactive state, that is, the historical tag corresponding to the suspected risk service request is set to the inactive state, and a new risk tag in the active state is created according to the set tag type. The process of creating a new risk label may refer to the process of creating a risk label by first manual review, which is not described herein again.

In the embodiment of the specification, for the request which is not successfully decided by the label, the label is created or updated again after the manual examination and decision, so that the number of the label library is continuously increased, and the follow-up more requests are given a chance to be successfully decided in real time. And under the condition that few labels exist, the method can also make real-time accurate decision on part of suspected risk service requests, and has high accuracy.

Fig. 2 is a schematic flow chart of a suspected risk service decision method in another embodiment of the present specification, as shown in fig. 2, in an example of the present specification, a suspected risk decision is performed by using a request of a suspected hit reverse money laundering sanction list as a suspected risk service request, and a decision process for suspected risk service in the embodiment of the present specification is specifically described below with reference to fig. 2:

1. key feature parameter extraction

The key characteristic parameters commonly used for manual anti-money laundering trial can be extracted from request parameters of suspected risk business requests by referring to manual trial experience, and the key characteristic parameters can comprise the names, certificate numbers, birthdays, nationality, addresses and other parameters of the business request party and the counter-party.

For each key feature parameter, 2 parts of contents can be respectively extracted and combined together to form a complete feature parameter content:

1) The participation content in the request of the suspected hit anti-money laundering sanctioning list is the participation information recorded in the embodiment;

2) And corresponding to the record content in the matched suspected hit sanctioned list, namely the matching record information recorded in the above embodiment.

2. Label library

The label library can be abstract of the manual examination task conclusion of the historical anti-money laundering sanctioning, represents abstract information of the manual examination task conclusion of each anti-money laundering sanctioning in history, and can be automatically generated based on the manual examination conclusion after each manual examination.

The types of the risk labels can be divided into 3 types, including full parameter labels, address labels and name labels (the full parameter labels are enabled by default, and the address labels and the name labels can be selected according to business needs). For each label, all key characteristic parameter contents related to the type label are spliced into a character string, and a 32-bit hash value of the character string is calculated based on a MurmurHash algorithm and is used as summary information of the risk label.

a) Full ginseng label

The risk label generated based on all key characteristic parameter information concerned during the manual examination of the anti-money laundering sanctioner comprises all key characteristic parameters which need to be referred to during the manual examination of the anti-money laundering sanctioner.

b) Address label:

and the label is generated based on address information in the key characteristic parameters concerned during the manual examination of the money laundering operation, and comprises all the key characteristic parameters related to the address, which need to be referred to during the manual examination of the money laundering operation.

c) Name tag:

the label is generated based on name information in the key characteristic parameters concerned during the manual examination of the money laundering algorithm, and comprises all the key characteristic parameters related to the name, which need to be referred to during the manual examination of the money laundering algorithm.

Meanwhile, according to different examination conclusions (a true hit sanction list and a wrong hit sanction list) of the manual examination task, the risk types of each risk label are generated, and decision conclusions which can be supported subsequently by the risk labels with different risk types are also different. If the sanction list is truly hit, the generated label is called as a black label and only can support the conclusion of rejecting the request; if an error hits the sanctioned list, the generated tag is called white-marked and can only support the conclusion of a release request.

3) Matching labels;

after extracting key characteristic parameters for a request suspected of hitting a sanctioned list, the key characteristic parameters contained in the request can be spliced into a character string according to several kinds of key characteristic parameter information pre-specified by three types of labels respectively in the same way as when the labels are generated, and then a 32-bit hash value of the character string is calculated based on a MurmURHash algorithm to serve as a summary of the request. If the summary content is the same as the summary information for the corresponding tag type in the tag library, the request is considered to match this type of tag.

Since multiple requests may occur for the same user and the key feature parameters in the requests may be the same, multiple risk labels with the same abstract are often matched in practice.

4) Label filtering

Filtering all matched risk labels, such as: only tags of the same type in the activated state may be retained to determine a matching set of tags corresponding to different types of tags. Meanwhile, the label generated or modified within a credible time range can be reserved, and the risk label of the same service type and the same user as the suspected-hit reverse money laundering sanctioning list is reserved.

After label filtering, all risk labels obtained are considered as valid labels.

5) Tag decision of success or failure

If no valid tag is obtained, the tag is considered to be unable to obtain a valid conclusion, and the tag decision fails; if the effective label contains white marks and black marks at the same time, the decision results of different labels are considered to be contradictory, and the label decision fails.

The other situations are regarded as that the label decision is successful, if the effective labels are all white labels at the moment, the decision result is that the sanction list is hit by mistake, and the request needs to be released; if the effective labels are black labels at the moment, the decision result is that the sanction list is truly hit, and the request needs to be rejected.

6) Manual trial decision making

For a request that a tag decision fails, a manual trial decision needs to be made. In the manual trial and error decision, the key characteristic parameters of the client and the parameters in the sanction list can be compared, and the decision result of the manual trial and error can be obtained. If the manual decision result is that the error hits the sanction list, the request needs to be released; if the decision result is a true hit on the sanctioned name, the request is rejected.

7) Maintaining label library based on manual trial conclusion

For the request which is subjected to manual trial and decision, the content of the label library is maintained according to a manual trial and decision conclusion. If the request is the first manual examination, a new label in an activated state is created according to the set label type; if the request is not the first manual examination (for example, the examination is conducted again after the first task examination is completed), the previously created label needs to be set in an inactive state, and a new label in an active state is created according to the set label type.

The suspected risk service decision method provided by the embodiment of the specification can realize semi-real-time risk decision on a suspected risk service request, three different types of labels are designed based on the manual auditing experience of historical suspected risk service, and key characteristic parameters in the labels are respectively extracted to abstract the historical manual auditing experience information; and then, for each suspected risk service request, extracting key characteristic parameters in the suspected risk service request and matching the key characteristic parameters with the label to perform summary information, so that the suspected risk service request has the capability of automatically making a decision on a new request based on a historical audit case. The semi-automatic decision making method can realize semi-automatic accurate decision making under the condition of less manual auditing cases, greatly reduces workload of manual auditing, improves auditing efficiency, reduces probability of service blocking, and meets requirements of large service volume. For the request which can be successfully subjected to the tag decision, a decision result can be obtained in real time according to historical manual trial and error experience; for the requests which are not successfully decided by the label, the labels are re-created or updated after the manual examination and the decision, so that the number of the label library is continuously increased, and the real-time decision success for more subsequent requests is provided. And under the condition that few labels exist, the method can also carry out real-time accurate decision on the requests which are partially suspected to hit the sanctioning list, and has high accuracy. Meanwhile, the key characteristic parameter selection and decision mechanism related to the whole label decision are clear and describable, the feasibility is high, and the interpretability is high.

In the present specification, each embodiment of the method is described in a progressive manner, and the same and similar parts among the embodiments are referred to each other, and each embodiment focuses on the differences from other embodiments. The relevant points can be obtained by referring to the partial description of the method embodiment.

Based on the suspected risk business decision method, one or more embodiments of the present specification further provide a system for making a decision on suspected risk business. The system may include systems (including distributed systems), software (applications), modules, components, servers, clients, etc. that use the methods described in embodiments of the present specification in conjunction with any necessary hardware-implemented devices. Based on the same innovative concept, the embodiments of the present specification provide one or more embodiments with devices as described in the following embodiments. Since the implementation scheme of the apparatus for solving the problem is similar to that of the method, reference may be made to the implementation of the foregoing method for the specific apparatus in the embodiment of the present specification, and repeated descriptions are omitted. As used hereinafter, the term "unit" or "module" may be a combination of software and/or hardware that implements a predetermined function. Although the means described in the embodiments below are preferably implemented in software, an implementation in hardware, or a combination of software and hardware is also possible and contemplated.

Specifically, fig. 3 is a schematic block structure diagram of an embodiment of a suspected risk service decision device provided in this specification, and as shown in fig. 3, the suspected risk service decision device provided in this specification may include: a characteristic parameter obtaining module 31, a label matching module 32, and a risk decision module 33, wherein:

a characteristic parameter obtaining module 31, configured to obtain a key characteristic parameter of the received suspected risk service request;

the tag matching module 32 is configured to match the key feature parameters with risk tags in a tag library, and determine a matching tag set corresponding to the suspected risk service request; the label library is constructed based on manual auditing data of historical suspected risk service requests, the label library comprises risk labels of the historical suspected risk service requests determined according to auditing conclusions of manual auditing, and each risk label corresponds to summary information determined based on key characteristic parameters of the historical suspected risk service requests;

and a risk decision module 33, configured to determine a risk decision result of the suspected risk service request according to the risk label in the matching label set.

The suspected risk service decision device provided in the embodiments of the present specification extracts key feature parameters of a suspected risk service request, matches the extracted key feature parameters with a tag library constructed based on a manually-examined historical suspected risk service request, constructs a matching tag set corresponding to the suspected risk service request according to a matching result, and determines a risk decision result of the suspected risk service request based on risk tags in the matching tag set. The tag library constructed based on the experience information abstracted from the manual auditing data is used for matching and making a decision on the new service request, so that the capability of making a semi-automatic decision on the new request based on the historical auditing case is realized, the workload of manual auditing is greatly reduced, and the auditing efficiency is improved. Especially for the risk business with less manual data, the training of the machine learning model can not be accurately carried out without a large amount of data. The method provided by the embodiment of the specification can be used for constructing the tag library based on a small amount of manual auditing data, has clear key characteristic parameter information and higher interpretability, and can meet the regulatory compliance requirement.

the tag matching module is specifically configured to:

In the embodiment of the specification, the hash algorithm is used for performing hash calculation on the key characteristic parameters of the historical suspected risk service request and the newly received key characteristic parameters, and the summary information calculated based on the hash of the key characteristic parameters is accurately matched, so that accurate decision can be made even under the condition of few real cases. Meanwhile, the key characteristic parameter information is clear, has higher interpretability, and can meet the regulatory compliance requirement.

the tag matching module is specifically configured to:

In the embodiment of the specification, three different types of risk labels are designed, and key characteristic parameters are extracted from the manual auditing data of the historical suspected risk service request, so that the experience information of the manual auditing of the historical suspected risk service request is abstracted; and then, the new service request is matched and decided based on the labels, so that the capability of semi-automatically deciding the new request based on the historical auditing case is realized, the workload of manual auditing is greatly reduced, and the auditing efficiency is improved. In addition, the three types of risk labels represent the attributes of three dimensions of the risk service respectively, the full-parameter label can represent the risk attribute of the service request comprehensively, but the required data volume is large, the requirement is more strict, the matching can be successful only if all the parameters are matched, and the phenomenon that the matching is empty can be caused. The address label and the name label require smaller data volume, can represent certain service attributes, and can realize quick matching calculation.

On the basis of the above embodiments, in some embodiments of the present specification, the apparatus further includes a tag filtering module, configured to:

filtering risk labels in the matching label set according to a preset rule, wherein the preset rule comprises at least one of the following rules:

In the embodiment of the specification, the auditing scales and the auditing rules of the risk identification of the service request at different time may be different, and the filtering of the tags is performed based on the generation or modification time of the risk tags, so that the timeliness and the accuracy of the matched risk tags are ensured. The auditing scale and the auditing rule of the same type of service request are similar, the reference value of the risk auditing data of the same user to the auditing of the subsequent service request is higher, the label filtering is carried out based on the service type and the user, the matched label can be more accurately found, and the accuracy of the risk decision result is improved.

On the basis of the foregoing embodiments, in some embodiments of the present specification, the tag matching module is specifically configured to:

and selecting request summary information corresponding to the matching label type from the request summary information corresponding to the suspected risk service request according to the matching rule, matching the selected request summary information with the summary information corresponding to the label type in the label library, and determining at least one matching label set.

In the embodiment of the specification, the same type of risk label can be characterized in relatively similar meaning,

On the basis of the foregoing embodiments, in some embodiments of the present specification, the risk decision module is specifically configured to:

In the embodiment of the specification, the label matching decision is respectively performed according to the label types, and then the risk decision results corresponding to the label types are integrated to determine the final risk decision result, so that risk identification is performed on the suspected risk service request from different dimensions.

In the embodiment of the description, whether the tag decision is valid or not is determined by matching the risk types of the risk tags in the tag set, the tag decision is determined to be valid only when the risk types of the risk tags in the set are the same, and the risk decision result of the current suspected risk service request is further determined based on the risk types of the risk tags in the set, so that the purpose of quickly and accurately performing the risk identification decision on the suspected risk service request is achieved.

On the basis of the foregoing embodiments, in some embodiments of the present specification, the apparatus further includes a manual auditing module, configured to:

when the label decision fails, carrying out manual examination and management on the suspected risk service request, and reserving an examination and management conclusion corresponding to the manual examination and management;

and updating the label library according to the examination and management conclusion corresponding to the suspected risk service request.

In the embodiment of the specification, after a risk decision-making based on the tag library fails, the suspected risk business request can be further subjected to risk check by adopting manual examination, so that the accuracy of the risk decision-making is improved, meanwhile, the tag library is updated based on the examination conclusion of the manual examination, so that the tag library is continuously expanded, a pre-training process is not needed, the generation efficiency of tags is greatly improved, and the risk decision-making efficiency of the suspected risk business request is improved.

On the basis of the foregoing embodiments, in some embodiments of this specification, the manual auditing module is specifically configured to:

if the suspected risk service request is the first manual examination, creating a new risk label in an activated state according to the key characteristic parameters of the suspected risk service request and the examination conclusion corresponding to the suspected risk service request, and storing the risk label into a label library;

On the basis of the foregoing embodiments, in some embodiments of the present specification, the key feature parameters extracted by the feature parameter obtaining module include entry information in a suspected risk service request and matching record information in a risk sanction list matched with the suspected risk service request.

In the embodiment of the specification, a key characteristic parameter is constructed through the combination of the parameter entering information and the matching record information, and the parameter entering information in the request and the matching information matched in the risk sanction list are comprehensively considered during subsequent risk identification, so that the accuracy of service risk identification is improved.

It should be noted that the system described above may also include other embodiments according to the description of the corresponding method embodiment. The specific implementation manner may refer to the description of the above corresponding method embodiment, and is not described in detail herein.

An embodiment of the present specification further provides a decision processing device for suspected risk service, including: at least one processor and a memory for storing processor-executable instructions, wherein the processor implements the information recommendation data processing method of the above embodiment when executing the instructions, such as:

matching the key characteristic parameters with risk labels in a label library to determine a matching label set corresponding to the suspected risk service request; the label library is constructed based on manual auditing data of historical suspected risk service requests, the label library comprises risk labels of the historical suspected risk service requests determined according to auditing conclusions of manual auditing, and each risk label corresponds to summary information determined based on key characteristic parameters of the historical suspected risk service requests;

It should be noted that the above description of the processing device according to the method embodiment may also include other implementations. The specific implementation manner may refer to the description of the related method embodiment, and is not described in detail herein.

The suspected risk business decision device provided by the present specification can also be applied to various data analysis processing systems. The system or server or terminal or processing device may be a single server, or may include a server cluster, a system (including a distributed system), software (applications), a practical operating device, a logic gate device, a quantum computer, etc. using one or more of the methods described herein or one or more embodiments of the system or server or terminal or processing device, in combination with necessary end devices implementing hardware. The detection system for collating difference data may comprise at least one processor and a memory storing computer executable instructions which when executed by the processor implement the steps of the method of any one or more of the embodiments described above.

The method embodiments provided in the embodiments of the present specification may be executed in a mobile terminal, a computer terminal, a server, or a similar computing device. Taking an example of the computer running on a server, fig. 4 is a block diagram of a hardware structure of a suspected risk service decision server in an embodiment of this specification, and the computer terminal may be the suspected risk service decision server or the suspected risk service decision device in the above embodiment. As shown in fig. 4, the server 10 may include one or more (only one shown) processors 100 (the processors 100 may include, but are not limited to, a processing device such as a microprocessor MCU or a programmable logic device FPGA, etc.), a memory 200 for storing data, and a transmission module 300 for communication functions. It will be understood by those skilled in the art that the structure shown in fig. 4 is only an illustration and is not intended to limit the structure of the electronic device. For example, the server 10 may also include more or fewer components than shown in FIG. 4, and may also include other processing hardware, such as a database or multi-level cache, a GPU, or have a different configuration than shown in FIG. 4, for example.

The memory 200 may be used to store software programs and modules of application software, such as program instructions/modules corresponding to the suspected risk service decision method in the embodiment of the present specification, and the processor 100 executes various functional applications and resource data updates by executing the software programs and modules stored in the memory 200. Memory 200 may include high speed random access memory and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some examples, memory 200 may further include memory located remotely from processor 100, which may be connected to a computer terminal through a network. Examples of such networks include, but are not limited to, the internet, intranets, office-to-network, mobile communication networks, and combinations thereof.

The transmission module 300 is used for receiving or transmitting data via a network. Specific examples of the network described above may include a wireless network provided by a communication provider of the computer terminal. In one example, the transmission module 300 includes a Network adapter (NIC) that can be connected to other Network devices through a base station so as to communicate with the internet. In one example, the transmission module 300 may be a Radio Frequency (RF) module, which is used for communicating with the internet in a wireless manner.

The foregoing description of specific embodiments has been presented for purposes of illustration and description. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims may be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing may also be possible or may be advantageous.

The method or apparatus provided in this specification and described in the foregoing embodiments may implement the service logic through a computer program and record the service logic on a storage medium, where the storage medium may be read and executed by a computer, and implement the effects of the solutions described in the embodiments of this specification, such as:

The storage medium may include a physical device for storing information, and typically, the information is digitized and stored using an electrical, magnetic, or optical media. The storage medium may include: devices that store information using electrical energy, such as various types of memory, e.g., RAM, ROM, etc.; devices that store information using magnetic energy, such as hard disks, floppy disks, tapes, core memories, bubble memories, and usb disks; devices that store information optically, such as CDs or DVDs. Of course, there are other ways of storing media that can be read, such as quantum memory, graphene memory, and so forth.

The method or apparatus for deciding the suspected risk service provided in the embodiment of the present disclosure may be implemented in a computer by a processor executing corresponding program instructions, for example, implemented in a PC end using a c + + language of a windows operating system, implemented in a linux system, or implemented in an intelligent terminal using android and iOS system programming languages, implemented in processing logic based on a quantum computer, or the like.

It should be noted that descriptions of the apparatus, the computer storage medium, and the system described above according to the related method embodiments may also include other embodiments, and specific implementations may refer to descriptions of corresponding method embodiments, which are not described in detail herein.

The embodiments in the present specification are described in a progressive manner, and the same and similar parts among the embodiments may be referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, for the hardware + program class embodiment, since it is substantially similar to the method embodiment, the description is simple, and the relevant points can be referred to only the partial description of the method embodiment.

The embodiments of the present description are not limited to what must be consistent with industry communications standards, standard computer resource data updating and data storage rules, or what is described in one or more embodiments of the present description. Certain industry standards, or implementations modified slightly from those described using custom modes or examples, may also achieve the same, equivalent, or similar, or other, contemplated implementations of the above-described examples. The embodiments using the modified or transformed data acquisition, storage, judgment, processing and the like can still fall within the scope of the alternative embodiments of the embodiments in this specification.

In the 90's of the 20 th century, improvements to a technology could clearly distinguish between improvements in hardware (e.g., improvements to circuit structures such as diodes, transistors, switches, etc.) and improvements in software (improvements to process flow). However, as technology advances, many of today's process flow improvements have been seen as direct improvements in hardware circuit architecture. Designers almost always obtain the corresponding hardware circuit structure by programming an improved method flow into the hardware circuit. Thus, it cannot be said that an improvement in the process flow cannot be realized by hardware physical modules. For example, a Programmable Logic Device (PLD), such as a Field Programmable Gate Array (FPGA), is an integrated circuit whose Logic functions are determined by programming the Device by a user. A digital system is "integrated" on a PLD by the designer's own programming without requiring the chip manufacturer to design and fabricate application-specific integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing an Integrated Circuit chip, such Programming is often implemented by "logic compiler" software, which is similar to a software compiler used in program development and writing, but the original code before compiling is also written by a specific Programming Language, which is called Hardware Description Language (HDL), and HDL is not only one but many, such as ABEL (Advanced Boolean Expression Language), AHDL (alternate Hardware Description Language), traffic, CUPL (core universal Programming Language), HDCal, jhddl (Java Hardware Description Language), lava, lola, HDL, PALASM, rhyd (Hardware Description Language), and vhigh-Language (Hardware Description Language), which is currently used in most popular applications. It will also be apparent to those skilled in the art that hardware circuitry that implements the logical method flows can be readily obtained by merely slightly programming the method flows into an integrated circuit using the hardware description languages described above.

The controller may be implemented in any suitable manner, for example, the controller may take the form of, for example, a microprocessor or processor and a computer readable medium that stores computer readable program code (e.g., software or firmware) executable by the (micro) processor, logic gates, switches, an Application Specific Integrated Circuit (ASIC), a programmable logic controller, and embedded microcontrollers, examples of which include, but are not limited to, the following microcontrollers: ARC 625D, atmel AT91SAM, microchip PIC18F26K20, and Silicone Labs C8051F320, the memory controller may also be implemented as part of the control logic for the memory. Those skilled in the art will also appreciate that, in addition to implementing the controller in purely computer readable program code means, the same functionality can be implemented by logically programming method steps such that the controller is in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers, embedded microcontrollers and the like. Such a controller may thus be regarded as a hardware component and the means for performing the various functions included therein may also be regarded as structures within the hardware component. Or even means for performing the functions may be regarded as being both a software module for performing the method and a structure within a hardware component.

The systems, devices, modules or units illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. One typical implementation device is a computer. In particular, the computer may be, for example, a personal computer, a laptop computer, a vehicle human interaction device, a cellular telephone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

Although one or more embodiments of the present description provide method operational steps as described in the embodiments or flowcharts, more or fewer operational steps may be included based on conventional or non-inventive approaches. The order of steps recited in the embodiments is merely one manner of performing the steps in a multitude of orders and does not represent the only order of execution. When the device or the end product in practice executes, it can execute sequentially or in parallel according to the method shown in the embodiment or the figures (for example, in the environment of parallel processors or multi-thread processing, even in the environment of distributed resource data update). 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, the presence of additional identical or equivalent elements in a process, method, article, or apparatus that comprises the recited elements is not excluded. The terms first, second, etc. are used to denote names, but not any particular order.

For convenience of description, the above devices are described as being divided into various modules by functions, and are described separately. Of course, when implementing one or more of the present description, the functions of each module may be implemented in one or more software and/or hardware, or the modules implementing the same functions may be implemented by a combination of a plurality of sub-modules or sub-units, etc. The above-described embodiments of the apparatus are merely illustrative, and for example, the division of the units is only one logical division, and other divisions may be realized in practice, for example, a plurality of units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.

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 flowchart illustrations and/or block diagrams, and combinations of flows and/or blocks in the flowchart illustrations 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 resource data updating apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable resource data updating 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 resource data update 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 resource data update 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.

In a typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.

The memory may include forms of volatile memory in a computer readable medium, random Access Memory (RAM) and/or non-volatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.

Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static Random Access Memory (SRAM), dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), read Only Memory (ROM), electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage, graphene storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.

As will be appreciated by one skilled in the art, one or more embodiments of the present description may be provided as a method, system, or computer program product. Accordingly, one or more embodiments of the present description may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, one or more embodiments of the present description 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 so forth) having computer-usable program code embodied therein.

One or more embodiments of the present description may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. One or more embodiments of the present specification can also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.

The embodiments in the present specification are described in a progressive manner, and the same and similar parts among the embodiments may be referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, for system embodiments, since they are substantially similar to method embodiments, the description is relatively simple, and the relevant points can be referred to only part of the description of the method embodiments. In the description of the specification, reference to the description of the term "one embodiment," "some embodiments," "an example," "a specific example," or "some examples," etc., means that a particular feature, structure, material, or characteristic described in connection with the embodiment or example is included in at least one embodiment or example of the specification. In this specification, the schematic representations of the terms used above are not necessarily intended to refer to the same embodiment or example. Furthermore, the particular features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples. Moreover, various embodiments or examples and features of various embodiments or examples described in this specification can be combined and combined by one skilled in the art without being mutually inconsistent.

The above description is merely exemplary of one or more embodiments of the present disclosure and is not intended to limit the scope of one or more embodiments of the present disclosure. Various modifications and alterations to one or more embodiments described herein will be apparent to those skilled in the art. Any modification, equivalent replacement, improvement or the like made within the spirit and principle of the present specification should be included in the scope of the claims.

Claims

1. A method for making a decision for suspected risk business, the method comprising:

matching the key characteristic parameters with risk labels in a label library to determine a matching label set corresponding to the suspected risk service request; the label library is constructed based on manual auditing data of historical suspected risk service requests, the label library comprises risk labels of the historical suspected risk service requests determined according to auditing conclusions of manual auditing, and each risk label corresponds to summary information determined based on key characteristic parameters of the historical suspected risk service requests; the tag library includes three tag types: the system comprises full parameter labels, address labels and name labels, wherein summary information corresponding to each risk label is determined based on key characteristic parameters corresponding to label types in the historical suspected risk service request;

2. The method of claim 1, wherein the summary information of the risk label in the label library is obtained by performing a hash calculation on the concatenated data of the key characteristic parameters of the historical suspected risk service request;

3. The method according to claim 2, wherein the performing a hash calculation on the key feature parameter of the suspected risk service request to determine the request summary information corresponding to the suspected risk service request includes:

4. The method of claim 1, further comprising filtering risk tags in the set of matching tags according to preset rules, wherein the preset rules include at least one of:

5. The method of claim 3, wherein the matching the key feature parameter with the risk tag in the tag library to determine the matching tag set corresponding to the suspected risk service request comprises:

6. The method of claim 5, wherein determining a risk decision result for the suspected risk business request according to the risk label in the matching label set comprises:

if the number of the matched label sets is one, determining a risk decision result of the suspected risk service request according to the risk types of the risk labels in the matched label sets;

7. The method of claim 1, wherein the determining a risk decision result of the suspected risk service request according to the tags in the matching tag set comprises:

otherwise, determining that the label decision is successful, acquiring the risk type of the risk label in the matched label set, if the risk type of the risk label is safe, determining that the risk decision result is release, and if the risk type of the risk label is risk, determining that the risk decision result is risk management and control.

8. The method of claim 7, further comprising:

9. The method according to claim 8, wherein the updating the tag library according to the audit result corresponding to the suspected risk service request includes:

if the suspected risk service request is not the first manual examination, setting the historical label corresponding to the suspected risk service request to be in an inactive state, creating a new risk label in an active state according to the key characteristic parameters of the suspected risk service request and the examination conclusion corresponding to the suspected risk service request, and storing the risk label into a label library.

10. The method of claim 1, wherein the key feature parameters comprise entry information in suspected risk business requests and matching record information of the suspected risk business requests matching into a risk sanction list.

11. A suspected risk business decision-making apparatus, comprising:

the label matching module is used for matching the key characteristic parameters with risk labels in a label library and determining a matching label set corresponding to the suspected risk service request; the label library is constructed based on the manual management data of the historical suspected risk service requests, the label library comprises risk labels of all the historical suspected risk service requests determined according to the manual management result, and each risk label corresponds to summary information determined based on key characteristic parameters of the historical suspected risk service requests; the tag library includes three tag types: the system comprises full parameter labels, address labels and name labels, wherein summary information corresponding to each risk label is determined based on key characteristic parameters corresponding to label types in the historical suspected risk service request;

12. The apparatus according to claim 11, wherein the summary information of the risk label in the label library is obtained by performing hash calculation on the concatenated data of the key characteristic parameters of the historical suspected risk service request;

the tag matching module is specifically configured to:

13. The apparatus of claim 12, the tag matching module being specifically configured to:

and performing hash calculation on the full parameter splicing parameter, the address splicing parameter and the name splicing parameter respectively, and determining three request summary information corresponding to the suspected risk service request respectively.

14. The apparatus of claim 11, further comprising a tag filtering module to:

filtering risk labels in the matching label set according to preset rules, wherein the preset rules comprise at least one of the following:

15. The apparatus of claim 13, the tag matching module is specifically configured to:

16. The apparatus of claim 15, the risk decision module is specifically configured to:

17. The apparatus of claim 11, the risk decision module specifically configured to:

18. The apparatus of claim 17, further comprising a manual auditing module to:

when the label decision fails, carrying out manual examination on the suspected risk service request, and reserving an examination conclusion corresponding to the manual examination;

19. The apparatus of claim 18, the manual audit module to:

if the suspected risk business request is not manually checked for the first time, setting the history label corresponding to the suspected risk business request to be in an inactive state, creating a new risk label in an active state according to the key characteristic parameters of the suspected risk business request and the checking conclusion corresponding to the suspected risk business request, and storing the risk label into a label library.

20. The apparatus of claim 11, wherein the key feature parameters extracted by the feature parameter obtaining module include entry information in a suspected risk service request and matching record information of the suspected risk service request matching into a risk sanction list.

21. A decision processing device for suspected risk traffic, comprising: at least one processor and a memory for storing processor-executable instructions, the processor implementing the method of any one of claims 1-10 when executing the instructions.