Abnormality detection method, electronic device, storage medium and program product
By combining historical behavioral data and interaction information to detect the degree of anomaly in frequent flyer program user accounts in real time, the problem of lagging account detection in existing technologies has been solved, and efficient and accurate anomaly identification and processing have been achieved.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- CHINA SOUTHERN AIRLINES DIGITAL TECHNOLOGY (GUANGDONG) CO LTD
- Filing Date
- 2025-12-30
- Publication Date
- 2026-04-21
AI Technical Summary
In existing technologies, the detection of anomalies in frequent flyer program user accounts is delayed, making it impossible to identify violations in a timely manner and resulting in economic losses.
By combining the target account's historical behavior data and the interaction information of associated accounts, the abnormality of the target operation request is detected in real time. The pre-set abnormality rule library is used for matching and correction. Based on the number of historical abnormalities, the degree of account abnormality is determined and corresponding handling methods are taken.
It improves the timeliness and accuracy of account anomaly detection, enabling timely identification of abnormal operations, preventing economic losses, and reducing the risk of misjudgment and missed judgment.
Smart Images
Figure CN121901969A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of computer technology, and in particular to an anomaly detection method, electronic device, storage medium, and program product. Background Technology
[0002] Frequent flyer programs (FFPs) are loyalty reward programs established by airlines to encourage customers to repeatedly fly with them. As the years of a frequent flyer program increase, the value of a user's redeemable miles gradually rises. If the security of a user's account cannot be guaranteed, it can lead to huge financial losses.
[0003] Currently, the main method for detecting anomalies in user accounts is to periodically summarize account data and conduct manual review and verification to ultimately determine whether the account is in an abnormal state.
[0004] However, this detection mode has obvious lag defects, and it cannot identify and judge violations in the first moment. It is very easy for the problem to be discovered only after the violation has caused substantial damage. Summary of the Invention
[0005] This application provides an anomaly detection method, electronic device, storage medium, and program product, which are used to detect the degree of anomaly of a target account by combining the historical behavior data of the target account and the interaction information between the target account and associated accounts, and then provide a reasonable processing method for the target operation request, so as to solve the problem of current detection lag.
[0006] Firstly, this application provides an anomaly detection method, comprising: in response to receiving a target operation request, determining the request behavior data corresponding to the target operation request; the target operation request being a transaction operation request or a login operation request; the transaction operation request indicating a request to trade virtual assets associated with a target account; the login operation request indicating a request to log in to a target application using a target account on the current device; determining the degree of request anomaly corresponding to the target operation request based on the request behavior data and the historical behavior data corresponding to the target account; determining the degree of association anomaly corresponding to the target account based on the interaction information between the target account and associated accounts; the associated account being an account in the target application that is associated with the target account; determining the degree of account anomaly corresponding to the target account based on the degree of request anomaly and the degree of association anomaly; and determining the processing method for the target operation request based on the degree of account anomaly corresponding to the target account.
[0007] The technical solution provided in this application offers at least the following benefits: Upon receiving a target operation request representing a transaction operation request or a login operation request, the request behavior data corresponding to the target operation request is determined. Specifically, a transaction operation request represents a request to trade virtual assets associated with the target account, and a login operation request represents a request to log in to the target application using the target account on the current device. By immediately responding to and obtaining the request behavior data when the target operation request occurs, the response speed of the target operation request can be improved, providing data support for subsequent real-time detection of whether the target operation request is abnormal, and improving the timeliness of account anomaly detection. Then, the degree of anomaly of the target operation request is determined based on the request behavior data and historical behavior data, and the degree of association anomaly is determined based on the interaction information between the target account and the associated account. Judging the degree of anomaly of the target operation request from two dimensions—the target operation request itself and the associated account—ensures the accuracy of detecting the degree of anomaly of the target operation request. This, in turn, provides support for determining how to handle the target operation request. In one possible implementation, before determining the processing method for the target operation request based on the account abnormality level corresponding to the target account, the method further includes: matching the request behavior data with each preset abnormal rule in the preset abnormal rule library; and, if a preset abnormal rule is matched, correcting the account abnormality level corresponding to the target account based on the preset abnormality level corresponding to the matched preset abnormal rule.
[0008] Based on the above implementation method, by introducing a preset abnormal rule matching mechanism, the abnormality level of the obtained account is supplemented and corrected. By matching with the preset abnormal rules, known abnormal operations can be quickly identified, thereby enhancing the response sensitivity and judgment accuracy to known abnormal operations or typical abnormal behaviors.
[0009] In one possible implementation, the method further includes: determining the degree of request anomaly corresponding to the target operation request based on request behavior data and historical behavior data corresponding to the target account, including: determining multiple behavioral features based on request behavior data; determining the similarity between each behavioral feature and historical behavioral features; the historical behavioral features are determined based on the historical behavior data corresponding to the target account; and determining the degree of request anomaly corresponding to the target operation request based on the similarity between each behavioral feature among the multiple behavioral features.
[0010] Based on the above implementation method, by comparing the similarity between the current behavior characteristics and the historical behavior characteristics, if the current behavior characteristics and the historical behavior characteristics are significantly different, the abnormality of the target operation request is determined to be high. Combining historical behavior characteristics can improve the accuracy of the abnormality determination of the target operation request.
[0011] In one possible implementation, the method further includes: determining the number of historical anomalies corresponding to the target account; determining the processing method for the target operation request based on the degree of account anomaly corresponding to the target account, including: correcting the degree of account anomaly corresponding to the target account based on the number of historical anomalies to obtain a corrected degree of account anomaly; the corrected degree of account anomaly is positively correlated with the number of historical anomalies; and determining the processing method for the target operation request based on the corrected degree of account anomaly.
[0012] Based on the above implementation method, the abnormality level of the target account is adjusted by combining the historical number of abnormalities of the target account, and the historical abnormality records of the account are included in the current risk assessment, so that high-frequency abnormal accounts are given higher risk weights, thereby strengthening the detection capability of habitual offenders or continuous abnormal behavior.
[0013] In one possible implementation, the interaction information includes at least one of the following: the degree of account anomaly corresponding to the associated account, the interaction frequency between the target account and the associated account, and the similarity of the historical behavioral characteristics of the target account and the associated account.
[0014] Based on the above implementation method, the risk assessment context is expanded by utilizing social or operational information in the interaction information between the target account and associated accounts, effectively identifying abnormal behaviors carried out collaboratively through associated accounts.
[0015] In one possible implementation, the processing method for the target operation request is determined based on the degree of abnormality of the target account, including: if the degree of abnormality of the target account is greater than or equal to a first preset threshold, the target operation request is blocked.
[0016] Based on the above implementation method, when the abnormality level of the target account reaches the first preset threshold, the operation is blocked immediately to prevent risky behavior from further evolving into actual loss.
[0017] In one possible implementation, the method further includes: if the degree of abnormality corresponding to the target account is greater than or equal to a second preset threshold, freezing the virtual assets associated with the target account and outputting an alarm message; the alarm message is used to indicate that the target account has been prohibited from trading.
[0018] Based on the above implementation method, a dual approach of asset freezing and proactive alerts is adopted for high-risk accounts to prevent asset transfer at the first time, and then relevant parties are notified through alert information to intervene in a timely manner, thereby improving the efficiency and security of handling high-risk events on target accounts.
[0019] Secondly, embodiments of this application provide an anomaly detection device, comprising: The determination module, in response to receiving a target operation request, determines the request behavior data corresponding to the target operation request; the target operation request is either a transaction operation request or a login operation request; a transaction operation request indicates a request to trade virtual assets associated with the target account; a login operation request indicates a request to log in to the target application using the target account on the current device; The determination module is also used to determine the degree of request anomaly corresponding to the target operation request based on request behavior data and historical behavior data corresponding to the target account. The detection module is also used to determine the degree of association anomaly of the target account based on the interaction information between the target account and the associated account; the associated account is an account in the target application that has an association relationship with the target account; The detection module is also used to determine the degree of account abnormality corresponding to the target account based on the degree of request abnormality and the degree of associated abnormality. The processing module is used to determine how to handle the target operation request based on the degree of abnormality of the account corresponding to the target account.
[0020] Thirdly, this application provides an electronic device, including: a processor and a memory, the processor being coupled to the memory; the memory being used to store computer instructions, which are loaded and executed by the processor to enable the computer device to implement the method described in the first aspect.
[0021] Fourthly, this application provides a computer-readable storage medium comprising: computer software instructions; which, when executed in an electronic device, cause the electronic device to implement the method described in the first aspect.
[0022] Fifthly, this application provides a computer program product comprising a computer program; when the computer program is run in an electronic device, it causes the electronic device to implement the method described in the first aspect.
[0023] The beneficial effects of the second to fifth aspects mentioned above are described in the corresponding description of the first aspect and will not be repeated here. Attached Figure Description
[0024] Figure 1 This is a schematic diagram of an anomaly detection process provided in an embodiment of this application; Figure 2 A schematic diagram of another anomaly detection process provided in an embodiment of this application; Figure 3 This is a schematic diagram of the structure of an anomaly detection system provided in an embodiment of this application; Figure 4 This is a schematic diagram of the composition of an anomaly detection device provided in an embodiment of this application; Figure 5This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation
[0025] In this article, the term "and / or" is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can represent three situations: A exists alone, A and B exist simultaneously, and B exists alone.
[0026] The terms "first" and "second," etc., used in the specification and drawings of this application are used to distinguish different objects or to distinguish different treatments of the same object, rather than to describe a specific order of objects.
[0027] Furthermore, the terms "comprising" and "having," and any variations thereof, used in the description of this application are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the steps or units listed, but may optionally include other steps or units not listed, or may optionally include other steps or units inherent to such process, method, product, or apparatus.
[0028] It should be noted that in the embodiments of this application, the words "exemplary" or "for example" are used to indicate examples, illustrations, or explanations. Any embodiment or design scheme described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design schemes. Specifically, the use of the words "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.
[0029] To facilitate a clear description of the technical solutions of the embodiments of this application, the terms "first" and "second" are used in the embodiments of this application to distinguish the same or similar items with essentially the same function and effect. Those skilled in the art can understand that the terms "first" and "second" are not intended to limit the quantity or execution order.
[0030] In the description of this application, unless otherwise stated, "a plurality of" means two or more.
[0031] Airlines' frequent flyer programs have accumulated a large amount of redeemable miles over a long period of time. However, once these loyalty points are illegally transferred or redeemed, the original transactions are often difficult to recover, making frequent flyer programs targets for attacks.
[0032] Currently, most airlines still use static thresholds for login IP, device fingerprints, and redemption frequency, and calculate risk scores in batches during end-of-day batch processing. Once a threshold is triggered, the security team manually reviews relevant logs and credentials to decide whether to freeze the account. This solution is simple to deploy, but it has significant delays and a high risk of false positives / false negatives. Especially during large promotions or periods of high cancellation and change rates due to extreme weather, static thresholds often lead to high-value members being mistakenly blocked and new types of group attacks going undetected.
[0033] Based on this, this application provides an anomaly detection method for determining request behavior data corresponding to a target operation request upon receiving a target operation request representing a transaction operation request or a login operation request. A transaction operation request represents a request to trade virtual assets associated with a target account, while a login operation request represents a request to log in to a target application using the target account on the current device. By immediately responding to and obtaining request behavior data when a target operation request occurs, the response speed of the target operation request can be improved, providing data support for subsequent real-time detection of whether the target operation request is abnormal, and improving the timeliness of account anomaly detection. Then, the degree of anomaly of the target operation request is determined based on the request behavior data and historical behavior data, and the degree of association anomaly is determined based on the interaction information between the target account and associated accounts. Judging the degree of anomaly of the target operation request from two dimensions—the target operation request itself and the associated account—ensures the accuracy of detecting the degree of anomaly of the target operation request. This, in turn, provides support for determining how to handle the target operation request.
[0034] The embodiments provided in this application will now be described in detail with reference to the accompanying drawings.
[0035] The anomaly detection method provided in this application can be applied to electronic devices. These electronic devices can be servers, such as a server cluster consisting of multiple servers, a single server, a computer, or a processor or processing chip within a server or computer. For example, electronic devices can also be terminals, such as mobile phones, tablets, wearable devices, in-vehicle devices, laptops, and ultra-mobile personal computers (Ultra). Mobile personal computers (UMPCs), netbooks, personal digital assistants (PDAs), etc. It should be noted that the embodiments of this application do not limit the specific form of the electronic device.
[0036] Figure 1 This is a flowchart illustrating an anomaly detection method provided in an embodiment of this application. Figure 1 As shown, the data processing method provided in this application can be implemented by the aforementioned electronic device, specifically including S101~S105.
[0037] S101. In response to receiving the target operation request, determine the request behavior data corresponding to the target operation request.
[0038] The target operation request can be a transaction operation request or a login operation request. A transaction operation request indicates a request to trade virtual assets associated with the target account. For example, a user-initiated request involving the disposal of virtual assets associated with the target account, such as virtual currency transfer, virtual item trading, or points redemption, is essentially a request to change the ownership or status of virtual assets.
[0039] A login request indicates a request to log in to a target application using the target account on the current device. Specifically, it refers to a user's request to access the target application and use the target account's permissions on the electronic device they are currently using (such as a mobile phone, computer, tablet, etc.). It is a prerequisite for the user to obtain account access rights.
[0040] Request behavior data represents the set of data related to the target operation request, including operation initiation time, initiating device information (device model, device unique identifier, IP address, geographical location), operation frequency, operation content details (such as transaction amount, transaction object, login account input method), etc.
[0041] For example, taking an airline customer platform as an example, user A uses a mobile phone (current device) to initiate a points transfer request to user B (the points transfer request is the target operation request, specifically a transaction operation request). After receiving the request, the platform collects user A's request behavior data (the request behavior data includes the time as 8:00 AM, the location of the initiating device's IP address as province A, the transaction amount, etc.).
[0042] In one implementation, after S101, the acquired request behavior data also needs to be preprocessed. The preprocessing includes, but is not limited to, data cleaning (e.g., filtering out invalid data), data standardization, and data anonymization (hiding or encrypting privacy information).
[0043] S102. Based on the request behavior data and the historical behavior data corresponding to the target account, determine the degree of request abnormality corresponding to the target operation request.
[0044] Historical behavior data can include historical records of all actions taken by the target account during its past use of the target application, including historical login devices, historical login time / location, historical transaction records, and historical operation frequency. For example, the target account has been operating between 8-10 PM for the past 6 months, its primary device is another fixed mobile phone, its primary IP address is located in province B, and its historical single transaction amount is much smaller than the current transaction amount. A comparison reveals a significant difference between the current request behavior and historical behavior, initially indicating a high degree of request anomaly.
[0045] The degree of abnormality of the request can be represented by a score (0-100), for example, 0 points is the lowest degree of abnormality, and 100 points is the highest degree of abnormality.
[0046] S103. Based on the interaction information between the target account and the associated account, determine the degree of association anomaly corresponding to the target account.
[0047] Associated accounts are accounts in the target application that are associated with the target account. The criteria for determining the association may include, but are not limited to: friend relationship, shared login device, shared payment account, frequent transactions, shared identity information, etc.
[0048] Based on the interaction information between the target account and associated accounts, it is determined whether the associated accounts exhibit any anomalies, and whether the target account engages in interaction with the abnormal associated accounts. For example, querying user A's associated accounts (the platform records show that user A and user C are friends and have had multiple financial transactions, meaning user C is an associated account), analyzing the interaction information reveals that user C has had 3 abnormal login records in the past 3 days (login from unfamiliar devices in different locations), therefore, user A's association anomaly level is determined to be moderate (e.g., 50 points). As another example, if user A has recently added several friends and has frequent transactions with these newly added friends, user A's association anomaly level can also be determined to be moderate.
[0049] Interaction information includes at least one of the following: the degree of account anomaly corresponding to the associated account, the interaction frequency between the target account and the associated account, and the similarity of the historical behavioral characteristics of the target account and the associated account. The degree of account anomaly corresponding to the associated account refers to the quantified value of the degree of account anomaly determined after anomaly detection in current or historical operations, reflecting the abnormal state of the associated account. If the associated account has a high risk, it may transmit to the target account. The interaction frequency refers to the number or frequency of interactions between the target account and the associated account within a preset statistical period (e.g., the last 7 days, the last 30 days). A higher interaction frequency indicates a closer association between the two accounts and a greater likelihood of risk transmission. The similarity of historical behavioral characteristics refers to the degree of similarity between the historical behavioral characteristics of the target account and the associated account (e.g., login time, frequently used devices, operational content preferences, transaction amount range, etc.). A higher similarity indicates possible collaborative operations or identity association (e.g., the same user controlling multiple accounts), and a higher potential risk.
[0050] In one implementation, a large model can be used to calculate the request anomaly level and the associated anomaly level separately, with the model outputting the request anomaly level and associated anomaly level for each operation. The large model supports an incremental training mechanism, allowing abnormal samples to be written back in real time to trigger online learning and enabling the model to continuously evolve during actual operation.
[0051] S104. Based on the degree of request anomaly and the degree of associated anomaly, determine the degree of account anomaly corresponding to the target account.
[0052] The weighted sum of the request anomaly level and the associated anomaly level can be used as the target account's overall anomaly level. For example, if the request anomaly level has a weight of 0.4 and a score of 50, and the associated anomaly level has a weight of 0.6 and a score of 60, then the target account's overall anomaly level is 56. Taking the request anomaly level as an example, its weight can be determined based on the target account's historical request anomaly scores. For instance, if the historical average request anomaly score is 40, and the current score is 50, then the request anomaly level's weight should be increased.
[0053] S105. Determine the processing method for the target operation request based on the degree of account abnormality corresponding to the target account.
[0054] Different handling methods are adopted for different levels of account anomaly in the target account. Multiple thresholds can be set, and corresponding actions are taken when the anomaly level of the target account meets different thresholds. For example, if the score is below 30, no action is taken; if the score is between 30 and 50, a warning is issued informing the target of potential risks, but the target's operation requests are not restricted; if the score is between 50 and 70, a warning is issued and the target's operation requests are restricted, including but not limited to limiting the number of operations and the amount of a single transaction; if the score is above 70, a warning is issued and all target operation requests of the target account are frozen.
[0055] Based on the above embodiments, by combining the request behavior data, historical behavior data and interaction information corresponding to the target operation request when the target operation request is received, the abnormality level of the target account can be analyzed in real time, which improves the timeliness of account anomaly detection, avoids the loss that may be caused by delayed analysis, and can improve the accuracy of account anomaly detection by combining multi-dimensional data.
[0056] Figure 2 This is a schematic diagram of another anomaly detection process provided in an embodiment of this application, as shown below. Figure 2 As shown, in one implementation, before S105, the method further includes S201-S202.
[0057] S201. Match the request behavior data with each preset exception rule in the preset exception rule library.
[0058] The preset anomaly rule library is a collection of anomaly behavior judgment rules pre-formulated and stored by the target application operator or security manager based on historical anomaly events, industry security standards, common attack methods, etc. Each rule corresponds to a specific anomaly scenario and preset anomaly level.
[0059] Preset exception rules are specific judgment clauses in the preset exception rule library, such as "more than 5 failed login attempts in a single day", "a single transaction amount exceeds 10 times the account's historical maximum transaction amount", "a large transaction is initiated within 10 minutes of logging in from an unfamiliar device in a different location", etc. Each rule has a clear applicable scenario and judgment condition.
[0060] After initially determining the level of account anomaly, but before determining the handling method for the target operation request, a pre-defined rule verification step can be added to the output of the large model using a rule engine. The collected request behavior data is compared one by one with each rule in the pre-defined anomaly rule library to determine whether the current request behavior conforms to one or more anomaly rules.
[0061] S202. If a preset abnormal rule is matched, the account abnormality level of the target account is corrected based on the preset abnormality level corresponding to the matched preset abnormal rule.
[0062] If a pre-defined anomaly rule is found to be matched, the pre-defined anomaly level corresponding to that rule is extracted. The pre-defined anomaly level of the account is then corrected based on this pre-defined anomaly level (for example, if the pre-defined anomaly level of the account is 60 points and the pre-defined anomaly level of the matched rule is 30 points, then the corrected anomaly level of the account is 90 points). After the correction is completed, the processing method for the target operation request is determined based on the corrected anomaly level of the account, thus avoiding misjudgment of risk due to a single dimension of evaluation.
[0063] like Figure 2 As shown, in one implementation, S102 can be implemented by S301-S303.
[0064] S301. Determine multiple behavioral characteristics based on request behavior data.
[0065] Behavioral features represent key dimensional information extracted from request behavior data that reflects the essential attributes of operational behavior. They are the basic indicators for quantitatively assessing the degree of request anomalies, including but not limited to operation time features, device features, geographical location features, operation content features, and operation frequency features.
[0066] S302. Determine the similarity between each behavioral characteristic and historical behavioral characteristics.
[0067] Historical behavior characteristics are determined based on the historical behavior data corresponding to the target account. Specifically, they are key dimension information extracted from the historical behavior data of the target account that corresponds to the current request behavior characteristics. They serve as the benchmark for judging whether the current behavior is abnormal. For example, the historical operation time characteristic is "8-10 pm", and the historical device characteristic is "a fixed mobile phone of a certain brand".
[0068] The similarity between each behavioral feature and historical behavioral features can be calculated using a preset algorithm (such as cosine similarity algorithm, Euclidean distance algorithm, etc.).
[0069] S303. Based on the similarity of each behavioral feature among multiple behavioral features, determine the degree of request anomaly corresponding to the target operation request.
[0070] Based on the importance of each behavioral feature (through weight settings, such as transaction amount feature weight 0.4, device feature weight 0.3, operation time feature weight 0.2, and geographical location feature weight 0.1), the similarity corresponding to each feature is weighted and calculated to finally obtain the request anomaly level of the current target operation request.
[0071] By combining the above embodiments with the historical behavioral characteristics of the target account, it is possible to determine whether the behavioral pattern of the target account has changed abruptly, thereby avoiding misjudging high-value users and improving the accuracy of identifying abnormal operations.
[0072] like Figure 2 As shown, in one implementation, the above S105 can also be implemented by S401-S404.
[0073] S401. Determine the number of historical anomalies corresponding to the target account.
[0074] Historical anomaly count refers to the cumulative number of times the target account has been judged as abnormal (including request anomaly, association anomaly, or account anomaly) due to various operational behaviors within a preset statistical period (such as the past 30 days or the past 90 days) before the current target operation request is initiated.
[0075] S402. Adjust the account abnormality level corresponding to the target account based on the number of historical abnormalities to obtain the adjusted account abnormality level.
[0076] The final account risk quantification value is obtained by adjusting the target account's abnormality level based on the number of historical anomalies. The corrected account abnormality level is positively correlated with the number of historical anomalies, meaning that the more historical anomalies there are, the greater the correction of the current account's abnormality level.
[0077] S403. Determine the processing method for the target operation request based on the corrected account anomaly level.
[0078] The implementation of S403 can be referred to S105 above, and will not be repeated here.
[0079] Based on the above embodiments, by accumulating the number of historical anomalies during the current judgment of the anomaly level of the target account, accounts that have performed abnormal operations multiple times can be identified, thereby improving the coverage of account detection and reducing the probability of missed detections.
[0080] In one implementation, S105 can be implemented as follows: if the anomaly level of the target account is greater than or equal to a first preset threshold, the target operation request is blocked. The first preset threshold can be a critical value for account anomaly level set by the operator based on risk control needs, business scenario characteristics, and historical risk data. It is used to delineate the boundary between "permissible operations" and "operations that need to be blocked." For example, it can be set to 70 points (out of 100), meaning an anomaly level ≥ 70 points indicates high risk and the operation needs to be blocked.
[0081] Blocking specifically refers to refusing to execute the current target operation request and providing feedback to the user that the operation failed. This method is used to directly block the execution of high-risk operations and prevent the risk from escalating (such as asset loss or account theft). In one possible implementation, blocking only applies to the current operation request and does not affect other functions of the account that have not triggered risks.
[0082] In one implementation, S105 can also be implemented as follows: if the abnormality level of the target account is greater than or equal to the second preset threshold, freeze the virtual assets associated with the target account and output alarm information.
[0083] The second preset threshold can also be a critical value for the degree of account abnormality set by the operator, which is higher than (or equal to) the first preset threshold. It is used to divide the boundary between "only blocking the current operation" and "freezing assets + alarm", corresponding to a higher level of risk. For example, it can be set to 90 points (out of 100), that is, the degree of abnormality ≥ 90 points is extremely high risk, and more stringent prevention and control measures need to be taken.
[0084] Freezing virtual assets associated with a target account means temporarily restricting the transfer, use, and trading permissions of all virtual assets associated with the target account, placing the virtual assets in a "non-disposable" state. During the freeze period, the ownership of the virtual assets still belongs to the user, but no changes can be made (such as transfers, exchanges, or consumption) until the risk is eliminated and the freeze is lifted.
[0085] Alarm messages are used to notify relevant entities (such as users, platform operators, and security managers) that a target account is at extremely high risk. The message content usually includes the target account ID, the type of abnormal operation, the degree of abnormality, the status of frozen assets, and risk warnings.
[0086] It should be noted that the first preset threshold and the second preset threshold can be the same or different, and the first preset threshold and the second preset threshold can be dynamically adjusted according to the risk level of historical operations. For example, if the risk level distribution of historical operations is 40-60 points, then the first preset threshold can be set to 60*(1+10%)=66, and the second preset threshold can be set to 60*(1+20%)=72.
[0087] Based on the above embodiments, different handling methods are adopted when the target account is in different abnormal states, so as to maintain the user experience as much as possible while ensuring the security of the target account.
[0088] The anomaly detection method of this application is described below with reference to a specific embodiment. In some embodiments, this application also provides an anomaly detection system. The anomaly detection system may include one or more functional modules for implementing the method described above. Figure 3 This is a schematic diagram of the structure of an anomaly detection system provided in an embodiment of this application, as shown below. Figure 3 As shown, the anomaly detection system includes: The data governance layer 201 is used to respond to target operation requests and determine the original request behavior data. After preprocessing the original behavior data obtained through multiple data source interfaces, it is injected into the data layer 202 in the form of a message stream. The Flink engine can then process the original behavior data and automatically label it with timestamps, behavior tags, and unique user identifiers.
[0089] Data layer 202 receives preprocessed request behavior data sent by data governance layer 201. Depending on the specific operation type of the target operation request, the request behavior data may include information such as points transactions, flight delay applications, login behavior, geographical location, and device information. Data layer 202 transmits the preprocessed feature data to the downstream artificial intelligence (AI) model layer through a dual "real-time / offline" path.
[0090] AI model layer 203 deploys a lightweight deep learning model and a graph neural network (GNN) engine to determine the request anomaly level and the correlation anomaly level, respectively. For each operation, the AI model outputs a final anomaly level for the target operation request based on the request anomaly level and the correlation anomaly level. The anomaly level can be quantified by a score, such as 0-100, and includes an anomaly feature explanatory vector. The AI model supports an incremental training mechanism, allowing anomaly samples to be written back in real time to trigger online learning and enable the model to continuously evolve during actual operation. Finally, the AI model pushes the quantified anomaly level of the target operation request to the business application layer 204 in a structured data format.
[0091] Application layer 204 includes risk control system 2041, membership management system 2042, and early warning notification module 2043. Risk control system 2041 determines whether to perform operations such as account freezing, suspension, or whitelist exclusion based on the quantification results of the abnormality of the target operation request provided by the business application layer, and sends the operation status back to membership management system 2042 through standard application programming interface.
[0092] The member management system 2042 is responsible for persistent account status and operation log recording. When the judgment result indicates that the account is suspended or unsuspended, this module automatically updates the member status and pushes key information to the early warning notification module 2043.
[0093] The early warning notification module 2043 is deployed at the bottom layer and is responsible for generating structured early warning content and sending synchronous alerts to the target account owner and the back-end operation and maintenance terminal through channels such as SMS, application push, and email, so as to realize a transparent risk control closed loop.
[0094] This application embodiment can divide the following device into functional modules based on the above method example. For example, each function can be divided into its own functional module, or two or more functions can be integrated into one processing module. The integrated module can be implemented in hardware or as a software functional module. Optionally, the module division in this application embodiment is illustrative and only represents one logical functional division; other division methods may be used in actual implementation.
[0095] In some embodiments, this application also provides an anomaly detection device. This anomaly detection device may include one or more functional modules for implementing the methods described in the above embodiments. For example, Figure 4 This is a schematic diagram illustrating the composition of an anomaly detection device 300 provided in an embodiment of this application. Figure 4 As shown, the anomaly detection device 300 includes: The determination module 301, in response to receiving the target operation request, determines the request behavior data corresponding to the target operation request; the target operation request is a transaction operation request or a login operation request; the transaction operation request indicates a request to trade virtual assets associated with the target account; the login operation request indicates a request to log in to the target application using the target account on the current device; The detection module 302 is also used to determine the degree of request abnormality corresponding to the target operation request based on the request behavior data and the historical behavior data corresponding to the target account; The detection module 302 is also used to determine the degree of association anomaly of the target account based on the interaction information between the target account and the associated account; the associated account is an account in the target application that has an association relationship with the target account; The determination module 301 is also used to determine the degree of account abnormality corresponding to the target account based on the degree of request abnormality and the degree of associated abnormality. Processing module 303 is used to determine the processing method for the target operation request based on the degree of account abnormality corresponding to the target account.
[0096] In one possible implementation, the processing module 303 is further configured to match the request behavior data with each preset exception rule in the preset exception rule library; and if a preset exception rule is matched, to correct the account exception level corresponding to the target account based on the preset exception level corresponding to the matched preset exception rule.
[0097] In one possible implementation, the detection module 302 is further configured to determine multiple behavioral features based on request behavior data; determine the similarity between each behavioral feature and historical behavioral features; the historical behavioral features are determined based on the historical behavioral data corresponding to the target account; and determine the degree of request anomaly corresponding to the target operation request based on the similarity between each behavioral feature among the multiple behavioral features.
[0098] In one possible implementation, the processing module 303 determines the number of historical anomalies corresponding to the target account; adjusts the account anomaly level corresponding to the target account based on the number of historical anomalies to obtain the adjusted account anomaly level; the adjusted account anomaly level is positively correlated with the number of historical anomalies; and determines the processing method for the target operation request based on the adjusted account anomaly level.
[0099] In one possible implementation, the interaction information includes at least one of the following: the degree of account anomaly corresponding to the associated account, the interaction frequency between the target account and the associated account, and the similarity of the historical behavioral characteristics of the target account and the associated account.
[0100] In one possible implementation, the processing module 303 is further configured to block the target operation request if the abnormality level corresponding to the target account is greater than or equal to a first preset threshold.
[0101] In one possible implementation, the processing module 303 is further configured to freeze the virtual assets associated with the target account and output an alarm message if the abnormality level of the target account is greater than or equal to a second preset threshold; the alarm message is used to indicate that the target account has been prohibited from trading.
[0102] When the methods of the above embodiments are implemented in hardware, this embodiment of the invention provides a possible structural schematic diagram of the electronic device involved in the above embodiments. For example... Figure 5 As shown, the electronic device 400 includes: a processor 402, a communication interface 403, and a bus 404. Optionally, the electronic device 400 may also include a memory 401.
[0103] Processor 402 may implement or execute various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. Processor 402 may be a central processing unit, a general-purpose processor, a digital signal processor, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It may implement or execute various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. Processor 402 may also be a combination that implements computing functions, such as including one or more microprocessor combinations, a combination of a DSP and a microprocessor, etc.
[0104] Communication interface 403 is used to connect to other devices via a communication network. This communication network can be Ethernet, wireless access network, wireless local area network (WLAN), etc.
[0105] The memory 401 may be a read-only memory (ROM) or other type of static storage device capable of storing static information and instructions, random access memory (RAM) or other type of dynamic storage device capable of storing information and instructions, or electrically erasable programmable read-only memory (EEPROM), disk storage media or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but is not limited thereto.
[0106] In one possible implementation, the memory 401 can exist independently of the processor 402. The memory 401 can be connected to the processor 402 via a bus 404 and is used to store instructions or program code. When the processor 402 calls and executes the instructions or program code stored in the memory 401, it can implement the method provided in the embodiments of the present invention.
[0107] In another possible implementation, the memory 401 can also be integrated with the processor 402.
[0108] Bus 404 can be an Extended Industry Standard Architecture (EISA) bus, etc. Bus 404 can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 5 The symbol is represented by only one line, but this does not mean that there is only one bus or one type of bus.
[0109] Through the above description of the implementation methods, those skilled in the art can clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the service calling device can be divided into different functional modules to complete all or part of the functions described above.
[0110] This application also provides a computer-readable storage medium. All or part of the processes in the above method embodiments can be executed by computer instructions instructing related hardware. The program can be stored in the aforementioned computer-readable storage medium, and when executed, it can include the processes of the above method embodiments. The computer-readable storage medium can be any of the foregoing embodiments or memory. The aforementioned computer-readable storage medium can also be an external storage device of the aforementioned device, such as a plug-in hard drive, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the aforementioned device. Further, the aforementioned computer-readable storage medium can include both internal storage units of the aforementioned service call device and external storage devices. The aforementioned computer-readable storage medium is used to store the aforementioned computer program and other programs and data required by the aforementioned device. The aforementioned computer-readable storage medium can also be used to temporarily store data that has been output or will be output.
[0111] This application also provides a computer program product comprising a computer program that, when run on a computer, causes the computer to perform the methods provided in the above embodiments.
[0112] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.
Claims
1. An anomaly detection method, characterized in that, The method includes: In response to receiving a target operation request, the system determines the request behavior data corresponding to the target operation request; the target operation request is either a transaction operation request or a login operation request; the transaction operation request indicates a request to trade virtual assets associated with the target account; the login operation request indicates a request to log in to the target application using the target account on the current device. Based on the request behavior data and the historical behavior data corresponding to the target account, the degree of request abnormality corresponding to the target operation request is determined; Based on the interaction information between the target account and the associated account, the degree of association anomaly corresponding to the target account is determined; the associated account is an account in the target application that has an association relationship with the target account; Based on the degree of request anomaly and the degree of associated anomaly, the degree of account anomaly corresponding to the target account is determined; The processing method for the target operation request is determined based on the degree of account abnormality corresponding to the target account.
2. The method according to claim 1, characterized in that, Before determining the processing method for the target operation request based on the degree of account abnormality corresponding to the target account, the method further includes: The request behavior data is matched against each preset exception rule in the preset exception rule library; If the preset anomaly rule is matched, the account anomaly level corresponding to the target account is corrected based on the preset anomaly level corresponding to the matched preset anomaly rule.
3. The method according to claim 1, characterized in that, The step of determining the degree of request anomaly corresponding to the target operation request based on the request behavior data and the historical behavior data corresponding to the target account includes: Multiple behavioral characteristics are determined based on the requested behavior data; Determine the similarity between each of the stated behavioral features and historical behavioral features; the historical behavioral features are determined based on the historical behavioral data corresponding to the target account. Based on the similarity of each of the multiple behavioral features, the degree of request anomaly corresponding to the target operation request is determined.
4. The method according to claim 1, characterized in that, Before determining the processing method for the target operation request based on the degree of account abnormality corresponding to the target account, the method further includes: Determine the number of historical anomalies corresponding to the target account; The method for determining the processing of the target operation request based on the degree of account anomaly corresponding to the target account includes: The account anomaly level corresponding to the target account is adjusted based on the number of historical anomalies to obtain the adjusted account anomaly level; the adjusted account anomaly level is positively correlated with the number of historical anomalies. The processing method for the target operation request is determined based on the corrected account anomaly level.
5. The method according to claim 1, characterized in that, The interaction information includes at least one of the following: the degree of account abnormality corresponding to the associated account, the interaction frequency between the target account and the associated account, and the similarity of the historical behavioral characteristics of the target account and the associated account.
6. The method according to claim 1, characterized in that, The method for determining the processing of the target operation request based on the degree of account anomaly corresponding to the target account includes: If the abnormality level of the target account is greater than or equal to the first preset threshold, the target operation request is blocked.
7. The method according to claim 1, characterized in that, The method further includes: If the abnormality level of the target account is greater than or equal to the second preset threshold, the virtual assets associated with the target account are frozen, and an alarm message is output; the alarm message is used to indicate that the target account has been prohibited from trading.
8. An electronic device, characterized in that, It includes a processor and a memory, the processor being coupled to the memory; the memory is used to store computer instructions, which are loaded and executed by the processor to enable the computer device to perform the method as described in any one of claims 1 to 7.
9. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes computer-executable instructions that, when executed on a computer, cause the computer to perform the method of any one of claims 1 to 7.
10. A computer program product, characterized in that, The computer program product includes a computer program that, when run on an electronic device, causes the electronic device to perform the method as described in any one of claims 1 to 7.