A data risk prevention and control method, device and equipment

Abstract

The embodiment of the specification discloses a data risk prevention and control method, device and equipment, the method is applied to terminal equipment, comprising: obtaining service data generated in the process of user executing target service; determining whether the service data meets the data screening rule; if not, the service data is sent to the server for risk detection to determine the risk detection result of the service data; if yes, the service data is provided to the risk detection model, the risk detection model is used for risk detection on the service data, and a corresponding second risk detection result is obtained, if the second risk detection result matches the risk result determined through the data screening rule, the risk detection result of the service data is determined, if the second risk detection result does not match the risk result determined through the data screening rule, the service data is sent to the server for risk detection to determine the risk detection result of the service data.

Description

Technical Field

[0001] This document relates to the field of computer technology, and in particular to a method, apparatus and equipment for data risk prevention and control. Background Technology

[0002] Traffic is a request, and it is the basis for communication between the client and the cloud. For risk control at the traffic granularity, as the control granularity becomes finer and the real-time control becomes stronger, traffic is the basis for communication between the client and the cloud. If the risk control time for each traffic is long, it will seriously affect the processing efficiency of the business. In addition, as the business deepens and the control becomes more and more in-depth, the requirements for the control effect are also getting higher and higher.

[0003] To mitigate traffic risks, asynchronous analysis on the terminal device side is typically employed. Specifically, this involves pre-analysis based on the characteristics of trigger points (the terminal devices at the business front end). However, this method requires advance calculations, resulting in poor accuracy of risk detection results. Alternatively, offline analysis via a server can be used; however, this approach cannot perform risk control processing in real-time or obtain relevant risk information immediately. Therefore, a technical solution is needed that provides risk control based on "service requests," offering greater flexibility, shortening access time, and improving risk coverage and detection efficiency. Summary of the Invention

[0004] The purpose of the embodiments in this specification is to provide a technical solution that can provide decision-making opportunities based on "service requests" for data risk prevention and control, which is more flexible, can shorten the access time for risk prevention and control, and improve risk coverage and risk detection efficiency.

[0005] To achieve the above technical solution, the embodiments in this specification are implemented as follows:

[0006] This specification provides a data risk control method applied to a terminal device. The method includes: acquiring business data generated during a user's execution of a target business; determining whether the business data meets the data filtering rules issued by a server; if not, sending the business data to the server for risk detection and receiving a first risk detection result from the server; and determining a risk detection result for the business data based on the first risk detection result; if yes, providing the business data to a risk detection model for risk detection to obtain a corresponding second risk detection result; if the second risk detection result matches the risk result determined by the data filtering rules, determining a risk detection result for the business data; if the second risk detection result does not match the risk result determined by the data filtering rules, sending the business data to the server for risk detection and receiving a third risk detection result from the server; and determining a risk detection result for the business data based on the third risk detection result.

[0007] This specification provides a data risk control method applied to a server. The method includes: receiving business data generated during a user's execution of a target business process from a terminal device. The business data is data that the terminal device obtains and, based on data filtering rules issued by the server, determines whether the business data meets the data filtering rules. If the business data does not meet the data filtering rules, the data is sent. Alternatively, if the terminal device determines that the business data meets the data filtering rules, it provides the business data to a first risk detection model, performs risk detection on the business data through the first risk detection model, obtains a corresponding second risk detection result, and the second risk detection result does not match the risk result determined by the data filtering rules, the data is sent. The business data is input into the second risk detection model to obtain the corresponding risk detection result. The obtained risk detection result is sent to the terminal device to trigger the terminal device to determine the risk detection result of the business data based on the received risk detection result.

[0008] This specification provides a data risk control device, comprising: a data acquisition module for acquiring business data generated during the business process; a filtering module for issuing data filtering rules and determining whether the business data meets the data filtering rules; a first risk module for sending the business data to a server for risk detection and receiving a first risk detection result from the server, and determining a risk detection result for the business data based on the first risk detection result; and a second risk module for providing the business data to a risk detection model if the data meets the criteria, performing risk detection on the business data through the risk detection model to obtain a corresponding second risk detection result. If the second risk detection result matches the risk result determined by the data filtering rules, the risk detection result for the business data is determined; if the second risk detection result does not match the risk result determined by the data filtering rules, the business data is sent to the server for risk detection and a third risk detection result from the server is received, and the risk detection result for the business data is determined based on the third risk detection result.

[0009] This specification provides a data risk control device, comprising: a data receiving module, which receives business data generated during a user's execution of a target business process, sent by a terminal device. The business data is data sent when the terminal device, after acquiring the business data, determines whether the business data meets the data filtering rules issued by a server, and if so, if it does not meet the data filtering rules. Alternatively, the business data is data sent when the terminal device, after determining that the business data meets the data filtering rules, provides the business data to a first risk detection model, performs risk detection on the business data through the first risk detection model, obtains a corresponding second risk detection result, and the second risk detection result does not match the risk result determined by the data filtering rules. A risk detection module inputs the business data into the second risk detection model to obtain the corresponding risk detection result. A result sending module sends the obtained risk detection result to the terminal device to trigger the terminal device to determine the risk detection result of the business data based on the received risk detection result.

[0010] This specification provides an embodiment of a data risk control device, comprising: a processor; and a memory configured to store computer-executable instructions, wherein the executable instructions, when executed, cause the processor to: acquire business data generated during a user's execution of a target business; determine whether the business data meets the data filtering rules issued by a server; if not, send the business data to the server for risk detection and receive a first risk detection result from the server, and determine a risk detection result for the business data based on the first risk detection result; if yes, provide the business data to a risk detection model, perform risk detection on the business data through the risk detection model, obtain a corresponding second risk detection result; if the second risk detection result matches the risk result determined by the data filtering rules, determine a risk detection result for the business data; if the second risk detection result does not match the risk result determined by the data filtering rules, send the business data to the server for risk detection and receive a third risk detection result from the server, and determine a risk detection result for the business data based on the third risk detection result.

[0011] This specification provides an embodiment of a data risk control device, comprising: a processor; and a memory configured to store computer-executable instructions. When executed, the executable instructions cause the processor to: receive business data generated during a user's execution of a target service, sent by a terminal device. This business data is data sent when the terminal device, after acquiring the business data, determines whether the business data meets the data filtering rules issued by a server, and if so, if it does not. Alternatively, the business data is data sent when the terminal device, after determining that the business data meets the data filtering rules, provides the business data to a first risk detection model, performs risk detection on the business data through the first risk detection model, obtains a corresponding second risk detection result, and if the second risk detection result does not match the risk result determined by the data filtering rules. The device also inputs the business data into the second risk detection model to obtain the corresponding risk detection result. Finally, it sends the obtained risk detection result to the terminal device to trigger the terminal device to determine the risk detection result of the business data based on the received risk detection result.

[0012] This specification also provides a storage medium for storing computer-executable instructions. When executed by a processor, these instructions implement the following process: acquiring business data generated during a user's execution of a target business task; determining whether the business data meets the data filtering rules issued by a server; if not, sending the business data to the server for risk detection and receiving a first risk detection result from the server; and determining a risk detection result for the business data based on the first risk detection result; if yes, providing the business data to a risk detection model for risk detection to obtain a corresponding second risk detection result; if the second risk detection result matches the risk result determined by the data filtering rules, determining a risk detection result for the business data; if the second risk detection result does not match the risk result determined by the data filtering rules, sending the business data to the server for risk detection and receiving a third risk detection result from the server; and determining a risk detection result for the business data based on the third risk detection result.

[0013] This specification also provides a storage medium for storing computer-executable instructions. When executed by a processor, these instructions implement the following process: receiving service data generated during a user's execution of a target service, sent by a terminal device. This service data is data sent when the terminal device, after acquiring the service data, determines whether the service data meets the data filtering rules issued by a server, and if so, if it does not. Alternatively, the service data is data sent when the terminal device, after determining that the service data meets the data filtering rules, provides the service data to a first risk detection model, performs risk detection on the service data using the first risk detection model, obtains a corresponding second risk detection result, and if the second risk detection result does not match the risk result determined by the data filtering rules. The service data is then input into the second risk detection model to obtain the corresponding risk detection result. The obtained risk detection result is sent to the terminal device to trigger the terminal device to determine the risk detection result of the service data based on the received risk detection result. Attached Figure Description

[0014] To more clearly illustrate the technical solutions in the embodiments or prior art of this specification, the drawings used in the description of the embodiments or prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0015] Figure 1 This is an embodiment of a data risk control method described in this specification;

[0016] Figure 2 This is another example of a data risk control method described in this specification;

[0017] Figure 3 This is a schematic diagram illustrating a risk control process for data in this specification;

[0018] Figure 4 This is yet another embodiment of a data risk control method described in this specification;

[0019] Figure 5 This is an embodiment of a data risk control device described in this specification;

[0020] Figure 6 This is another embodiment of a risk control device for data in this specification;

[0021] Figure 7 This is an example of a data risk control device described in this specification. Detailed Implementation

[0022] This specification provides a method, apparatus, and equipment for data risk prevention and control.

[0023] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0024] Example 1

[0025] like Figure 1As shown in the embodiments of this specification, a data risk prevention and control method is provided. The subject of this method can be a terminal device, which can be a mobile phone, tablet computer, or computer equipment such as a laptop or desktop computer, or an IoT device (specifically, a smartwatch, in-vehicle device, etc.). The method specifically includes the following steps:

[0026] In step S102, business data generated during the user's execution of the target business is obtained.

[0027] In this embodiment, the user can be any user; however, it can be the user executing the target service. The target service can include various types, such as payment services, money transfer services, facial recognition services, shopping services, and interactive social services. In this embodiment, the target service can be a single service or multiple services; for example, it can include login services, identity authentication services, and payment services. The specific details can be set according to actual circumstances, and this embodiment does not limit this. The service data can include various types, such as user-related information, target service-related information, and user operation information during the execution of the target service. User-related information can include various types, such as user account information, user name, information on documents proving user identity, and user biometric data. The specific details can be set according to actual circumstances. Target service-related information can include various types, such as the target service identifier, the target service execution time, and the data obtained from executing the target service. The specific details can be set according to actual circumstances. User operation information during the execution of the target service includes various types, such as the sequence information of user operations during the execution of the target service, the identifier of user operations during the execution of the target service, and the trajectory of user operations during the execution of the target service. The specific details can be set according to actual circumstances, and this embodiment does not limit this.

[0028] In implementation, traffic is synonymous with requests, forming the foundation for communication between the client and the cloud. For risk management at the traffic granularity level, as the granularity of management becomes increasingly finer and the real-time requirements more stringent, traffic, being the basis for client-cloud communication, will severely impact business processing efficiency if the risk control time for each traffic request is lengthy. Furthermore, as business operations deepen and management becomes more sophisticated, the demands on management effectiveness also increase. To enable traffic risk control, asynchronous analysis on the terminal device side is typically employed. Specifically, this involves pre-analysis based on the characteristics of trigger points (the terminal devices at the business front end). Taking a shopping scenario as an example, RPC control at the shopping node requires triggering the terminal device's risk detection mechanism when a user enters the shopping process. When the shopping scenario's RPC is received, the corresponding detection results are directly brought back for analysis. However, this method requires pre-calculation, resulting in poor accuracy of the obtained risk detection results. Alternatively, offline analysis can be performed via a server. However, this method cannot perform risk control processing in real time, nor can it obtain relevant risk information in real time. Therefore, there is a need for a technical solution that can provide risk control based on "service requests," offering greater flexibility and shortening the access time for risk control, thereby improving risk coverage and detection efficiency. This specification provides an achievable processing method, which may specifically include the following:

[0029] When a user launches a specified application through their terminal device and performs a target service through that application, the terminal device can obtain business data generated during the execution of the target service. Specifically, it can identify the user and obtain relevant information such as the user's account information, biometric information, and information on documents that can prove the user's identity through that identifier. In addition, it can also obtain relevant information such as the identifier of the target service, the execution time of the target service, and the data obtained from executing the target service. Furthermore, it can also obtain the operation sequence information during the user's execution of the target service, etc., depending on the actual situation. The specific settings can be made according to the actual situation, and this specification does not limit this aspect.

[0030] In step S104, based on the data filtering rules issued by the server, it is determined whether the business data meets the data filtering rules.

[0031] The data filtering rules can include various types. For example, corresponding data filtering rules can be set in advance according to the needs of the target business. Specifically, based on the characteristics of the target business, business data containing one or more different keywords or statements often poses a fraud risk. Therefore, corresponding data filtering rules can be constructed based on the aforementioned keywords or statements to determine whether the business data poses a fraud risk. Alternatively, a whitelist of the target business can be set in advance according to the actual situation. This whitelist can record information on accounts that do not have a specified risk, or it can record characteristics that do not have a specified risk, etc. The specific rules can be set according to the actual situation, and this specification does not limit this aspect.

[0032] In implementation, for example, corresponding data filtering rules can be constructed based on specified keywords or phrases, and the server can distribute these data filtering rules to designated terminal devices. After obtaining business data, it can be checked whether the business data contains the specified keywords or phrases. If it does, the business data is determined to meet the data filtering rules, meaning the business data poses a risk. If it does not contain the specified keywords or phrases, the business data is determined not to meet the data filtering rules, meaning the business data does not pose a risk. The above is only one possible processing method. In practical applications, in addition to the above method, various other implementation methods can be included, which can be set according to the actual situation. This specification does not limit this aspect.

[0033] In step S106, if not, the above-mentioned business data is sent to the server for risk detection, and the server sends the first risk detection result of the business data. Based on the first risk detection result, the risk detection result of the business data is determined.

[0034] The server can be a single server or a server cluster consisting of multiple servers. The server can be a backend server for the target business or a server used for risk control, etc. The specific configuration can be determined according to the actual situation, and this specification does not limit this.

[0035] In implementation, if it is determined that the business data does not meet the data filtering rules, the business data can be sent to the server. The server will then further verify whether the business data poses a risk. The server can be configured with a risk detection model. The server can input the business data into this risk detection model, analyze the data, and determine the first risk detection result. This first risk detection result can then be sent to the terminal device. The terminal device can then merge the first risk detection result with the result indicating that the business data does not meet the data filtering rules to obtain the final risk detection result for the business data.

[0036] In step S108, if so, the aforementioned business data is provided to the risk detection model, which performs risk detection on the business data to obtain a corresponding second risk detection result. If the second risk detection result matches the risk result determined by the data filtering rules, the risk detection result of the business data is determined. If the second risk detection result does not match the risk result determined by the data filtering rules, the business data is sent to the server for risk detection, and the server sends a third risk detection result for the business data. The risk detection result of the business data is determined based on the third risk detection result.

[0037] The risk detection model can be constructed using various algorithms. For example, it can be constructed using classification algorithms, such as decision tree algorithms, Bayesian algorithms, and KNN algorithms. Alternatively, it can be constructed using deep learning models, such as neural network models and multilayer perceptrons. The specific model can be set according to the actual situation, and the embodiments in this specification do not limit it.

[0038] In implementation, a specified algorithm can be obtained based on the actual situation. An initial risk detection model can be built using this algorithm, and historical data can be used as sample data to train the risk detection model, resulting in a trained model. If the business data is determined to meet the data filtering rules, it is provided to the risk detection model. The model performs risk detection on the business data, obtaining a corresponding second risk detection result. If the second risk detection result matches the risk result determined by the data filtering rules, the risk detection result for the business data is determined. For example, if the risk result determined by the data filtering rules indicates that the business data is at risk, and the second risk detection result also indicates that the business data is at risk, then the second risk detection result matches the risk result determined by the data filtering rules. Alternatively, if the risk result determined by the data filtering rules indicates that the business data is not at risk, and the second risk detection result also indicates that the business data is not at risk, then the second risk detection result matches the risk result determined by the data filtering rules. If the risk result determined by the data filtering rules indicates that the business data is at risk, and the second risk detection result indicates that the business data is not at risk, then the second risk detection result does not match the risk result determined by the data filtering rules. Alternatively, if the risk result determined by the data filtering rules indicates that the business data is not at risk, and the second risk detection result indicates that the business data is at risk, then the second risk detection result does not match the risk result determined by the data filtering rules. If the second risk detection result does not match the risk result determined by the data filtering rules, then the business data can be provided to the server for further risk detection. Specifically, the business data can be sent to the server for risk detection, and the server can send a third risk detection result for the business data. The risk detection result for the business data can be determined based on the third risk detection result.

[0039] This specification provides a data risk control method. It acquires business data generated during a user's execution of a target business process. Then, it determines whether the business data meets data filtering rules. If not, the business data is sent to a server for risk detection to determine the risk detection result. If yes, the business data is provided to a risk detection model, which performs risk detection on the business data to obtain a corresponding second risk detection result. If the second risk detection result matches the risk result determined by the data filtering rules, the risk detection result of the business data is determined. If the second risk detection result does not match the risk result determined by the data filtering rules, the business data is sent to the server for risk detection to determine the risk detection result of the business data. This proposes a decision-making timing based on "service requests," making data risk control processing more flexible, shortening the access time for risk control, and improving risk coverage and user experience. For example, in interactive social scenarios, previously risk control decisions could only be made at the end of the interactive game, during the payment verification process, affecting the efficiency and accuracy of risk control. This solution allows for risk control decisions during the game process.

[0040] Example 2

[0041] like Figure 2 As shown in the embodiments of this specification, a data risk prevention and control method is provided. The subject of this method can be a terminal device, which can be a mobile phone, tablet computer, or computer equipment such as a laptop or desktop computer, or an IoT device (specifically, a smartwatch, in-vehicle device, etc.). The method specifically includes the following steps:

[0042] In step S202, historical business data generated during the user's execution of the target business is obtained.

[0043] Historical business data can include user operation sequence data, and can also be data on Remote Procedure Call (RPC) traffic.

[0044] The specific processing of step S202 can be found in the above embodiment of the process of obtaining business data, and will not be repeated here.

[0045] In step S204, the risk detection model is trained based on historical business data to obtain the trained risk detection model. The risk detection model is used to detect risks in the business data generated during the user's execution of the target business.

[0046] The risk detection model can be a model constructed using a deep neural network model. This deep neural network model can include various types, such as convolutional neural network models, recurrent neural network models, deep belief network models, deep autoencoders, and generative adversarial networks, etc. The specific model can be set according to the actual situation, and this specification does not limit this specific choice in the embodiments.

[0047] In implementation, the corresponding algorithm can be obtained, and a risk detection model can be built based on the algorithm. The input data of the risk detection model can be the business data generated during the user's execution of the target business, and the output data can be the risk detection result corresponding to the input data. Then, training samples (i.e., historical business data generated during the user's execution of the target business) can be obtained for training the risk detection model. The risk detection model can be trained using the training samples. During the model training process, the objective function can be pre-defined, and the model parameters in the risk detection model can be optimized based on the objective function to finally obtain the trained risk detection model.

[0048] It should be noted that the training process of the above-mentioned risk detection model is carried out on the terminal device. In practical applications, the training process of the above-mentioned risk detection model can also be carried out on the server. The specific settings can be made according to the actual situation, and the embodiments in this specification do not limit this.

[0049] In step S206, business data generated during the user's execution of the target business is obtained.

[0050] The business data can include user operation sequence data, which can be data from Remote Procedure Call (RPC) traffic. RPC is a protocol that allows a program on a remote computer to request services over a network without needing to understand the underlying network technology. RPC protocols can exist through certain transport protocols, such as TCP or UDP, to carry information between communicating programs.

[0051] In step S208, based on the data filtering rules issued by the server, it is determined whether the above business data meets the data filtering rules.

[0052] The data filtering rules include one or more of the following: whitelist, blacklist, and graylist.

[0053] In implementation, taking a whitelist as an example of a data filtering rule, the server can send a whitelist to the terminal device. Then, it can be determined whether the above business data is whitelisted. If it is, the above business data is determined to meet the data filtering rule; if not, the above business data is determined not to meet the data filtering rule.

[0054] In step S210, if not, an entanglement identifier is constructed based on the risk results determined by the data filtering rules and the risk detection results of the risk detection model. The business data and the entanglement identifier are sent to the server for risk detection. The server sends the first risk detection result for the business data. The risk detection result of the business data is determined based on the first risk detection result.

[0055] The embedded identifier can be constructed in various ways. For example, taking a whitelist as an example, if the risk result determined by the data filtering rule is that there is a risk, then there is no need to perform risk detection through the risk detection model in the terminal device. In this case, the final embedded identifier can be "1 / -1", where "1" indicates that the risk result determined by the data filtering rule is that there is a risk, and "-1" indicates that the risk detection was not performed through the risk detection model in the terminal device.

[0056] In implementation, such as Figure 3 As shown, if it is determined that the above business data does not meet the data filtering rules (e.g., it is determined that the above business data does not belong to the whitelist), then it is not necessary to perform risk detection on the business data through the risk detection model in the terminal device. In this case, a corresponding embedded identifier "1 / -1" can be constructed, and the embedded identifier and the business data can be sent to the server for further risk detection. After receiving the data, the server can detect whether it contains an embedded identifier. If it does, the server can perform risk detection on the business data and obtain the corresponding risk detection result (i.e., the first risk detection result). Alternatively, the server can detect whether it contains an embedded identifier of a specified type. If it does, the server can perform risk detection on the business data and obtain the corresponding risk detection result (i.e., the first risk detection result). Then, the first risk detection result can be sent to the terminal device. The terminal device can comprehensively consider the first risk detection result and the risk result determined by the data filtering rules to finally obtain the risk detection result corresponding to the business data.

[0057] In step S212, if so, the business data is provided to the risk detection model, and the risk detection model performs risk detection on the business data to obtain the corresponding second risk detection result. If the second risk detection result matches the risk result determined by the data filtering rules, the risk detection result of the business data is determined. If the second risk detection result does not match the risk result determined by the data filtering rules, an enclosed identifier is constructed based on the risk result determined by the data filtering rules and the second risk detection result. The business data and the enclosed identifier are sent to the server for risk detection, and the third risk detection result of the business data sent by the server is received. The risk detection result of the business data is determined based on the third risk detection result.

[0058] In implementation, such as Figure 3 As shown, taking a whitelist as an example of data filtering rules, if the above business data is determined to belong to the whitelist, it needs to be provided to the local risk detection model for further risk detection. This means the business data can be input into the risk detection model, which will then perform risk detection to obtain the corresponding second risk detection result. If the above business data is determined to belong to the whitelist (i.e., the business data is not risky), and the second risk detection result indicates that the business data is not risky, then the second risk detection result matches the risk result determined by the data filtering rules. In this case, it can be determined that the business data is not risky, and the terminal device can continue to execute the user's target business processing. If the above business data is determined to belong to the whitelist (i.e., the business data is not risky), but the second risk detection result indicates that the business data is risky, then the second risk detection result does not match the risk result determined by the data filtering rules. In this case, it can be determined that the business data may be risky. The terminal device can construct an embedded identifier based on the risk result determined by the data filtering rules and the second risk detection result (i.e., the embedded identifier is "0 / 1"). This embedded identifier and the business data can then be sent to the server for further risk detection. After receiving data, the server can detect whether it contains any hidden identifiers. If so, it can perform risk detection on the business data and obtain the corresponding risk detection result (i.e., the third risk detection result). Alternatively, it can detect whether the received data contains any hidden identifiers of a specified type. If so, it can also perform risk detection on the business data and obtain the corresponding risk detection result (i.e., the third risk detection result). Then, the third risk detection result can be sent to the terminal device. The terminal device can comprehensively consider the second risk detection result, the third risk detection result, and the risk result determined by data filtering rules to finally obtain the risk detection result corresponding to the business data.

[0059] It should be noted that if the second risk detection result indicates that the business data cannot be detected by the risk detection model (i.e., the risk detection model's risk detection result for the business data is that the business data is of a new risk type), then it can be determined that the second risk detection result does not match the risk result determined by the data filtering rules. In this case, it can be determined that the business data may have a risk. The terminal device can construct an embedded identifier based on the risk result determined by the data filtering rules and the second risk detection result, i.e., the embedded identifier is "0 / -1". The embedded identifier and the business data can be sent to the server for further risk detection. After receiving the data, the server can detect whether it contains an embedded identifier. If it does, the server can perform risk detection on the business data and obtain the corresponding risk detection result (i.e., the third risk detection result). Alternatively, the server can detect whether it contains an embedded identifier of a specified type. If it does, the server can perform risk detection on the business data and obtain the corresponding risk detection result (i.e., the third risk detection result). Then, the third risk detection result can be sent to the terminal device. The terminal device can comprehensively consider the second risk detection result, the third risk detection result, and the risk result determined by the data filtering rules to finally obtain the risk detection result corresponding to the business data.

[0060] In step S214, if the business data includes data of the first risk type, an entanglement identifier is constructed, the business data and the entanglement identifier are sent to the server for risk detection, and the risk detection result of the business data sent by the server is received. The first risk type is a risk type not included in the current risk type.

[0061] In implementation, such as Figure 3 As shown, if the business data contains data of the first risk type, the whitelist and risk detection model in the terminal device will be unable to determine whether the business data is risky. In this case, an embedded identifier of "-1 / -1" can be constructed, and the embedded identifier and the business data can be sent to the server for further risk detection. After receiving the data, the server can detect whether it contains an embedded identifier. If it does, the server can perform risk detection on the business data and obtain the corresponding risk detection result. Alternatively, the server can detect whether it contains an embedded identifier of a specified type. If it does, the server can perform risk detection on the business data and obtain the corresponding risk detection result. Then, the server can send the risk detection result to the terminal device, which can then use the risk detection result to obtain the risk detection result corresponding to the business data.

[0062] This specification provides a data risk control method. It acquires business data generated during a user's execution of a target business process. Then, it determines whether the business data meets data filtering rules. If not, the business data is sent to a server for risk detection to determine the risk detection result. If yes, the business data is provided to a risk detection model, which performs risk detection on the business data to obtain a corresponding second risk detection result. If the second risk detection result matches the risk result determined by the data filtering rules, the risk detection result of the business data is determined. If the second risk detection result does not match the risk result determined by the data filtering rules, the business data is sent to the server for risk detection to determine the risk detection result of the business data. This proposes a decision-making timing based on "service requests," making data risk control processing more flexible, shortening the access time for risk control, and improving risk coverage and user experience. For example, in interactive social scenarios, previously risk control decisions could only be made at the end of the interactive game, during the payment verification process, affecting the efficiency and accuracy of risk control. This solution allows for risk control decisions during the game process.

[0063] In addition, the data sources for business risk control analysis can be increased by integrating terminal device behavior and gateway log data to improve risk coverage. For example, in shopping scenarios, previously only static profiles of devices or users and historical shopping information could be used to determine whether there was a risk. However, this solution can integrate abnormal gateway logs, terminal access logs, etc. to comprehensively determine whether there is a risk.

[0064] Example 3

[0065] like Figure 4 As shown in the embodiments of this specification, a data risk prevention and control method is provided. The execution subject of this method can be a server, which can be a single independent server or a server cluster composed of multiple servers. The server can be a backend server for financial or online shopping services, or a backend server for an application. The method specifically includes the following steps:

[0066] In step S402, the terminal device receives service data generated during the user's execution of the target service. This service data is data sent when the terminal device obtains the service data and determines whether the service data meets the data filtering rules issued by the server. Alternatively, the terminal device provides the service data to the first risk detection model when it determines that the service data meets the data filtering rules, performs risk detection on the service data through the first risk detection model, obtains the corresponding second risk detection result, and sends the data when the second risk detection result does not match the risk result determined by the data filtering rules.

[0067] In step S404, business data is input into the second risk detection model to obtain the corresponding risk detection results.

[0068] The second risk detection model can be constructed using various algorithms. For example, it can be constructed using classification algorithms, such as decision tree algorithms, Bayesian algorithms, and KNN algorithms. Alternatively, it can be constructed using deep learning models, such as neural network models and multilayer perceptrons. The specific model can be set according to the actual situation, and this specification does not limit the specific model.

[0069] In step S406, the obtained risk detection result is sent to the terminal device to trigger the terminal device to determine the risk detection result of the business data based on the received risk detection result.

[0070] The specific processing procedures for steps S402 to S406 can be found in the relevant content of the above embodiments, and will not be repeated here.

[0071] In practical applications, the above data filtering rules can be constructed in a variety of different ways. The following is an optional processing method, which may include the following steps A2 to A6.

[0072] In step A2, historical business data generated during the user's execution of the target business is obtained.

[0073] In step A4, the user model for data filtering rules is trained based on historical business data to obtain the trained user model for data filtering rules. The user model for data filtering rules is used to generate corresponding data filtering rules for terminal devices.

[0074] The user model for data filtering rules can be constructed using various algorithms. For example, it can be constructed using classification algorithms, or it can be constructed using neural network models, multilayer perceptrons, etc. The specific method can be set according to the actual situation, and the embodiments in this specification do not limit this.

[0075] In implementation, a corresponding algorithm can be obtained, and a data filtering rule user model can be constructed based on the algorithm. The input data of the data filtering rule user model can be the business data generated during the user's execution of the target business, and the output data can be the data filtering rule corresponding to the input data. Then, training samples (i.e., historical business data generated during the user's execution of the target business) can be obtained for training the data filtering rule user model. The training samples can be used to train the data filtering rule user model. During the model training process, an objective function can be pre-defined, and the model parameters in the data filtering rule user model can be optimized based on the objective function to finally obtain the trained data filtering rule user model.

[0076] In step A6, a data filtering rule matching the user is generated based on the trained data filtering rule user model, and the generated data filtering rule is sent to the user's terminal device.

[0077] In practical applications, the above-mentioned second risk detection model can be constructed in a variety of different ways. The following provides an optional processing method, which may include the processing of steps B2 and B4.

[0078] In step B2, historical business data generated during the user's execution of the target business is obtained.

[0079] In step B4, the second risk detection model is trained based on historical business data to obtain the trained second risk detection model. The second risk detection model is used to detect risks in business data generated during the user's execution of target business.

[0080] In implementation, a corresponding algorithm can be obtained, and a second risk detection model can be constructed based on the algorithm. The input data of the second risk detection model can be the business data generated during the user's execution of the target business, and the output data can be the risk detection result corresponding to the input data. Then, training samples (i.e., historical business data generated during the user's execution of the target business) can be obtained for training the second risk detection model. The training samples can be used to train the second risk detection model. During the model training process, an objective function can be pre-set, and the model parameters in the second risk detection model can be optimized based on the objective function to finally obtain the trained second risk detection model.

[0081] In practical applications, the above-mentioned second risk detection model can be constructed in a variety of different ways. The following provides an optional processing method, which may include the following steps C2 to C6.

[0082] In step C2, historical business data generated during the user's execution of the target business is obtained.

[0083] In step C4, the first risk detection model is trained based on historical business data to obtain the trained first risk detection model. The first risk detection model is used to detect risks in the business data generated during the user's execution of the target business.

[0084] The first risk detection model can be constructed using various algorithms. For example, it can be constructed using a classification algorithm, which may include decision tree algorithm, Bayesian algorithm, KNN algorithm, etc. It can also be constructed using a deep learning model, which may include neural network model, multilayer perceptron, etc. The specific model can be set according to the actual situation, and the embodiments in this specification do not limit it.

[0085] In implementation, a corresponding algorithm can be obtained, and a first risk detection model can be constructed based on the algorithm. The input data of the first risk detection model can be the business data generated during the user's execution of the target business, and the output data can be the risk detection result corresponding to the input data. Then, training samples (i.e., historical business data generated during the user's execution of the target business) can be obtained for training the first risk detection model. The first risk detection model can be trained using the training samples. During the model training process, an objective function can be pre-defined, and the model parameters in the first risk detection model can be optimized based on the objective function to finally obtain the trained first risk detection model.

[0086] In step C6, the trained first risk detection model is sent to the user's terminal device.

[0087] In addition, the user model of the above data screening rules, the first risk detection model and the second risk detection model can be updated by using business data of new risk types. For details, please refer to the processing of steps D2 to D6 below.

[0088] In step D2, when the preset period is reached, historical business data generated during the user's execution of the target business within the preset period is obtained.

[0089] In step D4, the historical business data generated within the preset period is detected based on the preset data detection strategy and / or user complaint information, and the corresponding detection results are obtained. The detection results indicate whether the historical business data generated within the preset period includes data of risk types other than the current risk type.

[0090] The data detection strategy can include various methods, such as specified keywords or statements, or specified fields, etc. The specific method can be set according to the actual situation, and the embodiments in this specification do not limit it.

[0091] In step D6, if the detection result indicates that the historical business data generated within the preset period includes data of risk types other than the current risk type, then the target model is updated based on the data of risk types other than the current risk type included in the historical business data generated within the preset period. The target model includes a data filtering rule user model, a first risk detection model, and a second risk detection model.

[0092] This specification provides a data risk control method. It acquires business data generated during a user's execution of a target business process. Then, it determines whether the business data meets data filtering rules. If not, the business data is sent to a server for risk detection to determine the risk detection result. If yes, the business data is provided to a risk detection model, which performs risk detection on the business data to obtain a corresponding second risk detection result. If the second risk detection result matches the risk result determined by the data filtering rules, the risk detection result of the business data is determined. If the second risk detection result does not match the risk result determined by the data filtering rules, the business data is sent to the server for risk detection to determine the risk detection result of the business data. This proposes a decision-making timing based on "service requests," making data risk control processing more flexible, shortening the access time for risk control, and improving risk coverage and user experience. For example, in interactive social scenarios, previously risk control decisions could only be made at the end of the interactive game, during the payment verification process, affecting the efficiency and accuracy of risk control. This solution allows for risk control decisions during the game process.

[0093] In addition, the data sources for business risk control analysis can be increased by integrating terminal device behavior and gateway log data to improve risk coverage. For example, in shopping scenarios, previously only static profiles of devices or users and historical shopping information could be used to determine whether there was a risk. However, this solution can integrate abnormal gateway logs, terminal access logs, etc. to comprehensively determine whether there is a risk.

[0094] Example 4

[0095] The above describes the data risk prevention and control method provided in the embodiments of this specification. Based on the same idea, the embodiments of this specification also provide a data risk prevention and control device, such as... Figure 5 As shown.

[0096] The risk control device for this data includes: a data acquisition module 501, a screening module 502, a first risk module 503, and a second risk module 504, wherein:

[0097] Data acquisition module 501: Business data generated during the bidding process;

[0098] The filtering module 502 issues data filtering rules and determines whether the business data meets the data filtering rules;

[0099] The first risk module 503 sends the business data to the server for risk detection, receives the first risk detection result of the business data sent by the server, and determines the risk detection result of the business data based on the first risk detection result.

[0100] If the second risk module 504 is used, it provides the business data to the risk detection model, performs risk detection on the business data through the risk detection model, and obtains a corresponding second risk detection result. If the second risk detection result matches the risk result determined by the data filtering rules, the risk detection result of the business data is determined. If the second risk detection result does not match the risk result determined by the data filtering rules, the business data is sent to the server for risk detection, and the server sends a third risk detection result for the business data. The risk detection result of the business data is determined based on the third risk detection result.

[0101] In the embodiments described in this specification, the device further includes:

[0102] The third risk module, if it detects that the business data includes data of the first risk type, sends the business data to the server for risk detection and receives the risk detection result of the business data sent by the server. The first risk type is a risk type not included in the current risk types.

[0103] In the embodiments described in this specification, the data filtering rules include one or more of a whitelist, a blacklist, and a graylist.

[0104] In this embodiment of the specification, the risk detection module constructs an embedded identifier based on the risk results determined by the data filtering rules and the risk detection results of the risk detection model; and sends the business data and the embedded identifier to the server for risk detection.

[0105] In the embodiments described in this specification, the business data includes user operation sequence data, which is data from Remote Procedure Call (RPC) traffic.

[0106] In the embodiments described in this specification, the risk detection model is a model constructed using a deep neural network model.

[0107] In the embodiments described in this specification, the device further includes:

[0108] The historical data acquisition module acquires historical business data generated during the user's execution of target business processes.

[0109] The training module trains the risk detection model based on the historical business data to obtain a trained risk detection model. The risk detection model is used to detect risks in business data generated during the user's execution of the target business.

[0110] This specification provides a data risk control device. It acquires business data generated during a user's execution of a target business process. Then, it determines whether the business data meets data filtering rules. If not, the business data is sent to a server for risk detection to determine the risk detection result. If yes, the business data is provided to a risk detection model, which performs risk detection on the business data to obtain a corresponding second risk detection result. If the second risk detection result matches the risk result determined by the data filtering rules, the risk detection result of the business data is determined. If the second risk detection result does not match the risk result determined by the data filtering rules, the business data is sent to the server for risk detection to determine the risk detection result of the business data. This proposes a decision-making timing based on "service requests," making data risk control processing more flexible, shortening the access time for risk control, and improving risk coverage and user experience. For example, in interactive social scenarios, previously risk control decisions could only be made at the end of the interactive game, during the payment verification process, affecting the efficiency and accuracy of risk control. This solution, however, allows for risk control decisions during the game process.

[0111] In addition, the data sources for business risk control analysis can be increased by integrating terminal device behavior and gateway log data to improve risk coverage. For example, in shopping scenarios, previously only static profiles of devices or users and historical shopping information could be used to determine whether there was a risk. However, this solution can integrate abnormal gateway logs, terminal access logs, etc. to comprehensively determine whether there is a risk.

[0112] Example 5

[0113] The above describes the data risk prevention and control method provided in the embodiments of this specification. Based on the same idea, the embodiments of this specification also provide a data risk prevention and control device, such as... Figure 6 As shown.

[0114] The risk control device for this data includes: a data receiving module 601, a risk detection module 602, and a result sending module 603, wherein:

[0115] The data receiving module 601 receives business data generated during the user's execution of a target business from the terminal device. The business data is data sent when the terminal device obtains the business data and determines whether the business data meets the data filtering rules based on the data filtering rules issued by the server, and when the business data does not meet the data filtering rules. Alternatively, the business data is data sent when the terminal device provides the business data to a first risk detection model after determining that the business data meets the data filtering rules, performs risk detection on the business data through the first risk detection model, obtains a corresponding second risk detection result, and the second risk detection result does not match the risk result determined by the data filtering rules.

[0116] The risk detection module 602 inputs the business data into the second risk detection model to obtain the corresponding risk detection results;

[0117] The result sending module 603 sends the obtained risk detection result to the terminal device to trigger the terminal device to determine the risk detection result of the business data based on the received risk detection result.

[0118] In the embodiments described in this specification, the device further includes:

[0119] The first historical data acquisition module acquires historical business data generated during the user's execution of the target business.

[0120] The first training module trains the data filtering rule user model based on the historical business data to obtain the trained data filtering rule user model, which is used to generate corresponding data filtering rules for terminal devices.

[0121] The rule distribution module generates data filtering rules that match the user based on the trained data filtering rule user model, and distributes the generated data filtering rules to the user's terminal device.

[0122] In the embodiments described in this specification, the device further includes:

[0123] The second historical data acquisition module acquires historical business data generated during the user's execution of the target business.

[0124] The second training module trains the second risk detection model based on the historical business data to obtain the trained second risk detection model. The second risk detection model is used to detect risks in the business data generated during the user's execution of the target business.

[0125] In the embodiments described in this specification, the device further includes:

[0126] The third historical data acquisition module acquires historical business data generated during the user's execution of the target business.

[0127] The third training module trains the first risk detection model based on the historical business data to obtain the trained first risk detection model. The first risk detection model is used to detect risks in business data generated during the user's execution of the target business.

[0128] The model distribution module distributes the trained first risk detection model to the user's terminal device.

[0129] In the embodiments described in this specification, the device further includes:

[0130] The fourth historical data acquisition module acquires historical business data generated during the user's execution of the target business within the preset period when the preset period is reached.

[0131] The fourth training module detects historical business data generated within the preset period based on a preset data detection strategy and / or user complaint information, and obtains corresponding detection results. The detection results indicate whether the historical business data generated within the preset period includes data of risk types other than the current risk type.

[0132] The model update module updates the target model based on the data of risk types other than the current risk type in the historical business data generated within the preset period, if the detection result indicates that the historical business data generated within the preset period includes such data. The target model includes a data filtering rule user model, a first risk detection model, and a second risk detection model.

[0133] This specification provides a data risk control device. It acquires business data generated during a user's execution of a target business process. Then, it determines whether the business data meets data filtering rules. If not, the business data is sent to a server for risk detection to determine the risk detection result. If yes, the business data is provided to a risk detection model, which performs risk detection on the business data to obtain a corresponding second risk detection result. If the second risk detection result matches the risk result determined by the data filtering rules, the risk detection result of the business data is determined. If the second risk detection result does not match the risk result determined by the data filtering rules, the business data is sent to the server for risk detection to determine the risk detection result of the business data. This proposes a decision-making timing based on "service requests," making data risk control processing more flexible, shortening the access time for risk control, and improving risk coverage and user experience. For example, in interactive social scenarios, previously risk control decisions could only be made at the end of the interactive game, during the payment verification process, affecting the efficiency and accuracy of risk control. This solution, however, allows for risk control decisions during the game process.

[0134] In addition, the data sources for business risk control analysis can be increased by integrating terminal device behavior and gateway log data to improve risk coverage. For example, in shopping scenarios, previously only static profiles of devices or users and historical shopping information could be used to determine whether there was a risk. However, this solution can integrate abnormal gateway logs, terminal access logs, etc. to comprehensively determine whether there is a risk.

[0135] Example 6

[0136] The above are data risk control devices provided in the embodiments of this specification. Based on the same idea, the embodiments of this specification also provide a data risk control device, such as... Figure 7 As shown.

[0137] The risk control equipment for the data can provide terminal devices or servers, etc., for the above embodiments.

[0138] Data risk control devices can vary significantly in configuration and performance, and may include one or more processors 701 and memory 702. Memory 702 may store one or more application programs or data. Memory 702 may be temporary or persistent storage. The application programs stored in memory 702 may include one or more modules (not shown), each module including a series of computer-executable instructions for the data risk control device. Furthermore, processor 701 may be configured to communicate with memory 702 and execute the series of computer-executable instructions in memory 702 on the data risk control device. The data risk control device may also include one or more power supplies 703, one or more wired or wireless network interfaces 704, one or more input / output interfaces 705, and one or more keyboards 706.

[0139] Specifically, in this embodiment, the data risk control device includes a memory and one or more programs, wherein one or more programs are stored in the memory, and one or more programs may include one or more modules, and each module may include a series of computer-executable instructions for the data risk control device, and is configured to be executed by one or more processors. The one or more programs include computer-executable instructions for performing the following:

[0140] Acquire business data generated during the user's execution of target business processes;

[0141] Based on the data filtering rules issued by the server, determine whether the business data meets the data filtering rules;

[0142] If not, the business data is sent to the server for risk detection, and the server sends a first risk detection result for the business data. Based on the first risk detection result, the risk detection result of the business data is determined.

[0143] If so, the business data is provided to the risk detection model, which performs risk detection on the business data to obtain a corresponding second risk detection result. If the second risk detection result matches the risk result determined by the data filtering rules, the risk detection result of the business data is determined. If the second risk detection result does not match the risk result determined by the data filtering rules, the business data is sent to the server for risk detection, and the server sends a third risk detection result for the business data. The risk detection result of the business data is determined based on the third risk detection result.

[0144] The embodiments in this specification also include:

[0145] If the business data is detected to include data of the first risk type, the business data is sent to the server for risk detection, and the risk detection result of the business data sent by the server is received. The first risk type is a risk type not included in the current risk types.

[0146] In the embodiments described in this specification, the data filtering rules include one or more of a whitelist, a blacklist, and a graylist.

[0147] In this embodiment of the specification, sending the business data to the server for risk detection includes:

[0148] An entrapment identifier is constructed based on the risk results determined by the data filtering rules and the risk detection results of the risk detection model.

[0149] The business data and the embedded identifier are sent to the server for risk detection.

[0150] In the embodiments described in this specification, the business data includes user operation sequence data, which is data from Remote Procedure Call (RPC) traffic.

[0151] In the embodiments described in this specification, the risk detection model is a model constructed using a deep neural network model.

[0152] The embodiments in this specification include:

[0153] Acquire historical business data generated during the user's execution of target business;

[0154] The risk detection model is trained based on the historical business data to obtain the trained risk detection model, which is used to detect risks in business data generated during the user's execution of target business.

[0155] Specifically, in this embodiment, the data risk control device includes a memory and one or more programs, wherein one or more programs are stored in the memory, and one or more programs may include one or more modules, and each module may include a series of computer-executable instructions for the data risk control device, and is configured to be executed by one or more processors. The one or more programs include computer-executable instructions for performing the following:

[0156] The terminal device receives business data generated during the user's execution of a target service. This business data is data sent when the terminal device obtains the business data and determines whether the business data meets the data filtering rules issued by the server, and when it determines that the business data does not meet the data filtering rules. Alternatively, the business data is data sent when the terminal device provides the business data to a first risk detection model, performs risk detection on the business data through the first risk detection model, obtains a corresponding second risk detection result, and the second risk detection result does not match the risk result determined by the data filtering rules.

[0157] The business data is input into the second risk detection model to obtain the corresponding risk detection results;

[0158] The obtained risk detection results are sent to the terminal device to trigger the terminal device to determine the risk detection result of the business data based on the received risk detection results.

[0159] The embodiments in this specification also include:

[0160] Acquire historical business data generated during the user's execution of target business;

[0161] The user model for data filtering rules is trained based on the historical business data to obtain the trained user model for data filtering rules. The user model for data filtering rules is used to generate corresponding data filtering rules for terminal devices.

[0162] Based on the trained data filtering rules, the user model generates data filtering rules that match the user, and sends the generated data filtering rules to the user's terminal device.

[0163] The embodiments in this specification also include:

[0164] Acquire historical business data generated during the user's execution of target business;

[0165] The second risk detection model is trained based on the historical business data to obtain the trained second risk detection model. The second risk detection model is used to detect risks in the business data generated during the user's execution of the target business.

[0166] The embodiments in this specification also include:

[0167] Acquire historical business data generated during the user's execution of target business;

[0168] The first risk detection model is trained based on the historical business data to obtain the trained first risk detection model. The first risk detection model is used to detect risks in business data generated during the process of a user performing a target business.

[0169] The trained first risk detection model is then sent to the user's terminal device.

[0170] The embodiments in this specification also include:

[0171] When the preset period is reached, acquire historical business data generated during the user's execution of the target business within the preset period;

[0172] Based on a preset data detection strategy and / or user complaint information, the historical business data generated within the preset period is detected to obtain corresponding detection results. The detection results indicate whether the historical business data generated within the preset period includes data of risk types other than the current risk type.

[0173] If the detection result indicates that the historical business data generated within the preset period includes data of risk types other than the current risk type, then the target model is updated based on the data of risk types other than the current risk type included in the historical business data generated within the preset period. The target model includes a data filtering rule user model, a first risk detection model, and a second risk detection model.

[0174] This specification provides a data risk control device that acquires business data generated during a user's execution of a target business. It then determines whether the business data meets data filtering rules. If not, the business data is sent to a server for risk detection to determine the risk detection result. If yes, the business data is provided to a risk detection model, which performs risk detection on the business data to obtain a corresponding second risk detection result. If the second risk detection result matches the risk result determined by the data filtering rules, the risk detection result of the business data is determined. If the second risk detection result does not match the risk result determined by the data filtering rules, the business data is sent to the server for risk detection to determine the risk detection result of the business data. This proposes a decision-making timing based on "service requests," which makes data risk control processing more flexible, shortens the access time for risk control, and improves risk coverage and user experience. For example, in interactive social scenarios, previously risk control decisions could only be made at the end of the interactive game, during the payment verification process, affecting the efficiency and accuracy of risk control. This solution, however, allows for risk control decisions during the game process.

[0175] In addition, the data sources for business risk control analysis can be increased by integrating terminal device behavior and gateway log data to improve risk coverage. For example, in shopping scenarios, previously only static profiles of devices or users and historical shopping information could be used to determine whether there was a risk. However, this solution can integrate abnormal gateway logs, terminal access logs, etc. to comprehensively determine whether there is a risk.

[0176] Example 7

[0177] Furthermore, based on the above Figures 1 to 4 The method shown in this specification, along with one or more embodiments, also provides a storage medium for storing computer-executable instruction information. In one specific embodiment, the storage medium can be a USB flash drive, optical disc, hard disk, etc. When the computer-executable instruction information stored in the storage medium is executed by a processor, it can achieve the following process:

[0178] Acquire business data generated during the user's execution of target business processes;

[0179] Based on the data filtering rules issued by the server, determine whether the business data meets the data filtering rules;

[0180] If not, the business data is sent to the server for risk detection, and the server sends a first risk detection result for the business data. Based on the first risk detection result, the risk detection result of the business data is determined.

[0181] If so, the business data is provided to the risk detection model, which performs risk detection on the business data to obtain a corresponding second risk detection result. If the second risk detection result matches the risk result determined by the data filtering rules, the risk detection result of the business data is determined. If the second risk detection result does not match the risk result determined by the data filtering rules, the business data is sent to the server for risk detection, and the server sends a third risk detection result for the business data. The risk detection result of the business data is determined based on the third risk detection result.

[0182] The embodiments in this specification also include:

[0183] If the business data is detected to include data of the first risk type, the business data is sent to the server for risk detection, and the risk detection result of the business data sent by the server is received. The first risk type is a risk type not included in the current risk types.

[0184] In the embodiments described in this specification, the data filtering rules include one or more of a whitelist, a blacklist, and a graylist.

[0185] In this embodiment of the specification, sending the business data to the server for risk detection includes:

[0186] An entrapment identifier is constructed based on the risk results determined by the data filtering rules and the risk detection results of the risk detection model.

[0187] The business data and the embedded identifier are sent to the server for risk detection.

[0188] In the embodiments described in this specification, the business data includes user operation sequence data, which is data from Remote Procedure Call (RPC) traffic.

[0189] In the embodiments described in this specification, the risk detection model is a model constructed using a deep neural network model.

[0190] The embodiments in this specification also include:

[0191] Acquire historical business data generated during the user's execution of target business;

[0192] The risk detection model is trained based on the historical business data to obtain the trained risk detection model, which is used to detect risks in business data generated during the user's execution of target business.

[0193] In another specific embodiment, the storage medium can be a USB flash drive, optical disc, hard disk, etc., and the computer-executable instruction information stored in the storage medium can achieve the following process when executed by the processor:

[0194] The terminal device receives business data generated during the user's execution of a target service. This business data is data sent when the terminal device obtains the business data and determines whether the business data meets the data filtering rules issued by the server, and when it determines that the business data does not meet the data filtering rules. Alternatively, the business data is data sent when the terminal device provides the business data to a first risk detection model after determining that the business data meets the data filtering rules, performs risk detection on the business data through the first risk detection model, obtains a corresponding second risk detection result, and when the second risk detection result does not match the risk result determined by the data filtering rules.

[0195] The business data is input into the second risk detection model to obtain the corresponding risk detection results;

[0196] The obtained risk detection results are sent to the terminal device to trigger the terminal device to determine the risk detection result of the business data based on the received risk detection results.

[0197] The embodiments in this specification also include:

[0198] Acquire historical business data generated during the user's execution of target business;

[0199] The user model for data filtering rules is trained based on the historical business data to obtain the trained user model for data filtering rules. The user model for data filtering rules is used to generate corresponding data filtering rules for terminal devices.

[0200] Based on the trained data filtering rules, the user model generates data filtering rules that match the user, and sends the generated data filtering rules to the user's terminal device.

[0201] The embodiments in this specification also include:

[0202] Acquire historical business data generated during the user's execution of target business;

[0203] The second risk detection model is trained based on the historical business data to obtain the trained second risk detection model. The second risk detection model is used to detect risks in the business data generated during the user's execution of the target business.

[0204] The embodiments in this specification also include:

[0205] Acquire historical business data generated during the user's execution of target business;

[0206] The first risk detection model is trained based on the historical business data to obtain the trained first risk detection model. The first risk detection model is used to detect risks in business data generated during the process of a user performing a target business.

[0207] The trained first risk detection model is then sent to the user's terminal device.

[0208] The embodiments in this specification also include:

[0209] When the preset period is reached, acquire historical business data generated during the user's execution of the target business within the preset period;

[0210] Based on a preset data detection strategy and / or user complaint information, the historical business data generated within the preset period is detected to obtain corresponding detection results. The detection results indicate whether the historical business data generated within the preset period includes data of risk types other than the current risk type.

[0211] If the detection result indicates that the historical business data generated within the preset period includes data of risk types other than the current risk type, then the target model is updated based on the data of risk types other than the current risk type included in the historical business data generated within the preset period. The target model includes a data filtering rule user model, a first risk detection model, and a second risk detection model.

[0212] This specification provides a storage medium that acquires business data generated during a user's execution of a target business process. It then determines whether the business data meets data filtering rules. If not, the business data is sent to a server for risk detection to determine the risk detection result. If yes, the business data is provided to a risk detection model, which performs risk detection on the business data to obtain a corresponding second risk detection result. If the second risk detection result matches the risk result determined by the data filtering rules, the risk detection result of the business data is determined. If the second risk detection result does not match the risk result determined by the data filtering rules, the business data is sent to the server for risk detection to determine the risk detection result of the business data. This proposes a decision-making timing based on "service requests," which makes data risk control processing more flexible, shortens the access time for risk control, and improves risk coverage and user experience. For example, in interactive social scenarios, previously risk control decisions could only be made at the end of the interactive game, during the payment verification process, affecting the efficiency and accuracy of risk control. This solution allows for risk control decisions during the game process.

[0213] In addition, the data sources for business risk control analysis can be increased by integrating terminal device behavior and gateway log data to improve risk coverage. For example, in shopping scenarios, previously only static profiles of devices or users and historical shopping information could be used to determine whether there was a risk. However, this solution can integrate abnormal gateway logs, terminal access logs, etc. to comprehensively determine whether there is a risk.

[0214] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0215] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using a hardware physical module. For example, a Programmable Logic Device (PLD) (e.g., a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program a digital system themselves to "integrate" it onto a PLD, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0216] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, ASICs, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0217] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, a computer can be, for example, a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or any combination of these devices.

[0218] For ease of description, the above apparatus is described by dividing it into various functional units. Of course, when implementing one or more embodiments of this specification, the functions of each unit can be implemented in one or more software and / or hardware.

[0219] Those skilled in the art will understand that the embodiments of this specification can be provided as methods, systems, or computer program products. Therefore, one or more embodiments of this specification may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, one or more embodiments of this specification may take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0220] Embodiments in this specification are described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this specification. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable parallel device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable parallel device, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0221] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable fraud device to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0222] These computer program instructions can also be loaded onto a computer or other programmable device, causing a series of operational steps to be performed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable device for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

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

[0224] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0225] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, 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 technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0226] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0227] Those skilled in the art will understand that the embodiments of this specification can be provided as methods, systems, or computer program products. Therefore, one or more embodiments of this specification may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, one or more embodiments of this specification may take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0228] One or more embodiments of this specification can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a particular task or implement a particular abstract data type. One or more embodiments of this specification can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0229] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to interchangeably. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

[0230] The above description is merely an embodiment of this specification and is not intended to limit this application. Various modifications and variations can be made to this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of the claims of this specification.

Claims

1. A data risk prevention and control method, applied to a terminal device, the method comprising: Acquire business data generated during the user's execution of the target business, including user-related information, target business-related information, and user operation information during the execution of the target business; Based on the data filtering rules issued by the server, determine whether the business data meets the data filtering rules; If not, the business data is sent to the server for risk detection, and the server sends a first risk detection result for the business data. Based on the first risk detection result, the risk detection result of the business data is determined. If so, the business data is provided to the risk detection model, which performs risk detection on the business data to obtain a corresponding second risk detection result. If the second risk detection result matches the risk result determined by the data filtering rules, the risk detection result of the business data is determined. If the second risk detection result does not match the risk result determined by the data filtering rules, the business data is sent to the server for risk detection, and the server sends a third risk detection result for the business data. The risk detection result of the business data is determined based on the third risk detection result.

2. The method according to claim 1, further comprising: If the business data is detected to include data of the first risk type, the business data is sent to the server for risk detection, and the risk detection result of the business data sent by the server is received. The first risk type is a risk type not included in the current risk types.

3. The method according to claim 2, wherein the data filtering rules include one or more of a whitelist, a blacklist, and a graylist.

4. The method according to any one of claims 1-3, wherein sending the business data to the server for risk detection includes: An entrapment identifier is constructed based on the risk results determined by the data filtering rules and the risk detection results of the risk detection model. The business data and the embedded identifier are sent to the server for risk detection.

5. The method according to claim 4, wherein the business data includes user operation sequence data, and the business data is data of remote procedure call (RPC) traffic.

6. The method according to claim 5, wherein the risk detection model is a model constructed using a deep neural network model.

7. The method according to claim 1, further comprising: Acquire historical business data generated during the user's execution of target business; The risk detection model is trained based on the historical business data to obtain the trained risk detection model, which is used to detect risks in business data generated during the user's execution of target business.

8. A data risk prevention and control method, applied to a server, the method comprising: The terminal device receives business data generated during the user's execution of a target service. This business data is generated after the terminal device acquires the data and determines whether it meets the data filtering rules issued by the server. If the data does not meet the data filtering rules, the terminal device sends the data. Alternatively, if the terminal device determines that the business data meets the data filtering rules, it provides the business data to a first risk detection model, performs risk detection on the business data using the first risk detection model, obtains a corresponding second risk detection result, and sends the data if the second risk detection result does not match the risk result determined by the data filtering rules. The business data includes user-related information, target service-related information, and user operation information during the execution of the target service. The business data is input into the second risk detection model to obtain the corresponding risk detection results; The obtained risk detection results are sent to the terminal device to trigger the terminal device to determine the risk detection result of the business data based on the received risk detection results.

9. The method according to claim 8, further comprising: Acquire historical business data generated during the user's execution of target business; The user model for data filtering rules is trained based on the historical business data to obtain the trained user model for data filtering rules. The user model for data filtering rules is used to generate corresponding data filtering rules for terminal devices. Based on the trained data filtering rules, the user model generates data filtering rules that match the user, and sends the generated data filtering rules to the user's terminal device.

10. The method according to claim 9, further comprising: Acquire historical business data generated during the user's execution of target business; The second risk detection model is trained based on the historical business data to obtain the trained second risk detection model. The second risk detection model is used to detect risks in the business data generated during the user's execution of the target business.

11. The method according to claim 9, further comprising: Acquire historical business data generated during the user's execution of target business; The first risk detection model is trained based on the historical business data to obtain the trained first risk detection model. The first risk detection model is used to detect risks in business data generated during the process of a user performing a target business. The trained first risk detection model is then sent to the user's terminal device.

12. The method according to any one of claims 9-11, further comprising: When the preset period is reached, acquire historical business data generated during the user's execution of the target business within the preset period; Based on a preset data detection strategy and / or user complaint information, the historical business data generated within the preset period is detected to obtain corresponding detection results. The detection results indicate whether the historical business data generated within the preset period includes data of risk types other than the current risk type. If the detection result indicates that the historical business data generated within the preset period includes data of risk types other than the current risk type, then the target model is updated based on the data of risk types other than the current risk type included in the historical business data generated within the preset period. The target model includes a data filtering rule user model, a first risk detection model, and a second risk detection model.

13. A data risk control device, the device comprising: The data acquisition module acquires business data generated during the user's execution of the target business. The business data includes relevant information about the user, relevant information about the target business, and operational information of the user during the execution of the target business. The filtering module determines whether the business data meets the data filtering rules based on the data filtering rules issued by the server. If not, the first risk module sends the business data to the server for risk detection, receives the first risk detection result of the business data sent by the server, and determines the risk detection result of the business data based on the first risk detection result. If the second risk module is present, it provides the business data to the risk detection model, performs risk detection on the business data through the risk detection model, and obtains a corresponding second risk detection result. If the second risk detection result matches the risk result determined by the data filtering rules, the risk detection result of the business data is determined. If the second risk detection result does not match the risk result determined by the data filtering rules, the business data is sent to the server for risk detection, and the server sends a third risk detection result for the business data. The risk detection result of the business data is determined based on the third risk detection result.

14. A data risk control device, the device comprising: The data receiving module receives business data generated during the user's execution of a target service from a terminal device. This business data is generated after the terminal device acquires the data and determines whether it meets the data filtering rules issued by the server. If the data does not meet the data filtering rules, the module sends the data. Alternatively, if the terminal device determines that the business data meets the data filtering rules, it provides the business data to a first risk detection model, performs risk detection on the business data using the first risk detection model, obtains a corresponding second risk detection result, and sends the data if the second risk detection result does not match the risk result determined by the data filtering rules. The business data includes user-related information, target service-related information, and user operation information during the execution of the target service. The risk detection module inputs the business data into the second risk detection model to obtain the corresponding risk detection results; The result sending module sends the obtained risk detection results to the terminal device to trigger the terminal device to determine the risk detection result of the business data based on the received risk detection results.

15. A data risk control device, the data risk control device comprising: processor; as well as A memory configured to store computer-executable instructions, which, when executed, cause the processor to: Acquire business data generated during the user's execution of the target business, including user-related information, target business-related information, and user operation information during the execution of the target business; Based on the data filtering rules issued by the server, determine whether the business data meets the data filtering rules; If not, the business data is sent to the server for risk detection, and the server sends a first risk detection result for the business data. Based on the first risk detection result, the risk detection result of the business data is determined. If so, the business data is provided to the risk detection model, which performs risk detection on the business data to obtain a corresponding second risk detection result. If the second risk detection result matches the risk result determined by the data filtering rules, the risk detection result of the business data is determined. If the second risk detection result does not match the risk result determined by the data filtering rules, the business data is sent to the server for risk detection, and the server sends a third risk detection result for the business data. The risk detection result of the business data is determined based on the third risk detection result.

16. A data risk control device, the data risk control device comprising: processor; as well as A memory configured to store computer-executable instructions, which, when executed, cause the processor to: The terminal device receives business data generated during the user's execution of a target service. This business data is generated after the terminal device acquires the data and determines whether it meets the data filtering rules issued by the server. If the data does not meet the data filtering rules, the terminal device sends the data. Alternatively, if the terminal device determines that the business data meets the data filtering rules, it provides the business data to a first risk detection model, performs risk detection on the business data using the first risk detection model, obtains a corresponding second risk detection result, and sends the data if the second risk detection result does not match the risk result determined by the data filtering rules. The business data includes user-related information, target service-related information, and user operation information during the execution of the target service. The business data is input into the second risk detection model to obtain the corresponding risk detection results; The obtained risk detection results are sent to the terminal device to trigger the terminal device to determine the risk detection result of the business data based on the received risk detection results.

17. A storage medium for storing computer-executable instructions, which, when executed by a processor, perform the following process: Acquire business data generated during the user's execution of the target business, including user-related information, target business-related information, and user operation information during the execution of the target business; Based on the data filtering rules issued by the server, determine whether the business data meets the data filtering rules; If not, the business data is sent to the server for risk detection, and the server sends a first risk detection result for the business data. Based on the first risk detection result, the risk detection result of the business data is determined. If so, the business data is provided to the risk detection model, which performs risk detection on the business data to obtain a corresponding second risk detection result. If the second risk detection result matches the risk result determined by the data filtering rules, the risk detection result of the business data is determined. If the second risk detection result does not match the risk result determined by the data filtering rules, the business data is sent to the server for risk detection, and the server sends a third risk detection result for the business data. The risk detection result of the business data is determined based on the third risk detection result.

18. A storage medium for storing computer-executable instructions, which, when executed by a processor, perform the following process: The terminal device receives business data generated during the user's execution of a target service. This business data is generated after the terminal device acquires the data and determines whether it meets the data filtering rules issued by the server. If the data does not meet the data filtering rules, the terminal device sends the data. Alternatively, if the terminal device determines that the business data meets the data filtering rules, it provides the business data to a first risk detection model, performs risk detection on the business data using the first risk detection model, obtains a corresponding second risk detection result, and sends the data if the second risk detection result does not match the risk result determined by the data filtering rules. The business data includes user-related information, target service-related information, and user operation information during the execution of the target service. The business data is input into the second risk detection model to obtain the corresponding risk detection results; The obtained risk detection results are sent to the terminal device to trigger the terminal device to determine the risk detection result of the business data based on the received risk detection results.

Images