Transaction risk detection method and device, storage medium and electronic equipment
By acquiring user data to calculate social relationship scores and performing semantic contradiction detection, and combining this with a risk decision matrix to identify transaction risk levels, this technology addresses the shortcomings of existing technologies in judging social relationships and transaction intentions, and achieves accurate identification and detection of transaction fraud risks.
Patent Information
- Application Number
- CN202511734224.X
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-11-24
- Publication Date
- 2026-02-13
AI Technical Summary
Existing technologies lack the ability to comprehensively judge the credibility of social relationships behind transactions and the semantic rationality of transaction intentions, resulting in poor identification of complex fraud scenarios based on social relationships and a high false negative rate.
By acquiring the target user's address book, call logs, and historical transaction records, a social relationship score is calculated to divide social circles. Then, a semantic rule base is used to detect semantic contradictions in transaction intent information and match risk words. Finally, a risk decision matrix is used to determine the transaction risk level.
It has achieved accurate identification of transaction fraud risks, improved the accuracy and coverage of transaction risk detection, and significantly improved the identification effect, especially in complex fraud scenarios such as impersonating acquaintances.
Smart Images
Figure CN121526801A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of computer technology, and in particular to a method, apparatus, storage medium and electronic device for detecting transaction risks. Background Technology
[0002] In the fintech field, especially in electronic payments and online transactions, transaction risk detection technology is a core element in ensuring user fund security. Existing solutions primarily rely on analyzing user transaction behavior itself, such as establishing baselines of historical user transactions to monitor anomalies in transaction amounts and frequency, or using blacklist databases to intercept transactions involving suspicious accounts. With technological advancements, some solutions have begun to employ machine learning models, analyzing multi-dimensional features such as device fingerprints and network environments to identify fraud. These methods have proven effective in addressing traditional fraud patterns.
[0003] However, the inventors of this application have discovered through long-term practice that the existing technical solutions have a fundamental core technical problem: the existing systems lack the ability to comprehensively judge the credibility of the social relationships behind the transaction and the semantic rationality of the transaction intention, which leads to poor identification effect and high false alarm rate in complex fraud scenarios based on social relationships, especially fraud behavior where the transaction behavior data seems normal but there are contradictions between the social context and semantic logic. Summary of the Invention
[0004] The technical problem this application aims to solve is to provide a transaction risk detection method, apparatus, storage medium, and electronic device capable of accurately identifying transaction fraud risks. The specific solution is as follows:
[0005] A method for detecting transaction risks, comprising:
[0006] In response to a received transaction instruction, the system acquires the target user's user data, which includes the address book, call logs, and historical transfer records.
[0007] Calculate the social relationship score between the target user and the counterparty based on the user data;
[0008] Based on the social relationship score, the target user and the counterparty are divided into social circles to obtain the division results;
[0009] Obtain the transaction intent information corresponding to the transaction instruction, the transaction intent information including the transaction type selected from predefined options and the transaction purpose description text entered by the user;
[0010] The semantic rule base is used to perform semantic contradiction detection and risk word matching on the transaction intent information in order to identify the intent risk of the target user and obtain the intent risk identification result;
[0011] Based on the classification results and the intention risk identification results, the transaction risk level corresponding to the transaction instruction is determined by the risk decision matrix.
[0012] Optionally, in the above method, calculating the social relationship score between the target user and the counterparty based on the user data includes:
[0013] Extract various relationship features associated with the counterparty from the user data. The relationship features include at least call frequency, number of historical transfers, number of shared groups, and duration of the relationship.
[0014] Assign a corresponding weight coefficient to each of the relation features;
[0015] Based on the weight coefficient of each relationship feature, a weighted sum is calculated for each relationship feature to generate a social relationship score.
[0016] Optionally, in the above method, obtaining the transaction intent information corresponding to the transaction instruction includes:
[0017] The transaction interface provides the target user with a predefined set of transaction type options;
[0018] Receive the target user's selection operation on the transaction type option set to determine the transaction type;
[0019] Displays a text input area for entering transaction information;
[0020] Receive the text describing the purpose of the transaction, which is entered by the target user in the text input area;
[0021] The determined transaction type is combined with the transaction purpose description text to obtain the transaction intent information.
[0022] Optionally, the above method, which utilizes a semantic rule base to perform semantic contradiction detection and risk word matching on the transaction intent information to identify the intent risk of the target user and obtain intent risk identification results, includes:
[0023] The text describing the purpose of the transaction is matched with a predefined risk vocabulary list to identify whether the text contains risk words and obtain the risk word identification results.
[0024] Input the semantic tags of transaction type and purpose, along with the recipient's attribute information, into the contradiction rule engine to verify the logical consistency of the transaction scenario and obtain the logical consistency verification result.
[0025] Based on the risk word identification results and the logical consistency verification results, the intent risk identification results of the target user are generated.
[0026] Optionally, in the above method, determining the transaction risk level corresponding to the transaction instruction through a risk decision matrix based on the segmentation result and the intention risk identification result includes:
[0027] Based on the classification results and the intentional risk identification results, the basic risk level corresponding to the classification results and the intentional risk identification results is obtained by matching them with the risk decision matrix.
[0028] The basic risk level is calibrated based on the time or amount of the transaction to obtain the transaction risk level corresponding to the transaction instruction.
[0029] Optionally, after determining the trading risk level corresponding to the trading instruction through the risk decision matrix, the above method further includes:
[0030] Determine the risk management procedures corresponding to the transaction risk level;
[0031] Perform the aforementioned risk management procedures.
[0032] A transaction risk detection device, comprising:
[0033] The acquisition unit is used to acquire user data of the target user in response to the received transaction instruction. The user data includes address book, call logs and historical transfer records.
[0034] The calculation unit is used to calculate the social relationship score between the target user and the counterparty based on the user data;
[0035] The first execution unit is used to divide the target user and the counterparty into social circles based on the social relationship score, and obtain the division result.
[0036] The acquisition unit is used to acquire the transaction intent information corresponding to the transaction instruction, the transaction intent information including the transaction type selected from predefined options and the transaction purpose description text input by the user;
[0037] The second execution unit is used to perform semantic contradiction detection and risk word matching on the transaction intent information using a semantic rule base, so as to identify the intent risk of the target user and obtain the intent risk identification result.
[0038] The determining unit is used to determine the transaction risk level corresponding to the transaction instruction through a risk decision matrix based on the division result and the intention risk identification result.
[0039] Optionally, in the aforementioned apparatus, the computing unit includes:
[0040] An extraction subunit is used to extract various relationship features associated with the counterparty from the user data. The relationship features include at least call frequency, number of historical transfers, number of common groups, and duration of relationship.
[0041] An allocation subunit is used to assign a corresponding weight coefficient to each of the relational features;
[0042] The calculation subunit is used to perform a weighted summation of each relation feature based on the weight coefficient of each relation feature to generate a social relation score.
[0043] A storage medium comprising stored instructions, wherein, when the instructions are executed, the device in which the storage medium resides executes the transaction risk detection method described above.
[0044] An electronic device includes a memory and one or more instructions, wherein one or more instructions are stored in the memory and configured to be executed by one or more processors as described above for the transaction risk detection method.
[0045] This application provides a transaction risk detection method, apparatus, storage medium, and electronic device. The method includes: in response to a received transaction instruction, acquiring user data of a target user, including address book, call logs, and historical transfer records; calculating a social relationship score between the target user and the counterparty based on the user data; classifying the target user and the counterparty into social circles based on the social relationship score, obtaining a classification result; acquiring transaction intent information corresponding to the transaction instruction, including a transaction type selected from predefined options and a description of the transaction purpose input by the user; performing semantic contradiction detection and risk word matching on the transaction intent information using a semantic rule base to identify the target user's intent risk, obtaining an intent risk identification result; and determining the transaction risk level corresponding to the transaction instruction through a risk decision matrix based on the classification result and the intent risk identification result. Applying the method provided in this application can accurately identify transaction fraud risks. Attached Figure Description
[0046] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of this application. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.
[0047] Figure 1 A flowchart of a transaction risk detection method provided in this application;
[0048] Figure 2 A schematic diagram of the system architecture of an anti-fraud system provided in this application;
[0049] Figure 3 This application provides a schematic diagram of the structure of a transaction risk detection device;
[0050] Figure 4 This is a schematic diagram of the structure of an electronic device provided in this application. Detailed Implementation
[0051] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.
[0052] In this application, the terms "comprising," "including," or any other variations thereof are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.
[0053] This application provides a method for detecting transaction risks. This method can be applied to electronic devices, such as personal computers, servers, smartphones, tablets, smart wearable devices, etc. The method flowchart is shown below. Figure 1 As shown, it specifically includes:
[0054] S101: In response to the received transaction instruction, obtain the target user's user data, including contacts, call logs, and historical transfer records.
[0055] In this embodiment, transaction instructions can be triggered by a user's transfer operation or payment request initiated through the client. User data is primarily obtained from local device storage or associated cloud servers. Contact list data includes contact names and contact information; call logs include caller and recipient frequency and duration statistics; and historical transfer records cover information such as transfer recipients, amounts, and frequencies over a specific period. These data collectively constitute the basic data source for assessing a user's social relationships.
[0056] S102: Calculate the social relationship score between the target user and the counterparty based on user data.
[0057] In this embodiment, the social relationship score is a comprehensive evaluation value obtained by quantitatively weighting multiple relationship dimensions. Specifically, four core dimensions related to the trading counterparty are first extracted from user data: call frequency, number of historical transfers, number of shared groups, and relationship duration. For example, the weight coefficients for each dimension are set as follows: call frequency 0.4, number of transfers 0.3, number of shared groups 0.2, and acquaintance duration 0.1. These weight coefficients can be dynamically adjusted according to business needs. Finally, a score value within the range of 0-100 is generated using a weighted summation algorithm; a higher score indicates a closer social relationship.
[0058] S103: Based on social relationship scores, segment the target users and their trading counterparts into social circles to obtain the segmentation results.
[0059] In this embodiment, social circles are divided into three levels based on three preset score ranges. Specifically, a score of ≥80 is classified as the core circle, including spouses and close friends with daily contact; a score between 30 and 79 is classified as the ordinary circle, including colleagues with monthly contact and casual friends; and a score <30 is classified as the stranger circle, mainly for new contacts with no prior interaction. This classification method helps to implement differentiated risk control strategies for different circles.
[0060] S104: Obtain the transaction intent information corresponding to the transaction instruction. The transaction intent information includes the transaction type selected from the predefined options and the transaction purpose description text entered by the user.
[0061] In this embodiment, transaction intent information is obtained through a combination of structured input and free text input. Specifically, the system provides users with drop-down menus containing options such as borrowing, repayment, and shopping, requiring users to select a transaction type. Simultaneously, a text input box is provided for users to fill in a specific description of the transaction purpose, such as "paying a down payment for a house." This design ensures both the standardization of transaction types and the flexibility of purpose descriptions.
[0062] S105: Utilize a semantic rule base to perform semantic contradiction detection and risk word matching on transaction intent information in order to identify the intent risk of the target user and obtain intent risk identification results.
[0063] In this embodiment, the semantic rule base comprises two core components: a high-risk vocabulary and a set of contradictory rules. During implementation, the text describing the purpose of the transaction is first matched against the high-risk vocabulary to identify whether it contains preset risk terms such as "margin deposit" or "brushing orders." Next, the contradictory rule engine verifies the logical consistency of the transaction scenario; for example, when the purpose is "paying rent," it checks whether the recipient has the "landlord" tag. Finally, the results from both aspects are combined to generate an intent risk identification report that includes risk level and risk type.
[0064] S106: Based on the classification results and the intention risk identification results, the transaction risk level corresponding to the transaction instruction is determined through the risk decision matrix.
[0065] In this embodiment, the risk decision matrix is a two-dimensional lookup table, where the row index corresponds to the social circle segmentation results and the column index corresponds to the intent risk identification results. Specifically, when the social circle is a core circle and the intent matches, the transaction is automatically allowed; however, when the social circle is an unfamiliar circle and contains high-risk keywords, the transaction is blocked. In addition, the system also has a dynamic adjustment mechanism. During nighttime transaction periods or when the transaction amount exceeds 200% of the monthly average transfer amount, the basic risk level is automatically increased by one level, thereby achieving precise calibration of the risk level.
[0066] In one optional embodiment, the calculation of social relationship scores can also incorporate a time decay factor. Specifically, for historical interaction data exceeding a certain time threshold, such as transfer records or call records older than six months, their weighting coefficients will decrease according to preset rules. This design makes the score more reflective of the recent closeness of social relationships, avoiding the undue influence of overly outdated historical data on current risk assessments.
[0067] In addition, the semantic rule base supports a dynamic update mechanism. During implementation, the system periodically extracts new risk features from actual fraud cases, which are then manually reviewed and incorporated into the rule base. For example, when new fraudulent tactics are discovered, relevant keywords can be added to the high-risk vocabulary list in a timely manner, thereby continuously improving the system's risk identification capabilities.
[0068] Specifically, for high-risk transaction scenarios, the system also features a multi-level verification mechanism. For example, when a transaction is detected to simultaneously meet the characteristics of both a stranger's circle and a lending transaction, a dynamic verification question based on social relationships will be generated first, such as asking for the date of the most recent call; if the verification fails, a further manual review process by customer service will be triggered. This progressive verification strategy ensures security while also considering user experience.
[0069] As is readily understood, this application's embodiments construct a two-dimensional risk assessment system by combining social relationship analysis with transaction intent recognition. Compared to traditional risk control solutions that solely rely on users' historical behavior, this solution can more accurately identify complex fraud scenarios such as impersonating acquaintances, effectively improving the accuracy and coverage of transaction risk detection.
[0070] It is worth noting that this solution strictly adheres to privacy protection principles during data collection and processing. All user data is anonymized on local devices, with only necessary feature parameters extracted for scoring calculations. The raw data is not uploaded to the server, thus ensuring user data security while achieving risk detection.
[0071] Finally, the technical solutions provided in this application can be flexibly deployed on various hardware platforms. They can run independently on mobile devices to achieve real-time risk control, or be centrally processed on servers to support large-volume transactions, demonstrating good scalability and applicability.
[0072] In one embodiment provided in this application, based on the above-described scheme, optionally, calculating a social relationship score between the target user and the counterparty based on user data includes:
[0073] Extract various relationship features associated with the counterparty from user data. These relationship features include at least call frequency, number of historical transfers, number of shared groups, and duration of the relationship.
[0074] Assign corresponding weight coefficients to each relation feature;
[0075] Based on the weight coefficient of each relation feature, the various relation features are weighted and summed to generate a social relation score.
[0076] In this embodiment, the process of extracting relationship features involves multi-dimensional analysis of the original user data. Specifically, call frequency is calculated based on the total number of calls made and received in the past three months combined with the average call duration; historical transfer statistics cover the number of successful transfers initiated by the target user to the counterparty in the past six months; the number of shared groups refers to the number of social application groups that both parties participate in, including but not limited to shared WeChat groups; and the relationship duration refers to the time span from the first communication or first transfer to the present, measured in months.
[0077] In implementation, the allocation of weighting coefficients follows the principle that the closeness of the relationship is directly proportional to the relevance of the risk. For example, the weighting coefficients for each dimension are set as follows: call frequency 0.4, historical transfer count 0.3, number of shared groups 0.2, and relationship duration 0.1. These weighting coefficients can be dynamically adjusted through the configuration interface according to actual business scenarios; for example, different weighting schemes can be adopted in specific regions or time periods.
[0078] The specific weighted summation calculation process is implemented using a linear weighted algorithm. First, the feature values of each dimension are normalized, converting them into standard scores within the range of 0-100. Then, each standard score is multiplied by its corresponding weight coefficient. Finally, the products are summed to obtain the final social relationship score. This score is also controlled within the range of 0-100, with higher scores indicating stronger social relationships.
[0079] In an optional embodiment, the calculation of relationship duration may also incorporate a time decay factor. Specifically, for historical data exceeding a preset time threshold (e.g., 24 months), its calculation weight will decrease according to an exponential decay law. This design allows recent social behaviors to have a greater impact on the scoring results, avoiding distorted judgments in current risk assessments due to overly outdated historical data.
[0080] Furthermore, the statistics on the number of shared groups can be divided into active and inactive groups. In practice, groups that have exchanged messages within the past month are defined as active groups, and their weighting factor in the calculation is 1.5 times that of inactive groups. This distinction more accurately reflects the actual intensity of social interaction between the two parties.
[0081] In particular, for newly registered users or special cases where data is missing, the system has a default scoring mechanism. When data for a certain relational feature is unavailable, the average value of the features of the user group to which the user belongs can be used for alternative calculations. At the same time, the weight coefficient of that feature item is proportionally redistributed to other available feature items to ensure the continuous provision of effective risk assessment services.
[0082] As is easily understood, this embodiment transforms qualitative social relationships into calculable and comparable numerical indicators by establishing a quantitative social relationship scoring mechanism. This transformation provides clear data support for subsequent risk decision-making processes, effectively improving the accuracy and consistency of transaction risk identification.
[0083] It is worth noting that the scoring calculation process has undergone necessary anonymization during the data preprocessing stage. All raw data involving personal privacy, such as specific call content and transfer amounts, are not included in the scoring calculation. Only non-sensitive data after statistical aggregation is used in the feature extraction stage, which complies with relevant regulations on personal information protection.
[0084] Finally, in actual deployment, the technical solution provided in this embodiment can select different computing modes according to the device performance requirements. A real-time computing mode can be used in high-performance server environments, while a near-real-time computing mode combining feature value caching and periodic updates can be used in resource-constrained environments such as mobile terminals. This flexibility allows the solution to adapt to different hardware configuration requirements.
[0085] In one embodiment provided in this application, based on the above-described solution, optionally, obtaining the transaction intent information corresponding to the transaction instruction includes:
[0086] The transaction interface provides target users with a predefined set of transaction type options;
[0087] Receive the target user's selection of the transaction type option set to determine the transaction type;
[0088] Displays a text input area for entering transaction information;
[0089] Receive the text describing the purpose of the transaction from the target user in the text input area;
[0090] By combining the identified transaction type with the text describing the purpose of the transaction, information about the transaction intent can be obtained.
[0091] In this embodiment, transaction intent information is collected by combining structured transaction type selection with unstructured purpose description input. The predefined transaction type option set includes common transaction scenarios such as lending, repayment, shopping, payments for goods, rent, labor remuneration, and others. These options need to cover most daily transfer purposes, and the configuration content of the option set can be dynamically updated and maintained through the backend management system.
[0092] In implementation, the transaction interface design combined mandatory selection with assisted input. Specifically, the system first displays a drop-down menu containing the aforementioned transaction type options, requiring the user to select one to confirm the transaction type. This mandatory selection mechanism ensures the standardization and analyzability of the transaction type data, providing a structured data foundation for subsequent semantic analysis.
[0093] Once the transaction type is determined, the system will simultaneously activate the adjacent text input area. This text input area is set as a multi-line text box and is accompanied by the prompt text "Please describe the purpose of the transaction in detail." The input area has an upper limit on the length of the content entered by the user, usually limited to within 50 Chinese characters. This design ensures that sufficient semantic information is obtained while avoiding excessively long text descriptions from affecting the efficiency of subsequent analysis and processing.
[0094] In one optional embodiment, the transaction type option set can also be personalized based on the user's historical behavior data. For example, for merchant users who frequently engage in payment transactions, the system will automatically display the "Payment" option at the top; while for ordinary individual users, frequently used options such as "Loan" and "Repayment" will be displayed first. This personalized sorting mechanism can improve user operational efficiency and enhance user experience.
[0095] In addition, the text input area is equipped with basic input validation functions. When the user's input description text contains special characters or emojis, the system will provide a real-time warning that the input does not conform to the specifications and require re-entry. Simultaneously, for obviously meaningless random character input, the system will also perform format validation when it loses focus, ensuring that the acquired description text has practical analytical value.
[0096] Specifically, when combining transaction type and purpose description text, the system encapsulates the data according to a predefined data structure. Specifically, the combined transaction intent information is stored in a key-value pair structure, where the transaction type serves as the primary key, the purpose description text as an additional descriptive field, and a timestamp of the intent information is also recorded. This standardized data structure facilitates unified processing by the subsequent semantic analysis module.
[0097] As is easily understood, this embodiment combines structured transaction type selection with unstructured usage descriptions, ensuring both the standardization of key information and the flexibility of specific usage descriptions. This dual-protection mechanism effectively obtains sufficient transaction intent information, providing comprehensive data support for subsequent risk identification.
[0098] It is worth noting that the system filters users' privacy information in real time throughout the entire intent information acquisition process. When the system detects that the purpose description text contains sensitive information such as ID card numbers or bank card numbers, it automatically performs desensitization processing, retaining only the text content related to semantic features. This processing method complies with relevant regulations on personal information protection.
[0099] Finally, the technical solution provided in this embodiment can be adapted and adjusted according to the characteristics of different terminal devices in practical applications. On mobile devices, the transaction type option can adopt a horizontal sliding selection interaction method; on PC devices, the traditional drop-down menu format is maintained. This differentiated interface design can better adapt to the operating characteristics of different devices and improve the user's operational convenience.
[0100] In one embodiment provided in this application, based on the above-described scheme, optionally, a semantic rule base is used to perform semantic contradiction detection and risk word matching on transaction intent information to identify the intent risk of the target user and obtain intent risk identification results, including:
[0101] The text describing the purpose of the transaction is matched with a predefined risk vocabulary list to identify whether the text contains risk words and obtain the risk word identification results.
[0102] Input the semantic tags of transaction type and purpose, along with the recipient's attribute information, into the contradiction rule engine to verify the logical consistency of the transaction scenario and obtain the logical consistency verification result.
[0103] Based on the risk word identification results and logical consistency verification results, the intent risk identification results of the target user are generated.
[0104] In this embodiment, the semantic rule base comprises two core components: a risk vocabulary and a set of contradictory rules. The risk vocabulary is essentially a dynamically maintained keyword blacklist, containing high-risk terms commonly used in known fraud scenarios, such as "margin deposit," "brushing orders," "investment rebates," and "safe account"—typical fraudulent phrases. This vocabulary can be updated and maintained through manual review and addition of new words, or automatically extracted and supplemented based on historical fraud cases using text mining.
[0105] In implementation, the pattern matching process combines string-based exact matching with fuzzy matching. Specifically, the system first normalizes the text describing the transaction purpose, including removing punctuation, standardizing full-width and half-width characters, and converting between simplified and traditional Chinese characters. Then, the processed text is compared one by one with each entry in the risk vocabulary list. When a complete risk term is found in the text, or a term with a similarity exceeding a preset threshold (e.g., 85%), it is marked as a successful match. This design effectively identifies fraudulent statements that have undergone slight modifications, improving the system's recognition coverage.
[0106] In one optional embodiment, the risk vocabulary can also be set with different risk levels based on the degree of risk of the words. For example, words such as "margin deposit" and "brushing orders," which are directly related to known fraud patterns, are marked as high-risk words, while words such as "urgent need" and "working capital," which have some risk implications but are not directly fraudulent, are marked as medium-risk words. Words with different risk levels will have different degrees of influence weight in the subsequent result generation stage. This classification mechanism makes risk assessment more refined.
[0107] Furthermore, the implementation of the conflict rule engine is based on a set of predefined business logic rules. These rules describe the logical consistency conditions that should be met under various transaction scenarios in the form of "IF-THEN". For example, a typical rule can be expressed as: IF Transaction Type="Rent Payment" THEN The payee attribute should contain the "Landlord" tag; or IF Transaction Type="Payment for Goods" THEN The payee account type should be "Corporate Account". When the rule engine is executed, it iterates through all applicable rules in turn, checking whether the current transaction information violates any of them.
[0108] In particular, the contradictory rule set supports flexible configuration based on business scenarios. During implementation, system administrators can add, modify, or deactivate specific rules through a graphical interface without modifying the program code. For example, when new fraud methods emerge, corresponding detection rules can be added promptly. This mechanism ensures that the system can quickly adapt to constantly evolving fraud tactics.
[0109] As is easy to understand, the logical consistency verification process is actually a cross-check of multi-dimensional information. The system needs to consider the transaction type, the semantic tags extracted from the purpose description text through natural language processing, and various attribute features of the payee (such as account type, historical transaction characteristics, user-added tags, etc.). By comparing this information with the preset business rules, it can discover any logical contradictions or anomalies.
[0110] It is worth noting that the system employs a multi-factor comprehensive evaluation method when generating intent risk identification results. Specifically, the risk word identification results and logical consistency verification results are comprehensively calculated according to preset weights. Logical consistency verification results typically have a higher weight coefficient because logical contradictions are often a better indicator of fraud risk than simple risk words. The final risk identification result includes a specific risk level (e.g., high, medium, low) and a detailed risk description, providing sufficient basis for subsequent risk decisions.
[0111] Finally, the technical solution provided in this embodiment establishes a comprehensive log recording mechanism during actual operation. The system records in detail the rules used in each detection, the matched risk words, the triggered contradictory rules, and the final risk assessment result. This log data can be used for subsequent case tracing and can also provide data support for the optimization and improvement of rules. At the same time, by analyzing this log data, blind spots or deficiencies in the existing rule system can be identified, promoting continuous improvement of the system.
[0112] In one embodiment provided in this application, based on the above-described scheme, optionally, based on the segmentation results and the intention risk identification results, the transaction risk level corresponding to the transaction instruction is determined through a risk decision matrix, including:
[0113] By matching the classification results and the intentional risk identification results with the risk decision matrix, the basic risk level corresponding to the classification results and the intentional risk identification results is obtained;
[0114] The basic risk level is calibrated based on the time or amount of the transaction to obtain the transaction risk level corresponding to the transaction instruction.
[0115] In this embodiment, the risk decision matrix is essentially a pre-defined two-dimensional lookup table. The table's structure is designed with social circles as the row dimension and the intent risk identification results as the column dimension. Specifically, the row dimension includes three circle categories: core circle, ordinary circle, and unfamiliar circle. The column dimension sets three risk states: intent matching, intent contradiction, and containing high-risk words. Each cell in the matrix has a predefined basic risk level and suggested handling measures. This tabular design makes the risk assessment process highly configurable and traceable.
[0116] In practice, the matching process is implemented through a dual-index lookup mechanism. Specifically, the system first obtains the social circle segmentation result of the current transaction and uses it as the row index to locate the corresponding row in the matrix; simultaneously, it obtains the risk level classification from the intent risk identification result and uses it as the column index to locate the corresponding column in the matrix. Next, the basic risk level for this transaction scenario is determined by the intersection of the row and column. This basic risk level is typically divided into three levels: low risk, medium risk, and high risk. For example, when the social circle is an unfamiliar circle and the intent identification result contains high-risk words, the basic risk level obtained through matrix matching is high risk.
[0117] In one optional embodiment, the risk decision matrix also supports differentiated configurations based on business scenarios. For example, different matrix versions can be used for users in different regions or for different types of accounts. For instance, the matrix for corporate accounts can include special rules such as verification of corporate accounts, while personal accounts can use the standard version of the matrix configuration. This flexibility allows risk control strategies to better adapt to different business needs.
[0118] In addition, the dynamic calibration mechanism considers two key factors: time and amount. In terms of time, the system defines the period from 11 PM to 5 AM the following day as the nighttime trading period; transactions within this period automatically raise the basic risk level by one level. In terms of amount, the system calculates the user's average monthly transfer amount over the past three months as a benchmark. When a single transaction exceeds 200% of this benchmark, the risk level is also raised. This dual calibration mechanism effectively identifies risk characteristics such as abnormal transaction times and large abnormal transactions.
[0119] Specifically, when both time and amount factors meet the calibration conditions, the system supports cumulative risk level increases. For example, a large transaction occurring at night might have its base risk level increased by two levels consecutively, directly adjusting from low risk to high risk. This cumulative effect enables more accurate risk assessments for complex risk scenarios.
[0120] It's easy to understand that maintaining the risk decision matrix is a continuous optimization process. During implementation, the system periodically calculates the actual fraud rate for each matrix unit, appropriately relaxing rules with excessively high false positive rates and strengthening rules with excessively high false negative rates. This dynamic optimization mechanism based on real-world data ensures that the matrix consistently maintains high accuracy in risk assessment.
[0121] It's worth noting that the calibration benchmark for transaction amounts uses a rolling update mechanism. Specifically, the system automatically recalculates the average monthly transfer amount for the most recent three months each month, removing obviously abnormal large transactions and taking the arithmetic mean as the new benchmark. This dynamically updated benchmark can promptly reflect changes in user transaction behavior and avoid benchmark distortion caused by changes in user income levels.
[0122] Finally, the technical solution provided in this embodiment includes a version management function for the risk decision matrix during actual deployment. Each modification to the matrix rules generates a new version number, while historical version records are retained. This design facilitates A / B testing to verify the effectiveness of new rules and allows for rapid rollback to a previous stable version in case of misjudgment, ensuring the stability and reliability of the system.
[0123] In one embodiment provided in this application, based on the above-described solution, optionally, after determining the transaction risk level corresponding to the transaction instruction through the risk decision matrix, the method further includes:
[0124] Determine the risk management procedures corresponding to the transaction risk level;
[0125] Perform risk management procedures.
[0126] This document provides a detailed introduction to the main functional modules and operating principles of this anti-fraud system.
[0127] In this embodiment, the determination of risk handling operations is based on a preset tiered handling strategy table. This strategy table establishes a one-to-one mapping relationship from risk level to specific handling operations, dividing transaction risk levels into three levels: low risk, medium risk, and high risk, with each level configured with a corresponding combination of handling operations. Specifically, low risk level corresponds to automatic release operation, medium risk level corresponds to enhanced verification operation, and high risk level corresponds to strong intervention measures such as transaction interception or delayed processing.
[0128] In implementation, the selection of the handling actions adopts a multi-factor decision-making mechanism. The system first determines the basic handling action based on the risk level, and then makes appropriate adjustments based on the characteristics of the transaction scenario. For example, for medium-risk transactions, SMS verification code verification is triggered in the case of a new device login, while manual customer service follow-up confirmation is initiated in the case of a large transaction. This differentiated handling strategy can better balance the relationship between security control and user experience.
[0129] In one optional embodiment, the risk handling operation also supports personalized configuration based on the user's risk preferences. For example, for users with low risk tolerance, stricter handling rules can be set, such as automatically elevating medium-risk transactions to high-risk handling levels; while for merchant users who frequently conduct large transactions, a more lenient handling strategy can be adopted, with strong intervention only for obviously abnormal transactions. This personalized configuration requires active user authorization and must be set in a secure environment.
[0130] Furthermore, the execution of the aforementioned actions employs a tiered triggering mechanism. Specifically, the system categorizes actions into multiple levels based on intervention intensity, ranging from the simplest automatic release to the most stringent temporary account freeze, triggering corresponding levels of actions sequentially according to the escalation of risk. This progressive approach effectively controls risk while avoiding unnecessary disruption to normal transactions.
[0131] Specifically, for special handling operations such as delayed arrival of funds, the system has set up a clear status tracking mechanism. When a transaction is determined to be delayed, the system will generate a pending transaction record, which includes key information such as the estimated unfreezing time, the verification customer service agent ID, and emergency contact channels. At the same time, the system will send a delay notification to both parties to the transaction and automatically initiate a review process before the preset time threshold is reached.
[0132] It is easy to understand that evaluating the effectiveness of the aforementioned handling operations is a continuous optimization process. During implementation, the system periodically analyzes the actual interception effect and false alarm rate of each handling operation. Rules with excessively high false alarm rates are appropriately relaxed, while rules with excessively high false negative rates are strengthened. This dynamic optimization mechanism based on actual data ensures that the handling strategy maintains a consistently high level of accuracy.
[0133] It is worth noting that the system has established a comprehensive multi-confirmation mechanism when performing high-risk handling operations. For example, when an account freeze operation is required, it must undergo dual confirmation through both automatic judgment by the risk control system and manual review. Furthermore, all operations are recorded in detailed audit logs, including information such as the operator, operation time, and decision basis. This design ensures both the rigor of risk handling and meets the requirements of compliance auditing.
[0134] Finally, the technical solution provided in this embodiment establishes a flexible rollback mechanism for processing operations. When the system detects that a processing operation may be misjudged, it supports the rapid cancellation of the executed operation through a preset emergency channel. For example, for transactions that are delayed due to being misjudged as high-risk, expedited processing can be carried out through the customer service ticket system. This mechanism effectively reduces the impact on users caused by system misjudgments.
[0135] This application also provides an anti-fraud system, the system architecture of which is shown in the figure below. Figure 2 As shown, the main functions of the processing module are as follows:
[0136] 1.1. Data Acquisition Layer: Real-time acquisition of user social data such as address book, call logs, and historical transfers;
[0137] 1.2. Risk Analysis Engine: Includes two modules: social relationship graph modeling and transaction intent analysis;
[0138] 1.3. Decision-making and execution level: Trigger differentiated verification measures based on risk level;
[0139] 1.4. Feedback and Learning Module: Continuously optimize the rule base through real-world fraud cases.
[0140] 2. Social relationship graph modeling.
[0141] 2.1. Social Relationship Score Calculation Process: Data Input → Relationship Dimension Weighting → Dynamic Score Calculation → Circle Division.
[0142] 2.2. The scoring calculation formula is as follows:
[0143] Rating = 0.4 * call frequency + 0.3 * number of money transfers + 0.2 * shared groups + 0.1 * duration of acquaintance
[0144] The weights of each relation dimension are adjustable.
[0145] 2.3. The layered division is shown in Table 1:
[0146] Table 1
[0147] social circles score range Example Scenario core circle ≥80 Spouse, daily phone call friend Normal circle 30-79 Colleagues I contact monthly unfamiliar circle <30 New contacts without historical interaction
[0148] 3. Semantic analysis of transaction intent.
[0149] 3.1. Structured intent input includes the following two types:
[0150] First, force users to select the transaction type (drop-down menu: loan / repayment / shopping, etc.).
[0151] Second, it assists in free text input.
[0152] 3.2. Semantic rule base, example as follows:
[0153] {
[0154] High-risk keywords: ["margin deposit", "brushing orders", "investment rebates"]
[0155] "Contradiction rule": [
[0156] {"Purpose":"Rent", "Recipient Requirements":"Landlord Label"},
[0157] {"Purpose":"Payment for Goods", "Account Type":"Corporate Account"} ]
[0159] }
[0160] 3.3. Example diagram of semantic contradiction detection:
[0161] User inputs: "Pay rent 5000 yuan" → System detection → Recipient tag: "Non-landlord" → Alarm triggered.
[0162] 4. Dual-modal risk linkage assessment.
[0163] 4.1 The risk decision matrix is shown in Table 2:
[0164] Table 2
[0165] social circles Intent matching Contradictory Intentions Contains high-risk words core circle Automatic release SMS confirmation Telephone verification unfamiliar circle Question and Answer Verification Delayed arrival Intercept
[0166] 4.2. The dynamic adjustment mechanism includes the following two types:
[0167] First, the time dimension: Nighttime trading automatically raises the risk level by one level.
[0168] Second, the amount: exceeding 200% of the average monthly transfer amount triggers enhanced verification.
[0169] 5. Tiered intervention measures.
[0170] 5.1 Intelligent Question Answer Generation:
[0171] Questions are dynamically generated based on social data:
[0172] Example question: "When was the last time you spoke with the recipient?"
[0173] The options are: Option 1: within 3 days; Option 2: within 1 week; Option 3: don't remember.
[0174] An incorrect answer will result in immediate account freezing.
[0175] 5.2. Delayed payment strategy:
[0176] First, high-risk transactions may be delayed by 2-24 hours before funds arrive.
[0177] Secondly, cancellation can be processed through customer service during this period.
[0178] Specifically, code examples for application scenarios are as follows:
[0179] If the risk of impersonating an acquaintance is detected, the following code will be executed:
[0180] If (trustScore < 30 && intent.contains("emergency loan")) {
[0181] triggerDynamicQA("Please state the recipient's birth month");
[0182] if (answerWrong) blockTransaction();
[0183] }
[0184] and Figure 1 Corresponding to the method described herein, embodiments of this application also provide a transaction risk detection device, applied to a data processing node in a blockchain, specifically used for detecting... Figure 1 The specific implementation of the method is shown in the following structural diagram. Figure 3 As shown, it includes:
[0185] The acquisition unit 301 is used to acquire user data of the target user in response to the received transaction instruction. The user data includes address book, call log and historical transfer record.
[0186] Calculation unit 302 is used to calculate the social relationship score between the target user and the counterparty based on the user data;
[0187] The first execution unit 303 is used to divide the target user and the counterparty into social circles based on the social relationship score, and obtain the division result.
[0188] The acquisition unit 304 is used to acquire the transaction intent information corresponding to the transaction instruction. The transaction intent information includes the transaction type selected from predefined options and the transaction purpose description text input by the user.
[0189] The second execution unit 305 is used to perform semantic contradiction detection and risk word matching on the transaction intent information using a semantic rule base, so as to identify the intent risk of the target user and obtain the intent risk identification result;
[0190] The determining unit 306 is used to determine the transaction risk level corresponding to the transaction instruction through a risk decision matrix based on the division result and the intention risk identification result.
[0191] In some embodiments provided in this application, based on the above-described scheme, optionally, the computing unit includes:
[0192] An extraction subunit is used to extract various relationship features associated with the counterparty from the user data. The relationship features include at least call frequency, number of historical transfers, number of common groups, and duration of relationship.
[0193] An allocation subunit is used to assign a corresponding weight coefficient to each of the relational features;
[0194] The calculation subunit is used to perform a weighted summation of each relation feature based on the weight coefficient of each relation feature to generate a social relation score.
[0195] The specific principles and execution processes of each unit and module in the transaction risk detection device disclosed in the above embodiments of this application are the same as those of the transaction risk detection method disclosed in the above embodiments of this application. Please refer to the corresponding parts of the transaction risk detection method provided in the above embodiments of this application, and they will not be repeated here.
[0196] This application also provides a storage medium, which includes stored instructions, wherein the instructions, when executed, control the device where the storage medium is located to perform the above-described transaction risk detection method.
[0197] This application also provides an electronic device, the structural schematic diagram of which is shown below. Figure 4 As shown, it specifically includes a memory 401 and one or more instructions 402, wherein one or more instructions 402 are stored in the memory 401 and are configured to be executed by one or more processors 403 to perform the above-mentioned transaction risk detection method.
[0198] It is understood that before using the technical solutions disclosed in the various embodiments of the present invention, users should be informed of the types, scope of use, and usage scenarios of the personal information involved in the present invention and their authorization should be obtained in accordance with relevant laws and regulations through appropriate means.
[0199] For example, upon receiving a user's active request, a prompt message is sent to the user to explicitly inform them that the requested operation will require the acquisition and use of the user's personal information. This allows the user to independently choose whether to provide personal information to the software or hardware, such as the electronic device, application program, server, or storage medium executing the operation of this invention, based on the prompt message.
[0200] As an optional but non-limiting implementation, in response to a user's active request, sending a prompt message to the user can be done via a pop-up window, where the prompt message can be presented in text format. Furthermore, the pop-up window can also include a selection control allowing the user to choose "agree" or "disagree" to provide personal information to the electronic device.
[0201] It is understood that the above notification and user authorization process is merely illustrative and does not constitute a limitation on the implementation of the present invention. Other methods that comply with relevant laws and regulations may also be applied to the implementation of the present invention.
[0202] It is understood that the data involved in this technical solution (including but not limited to the data itself, the acquisition or use of the data) shall comply with the requirements of relevant laws, regulations and related provisions.
[0203] It should be noted that the various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For apparatus embodiments, since they are basically similar to method embodiments, the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.
[0204] Finally, it should be noted that in this paper, relational terms such as first and second are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations.
[0205] For ease of description, the above devices are described separately by function as various units. Of course, in implementing this application, the functions of each unit can be implemented in one or more software and / or hardware.
[0206] As can be seen from the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware platforms. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods of various embodiments or some parts of the embodiments of this application.
[0207] The above provides a detailed description of a transaction risk detection method provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the method and its core ideas. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.
Claims
1. A method for detecting transaction risk, characterized in that, include: In response to a received transaction instruction, the system acquires the target user's user data, which includes the address book, call logs, and historical transfer records. Calculate the social relationship score between the target user and the counterparty based on the user data; Based on the social relationship score, the target user and the counterparty are divided into social circles to obtain the division results; Obtain the transaction intent information corresponding to the transaction instruction, the transaction intent information including the transaction type selected from predefined options and the transaction purpose description text entered by the user; The semantic rule base is used to perform semantic contradiction detection and risk word matching on the transaction intent information in order to identify the intent risk of the target user and obtain the intent risk identification result; Based on the classification results and the intention risk identification results, the transaction risk level corresponding to the transaction instruction is determined by the risk decision matrix.
2. The method according to claim 1, characterized in that, The calculation of the social relationship score between the target user and the counterparty based on the user data includes: Extract various relationship features associated with the counterparty from the user data. The relationship features include at least call frequency, number of historical transfers, number of shared groups, and duration of the relationship. Assign a corresponding weight coefficient to each of the relation features; Based on the weight coefficient of each relationship feature, a weighted sum is calculated for each relationship feature to generate a social relationship score.
3. The method according to claim 1, characterized in that, The step of obtaining the transaction intent information corresponding to the transaction instruction includes: The transaction interface provides the target user with a predefined set of transaction type options; Receive the target user's selection operation on the transaction type option set to determine the transaction type; Displays a text input area for entering transaction information; Receive the text describing the purpose of the transaction, which is entered by the target user in the text input area; The determined transaction type is combined with the transaction purpose description text to obtain the transaction intent information.
4. The method according to claim 3, characterized in that, The step of using a semantic rule base to perform semantic contradiction detection and risk word matching on the transaction intent information to identify the intent risk of the target user and obtain intent risk identification results includes: The text describing the purpose of the transaction is matched with a predefined risk vocabulary list to identify whether the text contains risk words and obtain the risk word identification results. Input the semantic tags of transaction type and purpose, along with the recipient's attribute information, into the contradiction rule engine to verify the logical consistency of the transaction scenario and obtain the logical consistency verification result. Based on the risk word identification results and the logical consistency verification results, the intent risk identification results of the target user are generated.
5. The method according to claim 1, characterized in that, The step of determining the transaction risk level corresponding to the transaction instruction through a risk decision matrix based on the classification result and the intention risk identification result includes: Based on the classification results and the intentional risk identification results, the basic risk level corresponding to the classification results and the intentional risk identification results is obtained by matching them with the risk decision matrix. The basic risk level is calibrated based on the time or amount of the transaction to obtain the transaction risk level corresponding to the transaction instruction.
6. The method according to claim 1, characterized in that, After determining the trading risk level corresponding to the trading instruction through the risk decision matrix, the method further includes: Determine the risk management procedures corresponding to the transaction risk level; Perform the aforementioned risk management procedures.
7. A transaction risk detection device, characterized in that, include: The acquisition unit is used to acquire user data of the target user in response to the received transaction instruction. The user data includes address book, call logs and historical transfer records. The calculation unit is used to calculate the social relationship score between the target user and the counterparty based on the user data; The first execution unit is used to divide the target user and the counterparty into social circles based on the social relationship score, and obtain the division result. The acquisition unit is used to acquire the transaction intent information corresponding to the transaction instruction, the transaction intent information including the transaction type selected from predefined options and the transaction purpose description text input by the user; The second execution unit is used to perform semantic contradiction detection and risk word matching on the transaction intent information using a semantic rule base, so as to identify the intent risk of the target user and obtain the intent risk identification result. The determining unit is used to determine the transaction risk level corresponding to the transaction instruction through a risk decision matrix based on the division result and the intention risk identification result.
8. The apparatus according to claim 7, characterized in that, The computing unit includes: An extraction subunit is used to extract various relationship features associated with the counterparty from the user data. The relationship features include at least call frequency, number of historical transfers, number of common groups, and duration of relationship. An allocation subunit is used to assign a corresponding weight coefficient to each of the relational features; The calculation subunit is used to perform a weighted summation of each relation feature based on the weight coefficient of each relation feature to generate a social relation score.
9. A storage medium, characterized in that, The storage medium includes stored instructions, wherein when the instructions are executed, the device containing the storage medium is controlled to perform the transaction risk detection method as described in any one of claims 1 to 6.
10. An electronic device, characterized in that, It includes a memory and one or more instructions, wherein one or more instructions are stored in the memory and configured to be executed by one or more processors as described in any one of claims 1 to 6.