Risk level determination method and device, storage medium and electronic device

Abstract

The invention discloses a risk level determination method and device, a storage medium and an electronic device, and relates to the technical field of smart home, and the method comprises the steps: determining a first risk control strategy corresponding to a target event when a target object is about to execute the target event; historical data corresponding to the target object is obtained, and the historical data comprises historical records of a target platform corresponding to the target event used by the target object in the target time period; the historical data is verified according to the first risk control strategy to determine the risk level of the target object executing the target event, and the risk level is used for indicating whether the target object is allowed to execute the target event or not; and under the condition that the risk level is a normal level, determining that the target object is allowed to execute the target event. According to the method, the problem that the misjudgment rate of the risk level is high due to the fact that the specific risk in the marketing activity cannot be specifically identified in the prior art can be solved.

Description

Technical Field

[0001] The present application relates to the field of smart home technology, and more specifically, to a method and device for determining a risk level, a storage medium, and an electronic device. Background Art

[0002] At present, the risk control strategies provided by third-party platforms are universal security capabilities and cannot be customized for specific businesses, especially those involving some localized strong business logic. Therefore, under the premise of being unable to effectively prevent and control, it is urgent to build your own risk control. Marketing and risk control have different focuses, but they complement each other. The marketing end is responsible for acquiring a large number of customers, and the risk control end is responsible for screening out good customers.

[0003] The problem with general risk control systems is that they lack specialized processing for marketing activities and cannot effectively identify specific risks in marketing activities, resulting in a high misjudgment rate and slow response. Different platforms invest a lot of money every year to promote various types of activities to acquire customers. The activity delivery scenarios are diverse, and the key businesses that require risk control are highly customized. That is, general risk control systems have the problem that related technologies cannot specifically identify specific risks in marketing activities, resulting in a high misjudgment rate of risk levels.

[0004] There is no effective solution yet for the problem that related technologies cannot specifically identify specific risks in marketing activities, resulting in a high rate of misjudgment of risk levels. Summary of the invention

[0005] The embodiments of the present application provide a method and device for determining a risk level, a storage medium, and an electronic device, so as to at least solve the problem in the related art that specific risks in marketing activities cannot be specifically identified, resulting in a high misjudgment rate of risk levels.

[0006] According to an embodiment of the embodiments of the present application, a method for determining a risk level is provided, including: when a target object is to execute a target event, determining a first risk control strategy corresponding to the target event; obtaining historical data corresponding to the target object, wherein the historical data includes historical records of the target object using a target platform corresponding to the target event within a target time period; verifying the historical data according to the first risk control strategy to determine the risk level of the target object executing the target event, wherein the risk level is used to indicate whether the target object is allowed to execute the target event; and when the risk level is a normal level, determining that the target object is allowed to execute the target event.

[0007] In an exemplary embodiment, determining the first risk control strategy corresponding to the target event includes: determining a second risk control strategy that has an association with the target event; verifying the second risk control strategy to determine whether the second risk control strategy is valid; if it is determined that the second risk control strategy is valid, determining the second risk control strategy as the first risk control strategy; if it is determined that the second risk control strategy is invalid, determining a preset risk control strategy as the first risk control strategy.

[0008] In an exemplary embodiment, the historical data is verified according to the first risk control strategy to determine the risk level of the target object executing the target event, including: determining whether the target object is in the blacklist and whitelist corresponding to the first risk control strategy according to the historical data; when it is determined that the target object is in the whitelist corresponding to the first risk control strategy, determining the verification method corresponding to the target object, wherein the verification method includes: contactless verification and slider verification code; verifying the target object based on the verification method to determine the risk level of the target object according to the first verification result; when it is determined that the target object is in the blacklist corresponding to the first risk control strategy, determining the risk level of the target object as the abnormal level.

[0009] In an exemplary embodiment, after determining whether the target object is in the blacklist and whitelist corresponding to the first risk control strategy based on the historical data, the method also includes: when it is determined that the target event is not in the blacklist and the whitelist, determining the user end corresponding to the target object; when it is determined that the user end corresponding to the target object is a non-target user end, calling the first risk control interface corresponding to the non-target user end; determining the risk control level of the target object when executing the target event based on the first risk control interface; when it is determined that the risk control level is the first risk control level, determining the verification method corresponding to the target object, and verifying the target object based on the verification method to determine the risk level of the target object according to a second verification result; when it is determined that the risk control level is the second risk control level, determining the risk level of the target object as the abnormal level, wherein the risk level of the target object corresponding to the second risk control level when executing the target event is greater than the risk level of the target object corresponding to the first risk control level when executing the target event.

[0010] In an exemplary embodiment, after determining the user end corresponding to the target object, the method also includes: when it is determined that the user end corresponding to the target object is the target user end, calling the second risk control interface corresponding to the target user end; determining whether the target object has used the target user end within the target time period based on the second risk control interface; when it is determined that the target object has not used the target user end within the target time period, determining the risk level of the target object as the abnormal level; when it is determined that the target object has used the target user end within the target time period, determining the security level of the target object when executing the target event based on the target object's use of the target user end, and determining the risk level of the target object executing the target event according to the security level, the security level including: safe and non-safe.

[0011] In an exemplary embodiment, determining the risk level of the target object executing the target event based on the security level includes: when the security level is determined to be safe, determining the number of times the target object is rebound based on the target user end, wherein the number of times the target object is rebound from the non-target user end to the target user end; determining the risk level of the target object executing the target event based on the number of times the target object is rebound; and when the security level is determined to be unsafe, determining the risk level of the target object as the abnormal level.

[0012] In an exemplary embodiment, the risk level of the target object executing the target event is determined based on the number of binding changes, including: when it is determined that the number of binding changes is greater than or equal to a preset threshold, the risk level of the target object is determined as the abnormal level; when it is determined that the number of binding changes is less than the preset threshold, the second risk control interface is switched to the first risk control interface; based on the first risk control interface, the risk control level corresponding to the target object is determined; when it is determined that the risk control level is the first risk control level, the verification method corresponding to the target object is determined, and the target object is verified based on the verification method to determine the risk level of the target object according to a third verification result; when it is determined that the risk control level is the second risk control level, the risk level of the target object is determined as the abnormal level.

[0013] According to another embodiment of the embodiments of the present application, a device for determining a risk level is also provided, including: a first determination module, used to determine a first risk control strategy corresponding to the target event when the target object is to execute a target event; an acquisition module, used to acquire historical data corresponding to the target object, wherein the historical data includes historical records of the target object using the target platform corresponding to the target event within a target time period; a verification module, used to verify the historical data according to the first risk control strategy to determine the risk level of the target object executing the target event, wherein the risk level is used to indicate whether the target object is allowed to execute the target event; a second determination module, used to determine whether the target object is allowed to execute the target event when the risk level is a normal level.

[0014] According to another aspect of an embodiment of the present application, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the risk level determination method through the computer program.

[0015] According to another aspect of the embodiments of the present application, a computer program product is provided, including a computer program, wherein the computer program is executed by a processor to perform the risk level determination method.

[0016] In an embodiment of the present application, when the target object is to execute a target event, the first risk control strategy corresponding to the target event is determined, and the historical data corresponding to the target object is obtained; the historical data is verified according to the first risk control strategy to determine the risk level of the target object executing the target event: normal level or abnormal level. That is to say, the embodiment of the present application determines the first risk control strategy corresponding to the target event, and then verifies the historical data of the target object according to the first risk control strategy to determine whether the risk level of the target object executing the target event is normal level or abnormal level. When it is determined that the risk level is a normal risk level, it is determined that the target object is allowed to execute the target event. The embodiment of the present application determines different first risk control strategies according to different target events, and verifies the historical data corresponding to different target objects according to different first risk control strategies to determine the risk level of the target object. Then, the specific risks in the marketing activities are identified in a targeted manner, which solves the problem of high misjudgment rate of risk levels caused by the inability to identify specific risks in marketing activities in the related art. Then, the misjudgment rate of risk levels is reduced. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0018] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0019] Figure 1 It is a hardware environment diagram of a method for determining a risk level in an embodiment of the present application;

[0020] Figure 2 is a flow chart of a method for determining a risk level according to an embodiment of the present application;

[0021] Figure 3 is a flow chart of a customized risk control strategy for a marketing activity according to an optional embodiment of the present application;

[0022] Figure 4 is a structural block diagram of a device for determining a risk level according to an embodiment of the present application;

[0023] Figure 5 It is a structural block diagram corresponding to the verification module according to the embodiment of the present application. DETAILED DESCRIPTION

[0024] In order to enable those skilled in the art to better understand the solution of the present application, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of the present application.

[0025] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device comprising a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0026] According to one aspect of the embodiments of the present application, a method for determining risk level is provided. The method for determining risk level is widely used in smart home, smart home, smart home device ecology, smart house ecology and other whole-house intelligent digital control application scenarios. Optionally, Figure 1 is a hardware environment diagram of a method for determining a risk level in an embodiment of the present application. In this embodiment, the above-mentioned method for determining a risk level can be applied to a module in a home appliance. The module can be applied to Figure 1 In the hardware environment composed of the home appliance 102 and the server 104 shown in FIG. Figure 1 As shown, the server 104 is connected to the home appliance 102 via a network, and can be used to provide services (such as application services, etc.) for the node or the client installed on the node. A database can be set on the server or independently of the server to provide data storage services for the server 104. Cloud computing and / or edge computing services can be configured on the server or independently of the server to provide data computing services for the server 104.

[0027] The network may include but is not limited to at least one of the following: wired network, wireless network. The wired network may include but is not limited to at least one of the following: wide area network, metropolitan area network, local area network, and the wireless network may include but is not limited to at least one of the following: WIFI (Wireless Fidelity), Bluetooth. The home appliance 102 may be but is not limited to smart air conditioners, smart range hoods, smart refrigerators, smart ovens, smart stoves, smart washing machines, smart water heaters, smart washing equipment, smart dishwashers, smart projection equipment, smart TVs, smart clothes hangers, smart curtains, smart audio and video, smart sockets, smart speakers, smart speakers, smart fresh air equipment, smart kitchen and bathroom equipment, smart bathroom equipment, smart sweeping robots, smart window cleaning robots, smart mopping robots, smart air purification equipment, smart steamers, smart microwave ovens, smart kitchen treasures, smart purifiers, smart water dispensers, smart door locks, etc.

[0028] In this embodiment, a method for determining a risk level is provided, which is applied to the above module. Figure 2 : is a flow chart of a method for determining a risk level according to an embodiment of the present application, the process comprising the following steps:

[0029] Step S202, when the target object is to execute a target event, determine a first risk control strategy corresponding to the target event;

[0030] It is understandable that the above-mentioned target event may be a marketing activity, such as a full-discount activity, a lottery activity, etc.

[0031] Step S204, obtaining historical data corresponding to the target object, wherein the historical data includes historical records of the target object using the target platform corresponding to the target event within a target time period;

[0032] The above historical data may be the browsing history, search history, purchase history, etc. of the target object.

[0033] Step S206: verifying the historical data according to the first risk control strategy to determine the risk level of the target object executing the target event, wherein the risk level is used to indicate whether the target object is allowed to execute the target event;

[0034] Step S208: When the risk level is a normal level, determine to allow the target object to execute the target event.

[0035] Through the above steps, when the target object is to execute the target event, the first risk control strategy corresponding to the target event is determined, and the historical data corresponding to the target object is obtained; the historical data is verified according to the first risk control strategy to determine the risk level of the target object executing the target event: normal level or abnormal level. That is to say, the embodiment of the present application determines the first risk control strategy corresponding to the target event, and then verifies the historical data of the target object according to the first risk control strategy to determine whether the risk level of the target object executing the target event is normal level or abnormal level. When it is determined that the risk level is a normal risk level, it is determined to allow the target object to execute the target event. The embodiment of the present application determines different first risk control strategies according to different target events, and verifies the historical data corresponding to different target objects according to different first risk control strategies to determine the risk level of the target object. Then, the specific risks in the marketing activities are identified in a targeted manner, which solves the problem that the specific risks in the marketing activities cannot be identified in a targeted manner in the related technology, resulting in a high misjudgment rate of the risk level. Then, the misjudgment rate of the risk level is reduced.

[0036] Optionally, determining the first risk control strategy corresponding to the target event in the above step S202 includes: determining a second risk control strategy that has an association with the target event; verifying the second risk control strategy to determine whether the second risk control strategy is valid; if it is determined that the second risk control strategy is valid, determining the second risk control strategy as the first risk control strategy; if it is determined that the second risk control strategy is invalid, determining the preset risk control strategy as the first risk control strategy.

[0037] It can be understood that the present application determines different risk control strategies for each target event. According to each target event, a second risk control strategy that is associated with this target event can be determined. The effectiveness of the risk control strategy needs to be determined. When the risk control strategy is determined to be valid, the second risk control strategy can be directly determined as the first risk control strategy corresponding to the target event. When the risk control strategy is determined to be invalid, the embodiment of the present application also provides a default risk control strategy, that is, a preset risk control strategy as an alternative, and the preset risk control strategy can be determined as the first risk control strategy.

[0038] According to the above embodiment, it is possible to prevent a situation where no risk control measures are implemented on the target object when the second risk control strategy associated with the target event is invalid.

[0039] Optionally, the above-mentioned step S206 verifies the historical data according to the first risk control strategy to determine the risk level of the target object executing the target event, including: determining whether the target object is in the blacklist and whitelist corresponding to the first risk control strategy according to the historical data; when it is determined that the target object is in the whitelist corresponding to the first risk control strategy, determining the verification method corresponding to the target object, wherein the verification method includes: contactless verification and slider verification code; verifying the target object based on the verification method to determine the risk level of the target object according to the first verification result; when it is determined that the target object is in the blacklist corresponding to the first risk control strategy, determining the risk level of the target object as the abnormal level.

[0040] It is understandable that it is necessary to determine whether the target object is in the blacklist and whitelist corresponding to the first risk control strategy. Specifically:

[0041] Determine whether the target object is in the business blacklist and business whitelist corresponding to the first risk control strategy;

[0042] In the case where it is determined that the target object is not in the business blacklist and the business whitelist, determine whether the target object is in the supplementary blacklist, supplementary whitelist and supplementary graylist (that is, technical black, white and gray lists) corresponding to the first risk control strategy, wherein the supplementary blacklist, supplementary whitelist and supplementary graylist are supplementary lists to the business blacklist and business whitelist;

[0043] In a case where it is determined that the target object is in the business blacklist, or the target object is in the supplementary blacklist, or the target object is in the supplementary graylist, determining that the target object is in the blacklist corresponding to the first risk control strategy;

[0044] When it is determined that the target object is in the business whitelist or the target object is in the supplemental whitelist, it is determined that the target object is in the whitelist corresponding to the first risk control strategy.

[0045] That is to say, the embodiments of the present application also include a supplementary blacklist, a supplementary whitelist, and a supplementary graylist. Through the embodiments of the present application, the black and white lists can be supplemented to make the black and white lists more comprehensive.

[0046] Among them, after determining whether the target object is in the blacklist and whitelist corresponding to the first risk control strategy according to the historical data, the method also includes: when it is determined that the target event is not in the blacklist and the whitelist, determining the user end corresponding to the target object; when it is determined that the user end corresponding to the target object is a non-target user end, calling the first risk control interface corresponding to the non-target user end; determining the risk control level of the target object when executing the target event based on the first risk control interface; when it is determined that the risk control level is the first risk control level, determining the verification method corresponding to the target object, and verifying the target object based on the verification method to determine the risk level of the target object according to the second verification result; when it is determined that the risk control level is the second risk control level, determining the risk level of the target object as the abnormal level, wherein the risk level of the target object corresponding to the second risk control level when executing the target event is greater than the risk level of the target object corresponding to the first risk control level when executing the target event.

[0047] It can be understood that when it is determined that the target object is neither in the business blacklist and the business whitelist, nor in the supplementary blacklist, supplementary whitelist and supplementary gray list, the user end of the target object can be determined, and the corresponding risk control interface can be determined according to the user end of the target object, and then the risk level of the target object can be determined according to different risk control interfaces.

[0048] Among them, after determining the user end corresponding to the target object, the method also includes: when it is determined that the user end corresponding to the target object is the target user end, calling the second risk control interface corresponding to the target user end; determining whether the target object has used the target user end within the target time period based on the second risk control interface; when it is determined that the target object has not used the target user end within the target time period, determining the risk level of the target object as the abnormal level; when it is determined that the target object has used the target user end within the target time period, determining the security level of the target object when executing the target event based on the use of the target user end by the target object, and determining the risk level of the target object executing the target event according to the security level, and the security level includes: safe and non-safe.

[0049] It is understandable that the target user end may be a mini program. When the end determines that the user end is a mini program end, it may determine whether the target object has used the mini program within a target time period (eg, within two hours).

[0050] When it is determined that the target object has not used the mini-program within the target time period, the target object is determined to be a user of an abnormal level.

[0051] When it is determined that the target object has used the mini-program within the target time period, it is necessary to further determine whether the risk level of the target object executing the target event is a safe level.

[0052] Wherein, determining the risk level of the target object executing the target event according to the security level includes: when it is determined that the security level is safe, determining the number of times the target object is rebound based on the target user end, wherein the number of times the target object is rebound from the non-target user end to the target user end; determining the risk level of the target object executing the target event according to the number of times the target object is rebound; when it is determined that the security level is unsafe, determining the risk level of the target object as the abnormal level.

[0053] It is understandable that after determining the number of times the target object has been re-bound on the mini program side, that is, the target object may have bound the mini program through a WeChat account, a mobile phone number, etc., it is possible to determine whether the target object has been unbound from the mini program side, and the risk level of the target object executing the target event can be determined by the number of times the target object has been unbound from the mini program side.

[0054] Among them, determining the risk level of the target object executing the target event according to the number of binding changes includes: when it is determined that the number of binding changes is greater than or equal to a preset threshold, determining the risk level of the target object as the abnormal level; when it is determined that the number of binding changes is less than the preset threshold, switching the second risk control interface to the first risk control interface; determining the risk control level corresponding to the target object based on the first risk control interface; when it is determined that the risk control level is the first risk control level, determining the verification method corresponding to the target object, and verifying the target object based on the verification method to determine the risk level of the target object according to a third verification result; when it is determined that the risk control level is the second risk control level, determining the risk level of the target object as the abnormal level.

[0055] It is understandable that, when the number of rebinding times of the target object is less than the preset threshold, the first risk control interface can be called to further verify the target object through the first interface, specifically: determine the risk control level corresponding to the target object, the risk control level can include the first risk control level, i.e., the normal risk control level, and the second risk control level, i.e., the abnormal risk control level. When the first risk control level is determined, the target object can be verified according to the verification method corresponding to the target event to determine the risk level of the target object executing the target event.

[0056] Verification methods may include: digital verification, slider verification, contactless verification, fingerprint verification and other verification methods.

[0057] In order to better understand the process of the above-mentioned risk level determination method, the implementation method flow of the above-mentioned risk level determination is described below in combination with an optional embodiment, but it is not used to limit the technical solution of the embodiment of the present application.

[0058] The purpose of the optional embodiments of the present application is to provide a customized risk control strategy for marketing activities, which can quickly and accurately identify and respond to various risks and improve the security and efficiency of marketing activities. Figure 3 is a flow chart of a customized risk control strategy for marketing activities according to an optional embodiment of the present application, such as Figure 3 As shown:

[0059] Step S301: Detecting that a user participates in an activity.

[0060] Users (i.e., target objects) participate in marketing activities (i.e., target events) through target channels. These activities include: drawing prizes, giving likes, collecting cards, and other activities on the activity page.

[0061] Step S302, determining whether to adopt the default strategy to determine the risk control strategy (ie, the first risk control strategy).

[0062] The defined risk control strategy (i.e., the second risk control strategy) is associated with the activity, and it is verified whether the defined risk control strategy is valid. If it is determined that the defined risk control strategy is valid, the risk control strategy is determined to be the defined risk control strategy (i.e., step S304); if it is determined that the defined risk control strategy is invalid, the risk control strategy is determined to be the default risk control strategy (i.e., the preset risk control strategy, i.e., step S303).

[0063] Step S303: follow the default risk control strategy.

[0064] Step S304, obtaining the corresponding risk control strategy through the strategy identifier.

[0065] Step S305, analyzing the risk control strategy.

[0066] Analyze the risk control strategy configuration items and verify the risk control points configured in the risk control strategy.

[0067] Step S306, query the user's risk control information (ie historical data).

[0068] Analyze user portraits (whether the user is on the blacklist, browsing history, search history, clicked links, purchase history, operating system, device model, network type, whether the home appliance is bound to a specific merchant, analysis of the content release records of a specific merchant, label users, customize labels in risk control strategies, and screen users.

[0069] Step S307, determine whether the user is in the service blacklist or whitelist. If the user is in the service blacklist, execute step S321; if the user is in the service whitelist, execute step S320; if the user is not in the service blacklist or whitelist, execute step S308.

[0070] Step S308, determine whether the user is in the technical black / gray list, if in the technical black / gray list, execute step S321, if in the technical white list, execute step S320, if not in the technical black / gray list, execute step S309.

[0071] Step S309, determining the user's end.

[0072] When it is determined that the user's end is a mini-program end (ie, a target end), step S310 is executed; when it is determined that the user's end is a non-mini-program end (ie, a non-target end), step S311 is executed.

[0073] Step S310, calling risk control interface 1 (ie, the second risk control interface).

[0074] The risk control interface 1 can be a private domain interface of the mini program.

[0075] Step S311, calling risk control interface 2 (ie, the first risk control interface).

[0076] Step S312, determine whether the user has visited the mini program within two hours.

[0077] If it is determined that the user has visited the mini program within two hours, step S313 is executed; if it is determined that the user has not visited the mini program within two hours, step S321 is executed.

[0078] Step S313, determining the user security level.

[0079] Verify the user's security level in the mini program. The security level is a risk control level score given by the merchant to the user. Risk control intercepts users with high risk control levels, tracks and monitors users in the middle level, and releases users with low levels.

[0080] When it is determined that the user security level is safe, step S304 is executed; when it is determined that the user security level is not safe, step S321 is executed.

[0081] Step S314, determining whether the number of times the user changes the binding on the mini program is within a specified range (ie, a preset threshold).

[0082] If it is determined that the number of times the user has changed the binding on the mini program side does not exceed the specified range, step S311 is executed. If it is determined that the number of times the user has changed the binding on the mini program side exceeds the specified range, step S321 is executed.

[0083] Step S315, determining the risk control level of the user.

[0084] If it is determined that the user is on the risk control level whitelist, execute step S316; if it is determined that the user is on the risk control level blacklist, execute step S317.

[0085] Step S316, storing whitelist users.

[0086] Step S317, storing blacklist users.

[0087] Step S318, determining the verification method corresponding to the activity.

[0088] Authentication can include: contactless verification, graphic code verification, and can be customized according to the activity.

[0089] Seamless verification means verifying the user during the user operation process without affecting the user's normal experience, and verifying the user's environmental information to verify the user's identity.

[0090] Graphic code verification verifies the verification code entered by the user to prevent automated attacks, malicious cracking, and spam registration.

[0091] Users can customize the above verification methods according to the nature and needs of the activities.

[0092] Determine whether the verification method is contactless verification or slider verification, and execute step S319 according to different verification methods.

[0093] Step S319, determining whether the verification code passes. If it is determined that the verification code passes, executing step S320; if it is determined that the verification code fails, executing step S321.

[0094] Step S320, determining that the risk control level of the user is a normal user level (ie, a normal level).

[0095] Step S321, determining that the user's risk control level is a risky user level (ie, an abnormal level).

[0096] In the optional embodiment of the present application, the risk control is based on the basic security protection capability, and customizes the configuration for different types of activities, supports real-time adjustment of risk control strategies, the ability to accurately intercept risky users, and the risk control model capabilities in the system, as well as the data processing flow and risk control strategies related thereto. The advantage of the optional embodiment of the present application over the prior art is its specialized processing capabilities for marketing activities, which can be customized according to the characteristics of different activities and historical data, accurately identify various potential risks, and adjust risk control strategies in real time. This can improve the efficiency of risk control, reduce the rate of misjudgment, and protect corporate interests and customer data security.

[0097] Through the description of the above implementation methods, those skilled in the art can clearly understand that the method according to the above embodiment can be implemented by means of software plus a necessary general hardware platform, and of course by hardware, but in many cases the former is a better implementation method. Based on such an understanding, the technical solution of the present application, or the part that contributes to the prior art, can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk), and includes a number of instructions for a terminal device (which can be a mobile phone, computer, server, or network device, etc.) to execute the methods of each embodiment of the present application.

[0098] Figure 4 is a structural block diagram of a device for determining a risk level according to an embodiment of the present application; Figure 5 As shown, including:

[0099] A first determination module 42 is used to determine a first risk control strategy corresponding to a target event when a target object is to execute the target event;

[0100] An acquisition module 44 is used to acquire historical data corresponding to the target object, wherein the historical data includes a historical record of the target object using the target platform corresponding to the target event within a target time period;

[0101] A verification module 46, configured to verify the historical data according to the first risk control strategy to determine a risk level of the target object executing the target event, wherein the risk level is used to indicate whether the target object is allowed to execute the target event;

[0102] The second determining module 48 is configured to determine, when the risk level is a normal level, whether or not the target object is allowed to execute the target event.

[0103] Through the above-mentioned device, when the target object is to execute the target event, the first risk control strategy corresponding to the target event is determined, and the historical data corresponding to the target object is obtained; the historical data is verified according to the first risk control strategy to determine the risk level of the target object executing the target event: normal level or abnormal level. That is to say, the embodiment of the present application determines the first risk control strategy corresponding to the target event, and then verifies the historical data of the target object according to the first risk control strategy to determine whether the risk level of the target object executing the target event is normal level or abnormal level. When it is determined that the risk level is a normal risk level, it is determined that the target object is allowed to execute the target event. The embodiment of the present application determines different first risk control strategies according to different target events, and verifies the historical data corresponding to different target objects according to different first risk control strategies to determine the risk level of the target object. Then, the specific risks in the marketing activities are identified in a targeted manner, which solves the problem that the specific risks in the marketing activities cannot be identified in a targeted manner in the related technology, resulting in a high misjudgment rate of the risk level. Then, the misjudgment rate of the risk level is reduced.

[0104] In an exemplary embodiment, the first determination module 42 is also used to determine a second risk control strategy associated with the target event; verify the second risk control strategy to determine whether the second risk control strategy is valid; if it is determined that the second risk control strategy is valid, determine the second risk control strategy as the first risk control strategy; if it is determined that the second risk control strategy is invalid, determine the preset risk control strategy as the first risk control strategy.

[0105] In an exemplary embodiment, the verification module 46 is also used to determine whether the target object is in the blacklist and whitelist corresponding to the first risk control strategy based on the historical data; when it is determined that the target object is in the whitelist corresponding to the first risk control strategy, determine the verification method corresponding to the target object, wherein the verification method includes: contactless verification and slider verification code; verify the target object based on the verification method to determine the risk level of the target object according to the first verification result; when it is determined that the target object is in the blacklist corresponding to the first risk control strategy, determine the risk level of the target object as the abnormal level.

[0106] in, Figure 5 is a structural block diagram corresponding to the verification module according to an embodiment of the present application, such as Figure 5 As shown: the verification module includes: a first verification submodule 52, a second verification submodule 54, a third verification submodule 56 and a fourth verification submodule 58. Specifically:

[0107] In an exemplary embodiment, the first verification submodule 52 is used to determine the user end corresponding to the target object when it is determined that the target event is not in the blacklist and the whitelist; when it is determined that the user end corresponding to the target object is a non-target user end, call the first risk control interface corresponding to the non-target user end; determine the risk control level of the target object when executing the target event based on the first risk control interface; when it is determined that the risk control level is the first risk control level, determine the verification method corresponding to the target object, and verify the target object based on the verification method to determine the risk level of the target object according to the second verification result; when it is determined that the risk control level is the second risk control level, determine the risk level of the target object as the abnormal level, wherein the risk level of the target object corresponding to the second risk control level when executing the target event is greater than the risk level of the target object corresponding to the first risk control level when executing the target event.

[0108] In an exemplary embodiment, the second verification submodule 54 is used to call the second risk control interface corresponding to the target user end when it is determined that the user end corresponding to the target object is the target user end; determine whether the target object has used the target user end within the target time period based on the second risk control interface; determine the risk level of the target object as the abnormal level when it is determined that the target object has not used the target user end within the target time period; determine the security level of the target object when executing the target event based on the use of the target user end by the target object when it is determined that the target object has used the target user end within the target time period, and determine the risk level of the target object executing the target event according to the security level, and the security level includes: safe and non-safe.

[0109] In an exemplary embodiment, the third check submodule 56 is used to determine the number of times the target object is rebound based on the target user end when the security level is determined to be safe, wherein the number of times the target object is rebound from the non-target user end to the target user end; determine the risk level of the target object executing the target event based on the number of times the target object is rebound; and determine the risk level of the target object as the abnormal level when the security level is determined to be unsafe.

[0110] In an exemplary embodiment, the fourth verification submodule 58 is used to determine the risk level of the target object as the abnormal level when it is determined that the number of binding changes is greater than or equal to a preset threshold; switch the second risk control interface to the first risk control interface when it is determined that the number of binding changes is less than the preset threshold; determine the risk control level corresponding to the target object based on the first risk control interface; when it is determined that the risk control level is the first risk control level, determine the verification method corresponding to the target object, and verify the target object based on the verification method to determine the risk level of the target object according to a third verification result; when it is determined that the risk control level is the second risk control level, determine the risk level of the target object as the abnormal level.

[0111] An embodiment of the present application further provides a storage medium, which includes a stored program, wherein the program executes any of the above methods when it is run.

[0112] Optionally, in this embodiment, the storage medium may be configured to store program codes for executing the following steps:

[0113] S1, when a target event is to be executed by a target object, determining a first risk control strategy corresponding to the target event;

[0114] S2, acquiring historical data corresponding to the target object, wherein the historical data includes historical records of the target object using the target platform corresponding to the target event within a target time period;

[0115] S3, verifying the historical data according to the first risk control strategy to determine the risk level of the target object executing the target event, wherein the risk level is used to indicate whether the target object is allowed to execute the target event;

[0116] S4: When the risk level is a normal level, determine to allow the target object to execute the target event.

[0117] An embodiment of the present application further provides an electronic device, including a memory and a processor, wherein a computer program is stored in the memory, and the processor is configured to run the computer program to execute the steps in any one of the above method embodiments.

[0118] Optionally, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor, and the input / output device is connected to the processor.

[0119] Optionally, in this embodiment, the processor may be configured to perform the following steps through a computer program:

[0120] S1, when a target event is to be executed by a target object, determining a first risk control strategy corresponding to the target event;

[0121] S2, acquiring historical data corresponding to the target object, wherein the historical data includes historical records of the target object using the target platform corresponding to the target event within a target time period;

[0122] S3, verifying the historical data according to the first risk control strategy to determine the risk level of the target object executing the target event, wherein the risk level is used to indicate whether the target object is allowed to execute the target event;

[0123] S4: When the risk level is a normal level, determine to allow the target object to execute the target event.

[0124] An embodiment of the present application further provides a computer program product, including a computer program, which is used by a processor to execute the steps in any of the above method embodiments.

[0125] Optionally, in this embodiment, the computer program product may be executed by a processor to perform the following steps:

[0126] S1, when a target event is to be executed by a target object, determining a first risk control strategy corresponding to the target event;

[0127] S2, acquiring historical data corresponding to the target object, wherein the historical data includes historical records of the target object using the target platform corresponding to the target event within a target time period;

[0128] S3, verifying the historical data according to the first risk control strategy to determine the risk level of the target object executing the target event, wherein the risk level is used to indicate whether the target object is allowed to execute the target event;

[0129] S4: When the risk level is a normal level, determine to allow the target object to execute the target event.

[0130] Optionally, in this embodiment, the above-mentioned storage medium may include but is not limited to: a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk or an optical disk, and other media that can store program codes.

[0131] Optionally, the specific examples in this embodiment may refer to the examples described in the above embodiments and optional implementation modes, and this embodiment will not be described in detail here.

[0132] Obviously, those skilled in the art should understand that the above modules or steps of the present application can be implemented by a general computing device, they can be concentrated on a single computing device, or distributed on a network composed of multiple computing devices, and optionally, they can be implemented by a program code executable by a computing device, so that they can be stored in a storage device and executed by the computing device, and in some cases, the steps shown or described can be executed in a different order from that herein, or they can be made into individual integrated circuit modules, or multiple modules or steps therein can be made into a single integrated circuit module for implementation. Thus, the present application is not limited to any specific combination of hardware and software.

[0133] The above is only a preferred embodiment of the present application. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present application. These improvements and modifications should also be regarded as the scope of protection of the present application.

Claims

1. A method for determining a risk level, characterized in that: include: In the case where the target object is to execute a target event, determining a first risk control strategy corresponding to the target event; Acquire historical data corresponding to the target object, wherein the historical data includes historical records of the target object using the target platform corresponding to the target event within a target time period; Verifying the historical data according to the first risk control strategy to determine the risk level of the target object executing the target event, wherein the risk level is used to indicate whether the target object is allowed to execute the target event; When the risk level is a normal level, it is determined that the target object is allowed to execute the target event.

2. The method for determining the risk level according to claim 1, characterized in that: Determining a first risk control strategy corresponding to the target event includes: Determining a second risk control strategy associated with the target event; Verifying the second risk control strategy to determine whether the second risk control strategy is effective; If it is determined that the second risk control strategy is effective, determining the second risk control strategy as the first risk control strategy; When it is determined that the second risk control strategy is invalid, the preset risk control strategy is determined as the first risk control strategy.

3. The method for determining the risk level according to claim 1, characterized in that: Verifying the historical data according to the first risk control strategy to determine the risk level of the target object executing the target event includes: Determining whether the target object is in the blacklist and whitelist corresponding to the first risk control strategy according to the historical data; In the case where it is determined that the target object is in the whitelist corresponding to the first risk control strategy, determining a verification method corresponding to the target object, wherein the verification method includes: non-contact verification and a slider verification code; Verifying the target object based on the verification method to determine the risk level of the target object according to a first verification result; When it is determined that the target object is in the blacklist corresponding to the first risk control strategy, the risk level of the target object is determined to be an abnormal level.

4. The method for determining the risk level according to claim 3, characterized in that: After determining whether the target object is in the blacklist and the whitelist corresponding to the first risk control strategy according to the historical data, the method further includes: In the case where it is determined that the target event is not in the blacklist and the whitelist, determining a user end corresponding to the target object; In the case where it is determined that the user end corresponding to the target object is a non-target user end, calling a first risk control interface corresponding to the non-target user end; Determining, based on the first risk control interface, a risk control level when the target object executes the target event; In the case where it is determined that the risk control level is the first risk control level, determining a verification method corresponding to the target object, and verifying the target object based on the verification method, so as to determine the risk level of the target object according to a second verification result; When it is determined that the risk control level is the second risk control level, the risk level of the target object is determined as the abnormal level, wherein the risk level of the target object corresponding to the second risk control level when executing the target event is greater than the risk level of the target object corresponding to the first risk control level when executing the target event.

5. The method for determining the risk level according to claim 4, characterized in that: After determining the user end corresponding to the target object, the method further includes: In the case where it is determined that the user end corresponding to the target object is the target user end, calling the second risk control interface corresponding to the target user end; Determining, based on the second risk control interface, whether the target object has used the target user terminal within a target time period; In the case where it is determined that the target object has not used the target user terminal within the target time period, determining the risk level of the target object as the abnormal level; When it is determined that the target object has used the target user end within the target time period, the security level of the target object when executing the target event is determined based on the target object's use of the target user end, and the risk level of the target object executing the target event is determined based on the security level, and the security levels include: safe and non-safe.

6. The method for determining the risk level according to claim 5, characterized in that: Determining the risk level of the target object executing the target event according to the security level includes: In the case where it is determined that the security level is safe, determining the number of times the target object is re-bound based on the target user end, wherein the number of times the target object is re-bound from the non-target user end to the target user end; Determining the risk level of the target object executing the target event according to the number of binding changes; When the safety level is determined to be unsafe, the risk level of the target object is determined to be the abnormal level.

7. The method for determining the risk level according to claim 6, characterized in that: Determining the risk level of the target object executing the target event according to the number of binding changes includes: When it is determined that the number of binding changes is greater than or equal to a preset threshold, determining the risk level of the target object as the abnormal level; If it is determined that the number of rebinding times is less than the preset threshold, switching the second risk control interface to the first risk control interface; Determining the risk control level corresponding to the target object based on the first risk control interface; In the case where it is determined that the risk control level is the first risk control level, determining the verification method corresponding to the target object, and verifying the target object based on the verification method, so as to determine the risk level of the target object according to a third verification result; When it is determined that the risk control level is the second risk control level, the risk level of the target object is determined as the abnormal level.

8. A device for determining a risk level, characterized in that: include: A first determination module, configured to determine, when a target event is to be executed by a target object, a first risk control strategy corresponding to the target event; An acquisition module, configured to acquire historical data corresponding to the target object, wherein the historical data includes a historical record of the target object using the target platform corresponding to the target event within a target time period; a verification module, configured to verify the historical data according to the first risk control strategy to determine a risk level of the target object executing the target event, wherein the risk level is used to indicate whether the target object is allowed to execute the target event; The second determining module is used to determine, when the risk level is a normal level, whether to allow the target object to execute the target event.

9. A computer-readable storage medium, characterized in that: The computer-readable storage medium includes a stored program, wherein the program executes the method described in any one of claims 1 to 7 when executed.

10. An electronic device comprising a memory and a processor, characterized in that: A computer program is stored in the memory, and the processor is configured to execute the method according to any one of claims 1 to 7 through the computer program.

Images