Big data-based recharging risk assessment method and system

Abstract

The invention relates to the technical field of safety and risk control, in particular to a recharging risk assessment method and system based on big data. The method comprises the following steps: executing first-level lightweight static detection on all transaction requests, and processing most of clear and safe or high-risk transactions by means of black and white lists and the like; if the first hierarchy cannot make clear judgment, the transaction is transmitted to a second hierarchy, and the hierarchy carries out behavior and context anomaly detection by introducing a short-term behavior portrait and transaction context information of the user; and for suspicious transactions which still cannot be qualitative at the second level, third-level evaluation is started, and a long-term user portrait and a graph are utilized to calculate an association network for comprehensive scoring. Through the multi-layer filtering structure, the computing resources are allocated to transactions of different risk levels according to needs, unnecessary deep analysis on low-risk transactions is avoided, and therefore the overall processing efficiency of the system is improved while the high-risk identification accuracy is guaranteed.

Description

Technical Field

[0001] The present invention relates to the field of security and risk control technology, and in particular to a recharge risk assessment method and system based on big data. Background Art

[0002] With the booming digital economy, online top-up services have penetrated e-commerce, telecommunications services, online games, and lifestyle services, becoming an indispensable payment method in users' daily lives. However, the convenience and high frequency of online top-up services also make them a hotbed for fraud. Fraudsters use various tactics, such as using stolen credit card information for top-ups and using top-up platforms to commit subscription fraud, resulting in significant financial losses and a loss of trust for both platforms and users.

[0003] Currently, existing technical solutions for addressing online recharge risks in the industry can be divided into the following two categories:

[0004] Static rule-based risk identification systems: These systems typically have a built-in rule engine that pre-defines a series of static, fixed logical rules based on the experience of domain experts. For example, a rule might be set such that if the transaction initiator's IP address is on a blacklist of known high-risk fraud areas, the transaction is directly rejected; or if a single deposit exceeds a preset hard threshold, a risk alert is triggered. These systems have clear logic, are easy to understand and implement, and respond quickly to known, fixed-pattern fraudulent behaviors. However, they lack flexibility and adaptability. Due to a lack of in-depth understanding of user behavior and transaction context, these systems are prone to generating a large number of "false positives" and "missed negatives," and their risk identification accuracy and coverage are difficult to meet the current complex fraud prevention needs.

[0005] Model-based risk assessment systems: To address the shortcomings of static rules, many modern risk control systems are turning to advanced machine learning or deep learning models. These systems, trained on massive amounts of historical transaction data, can learn and identify complex, nonlinear, and hidden fraud patterns, significantly improving the accuracy of risk identification. However, these technical solutions also present two significant challenges. First, the training and real-time inference of complex models consume enormous computing resources and time. For a highly concurrent recharge system, comprehensively analyzing every transaction using a heavyweight deep learning model is cost-prohibitive and performance-intensive, potentially leading to transaction delays and negative user experience. Second, the decision-making process of many advanced AI models, particularly deep neural networks, is a "black box," making it difficult to clearly explain to business personnel or regulators the basis for their specific risk assessments. This lack of explainability hinders system audits, iterative model optimization, and compliance requirements.

[0006] In summary, existing technologies generally struggle to strike an ideal balance between efficiency and accuracy in risk identification. Simple rule-based systems offer high efficiency but low accuracy, while complex AI models offer high accuracy but low efficiency and cost-effectiveness. Furthermore, with the widespread adoption of automated decision-making systems, transparency and explainability of the decision-making process have become a significant business pain point. Summary of the Invention

[0007] In order to solve the problem that the existing technology is difficult to achieve an ideal balance between the "efficiency" and "accuracy" of risk identification, the present invention proposes a recharge risk assessment method and system based on big data.

[0008] A recharge risk assessment method based on big data, comprising:

[0009] Receive a top-up transaction request including initial transaction data from the online business platform via an application programming interface or a message queue;

[0010] Performing a first-level evaluation on the recharge transaction request, wherein the first-level evaluation performs rapid filtering based on preset static data;

[0011] Based on the results of the first-level assessment, a conditional judgment is performed: if the transaction hits the blacklist or violates static rules, it is judged as high risk and a blocking decision is generated; if the transaction hits the whitelist and has no risk characteristics, it is judged as low risk and an approval decision is generated. In both cases, the assessment process ends; otherwise, the transaction is judged as pending risk and passed to the next step;

[0012] If the recharge transaction request is judged as pending risk at the first level, a second level assessment is performed on it. The second level assessment detects anomalies based on the user's short-term behavior data and the transaction context data, and outputs a comprehensive risk score for the transaction;

[0013] Based on the comprehensive risk score of the second-level assessment, a conditional judgment is performed: if the score is above the first high-risk threshold or below the first low-risk threshold, a corresponding approval or blocking decision is generated, and the assessment process ends; if the score falls within the risk range, a secondary verification process is triggered; otherwise, if the score falls within the fuzzy range, the transaction is again determined to have pending risk and passed to the next step;

[0014] If the recharge transaction request is still judged to be at risk at the second level, a third-level assessment will be performed on it. The third-level assessment will be based on a comprehensive score of the user's long-term behavioral profile data and the associated network data between entities, and a final disposal decision will be generated based on the score.

[0015] Preferably, the first-level evaluation is based on a quick filtering of preset static data, specifically including:

[0016] List matching: Key entity information in the initial transaction data, including but not limited to user ID, payment instrument hash value, IP address, and device fingerprint, is compared with multiple lists pre-loaded into the system and stored in an in-memory database. The list database includes internally maintained blacklists, whitelists, and graylists, as well as external high-risk entity lists obtained from public security, judicial authorities, or third-party security agencies.

[0017] Static rule and threshold judgment: comparing the transaction attributes in the initial transaction data with the preset static rule threshold;

[0018] High-rate detection: Based on a preset short time window, high-rate statistics are performed on the transaction frequency related to the recharge transaction request.

[0019] Preferably, before executing the second-level assessment, a data enrichment step is also included: based on the user ID in the initial transaction data, query and obtain related data from the risk variable library or user database to expand the initial transaction data set, and the related data specifically includes the user's short-term historical transaction statistics, commonly used device information, and historical geographic location information.

[0020] Preferably, the second-level assessment performs anomaly detection based on the user's short-term behavioral data and the transaction context data, and outputs a comprehensive risk score for the transaction, specifically including:

[0021] Short-term behavior profile deviation analysis: Quantitatively compare the key attributes of the current transaction with the user's recent behavior habits obtained from the data enrichment step to determine the degree of behavior deviation;

[0022] Contextual anomaly analysis: Analyze the geographic location information, device information, or time information of the transaction to determine contextual anomalies;

[0023] Risk score synthesis: The deviation and the output results of the anomaly detection are combined into a comprehensive risk score through a preset scoring card model, and the disposal decision is determined based on the preset range in which the risk score falls.

[0024] Preferably, the handling decision generated by the second level evaluation includes approval, blocking or requiring secondary identity verification.

[0025] Preferably, the third-level assessment performs comprehensive profiling and relationship scoring, specifically including:

[0026] Analyzing the user's long-term behavioral profile data to identify deviations from historical patterns;

[0027] Using the graph neural network model, we construct an association network graph that includes multiple entities such as users, devices, IP addresses, and payment tools as nodes and transaction relationships as edges. We then analyze the network through graph algorithms to discover hidden group fraud patterns.

[0028] Preferably, the third-level assessment comprehensively scores all deep features by calling a machine learning model to generate a final disposal decision, specifically including: when the final score is lower than the second lowest risk threshold, outputting an "approval" decision; when the final score is higher than the second highest risk threshold, outputting an "interception" decision; when the final score is lower than the second highest risk threshold but higher than the review threshold, outputting a "transfer to manual review" decision, which triggers the system to generate a case and push it to the risk analyst team for investigation.

[0029] Preferably, a feedback step is also included: the final conclusion of the "transfer to manual review" decision after confirmation by a manual analyst, or the fraud event information discovered and confirmed by other channels, is automatically fed back to the risk assessment system, for: automatically adding the entity information confirmed as fraudulent to the blacklist library used for the first-level assessment; using the confirmed fraud samples and normal transaction samples as new training data for regular retraining and iterative optimization of the machine learning model or scoring card model used in the second-level and third-level assessments.

[0030] A recharge risk assessment system based on big data, comprising:

[0031] The data receiving module is used to interact with external business systems in real time through APIs or message queues to receive recharge transaction requests;

[0032] a first-level evaluation engine, configured to perform the first-level evaluation on all received transaction requests;

[0033] A second-level assessment engine, configured to perform the second-level assessment upon receiving a transaction determined by the first-level assessment engine to have pending risk and passed on;

[0034] a third-level assessment engine configured to perform the third-level assessment upon receiving a transaction that has been re-determined by the second-level assessment engine as having pending risk and passed on;

[0035] The decision output module is used to generate and output a final disposal decision based on the deterministic evaluation results generated by any of the evaluation engines.

[0036] Preferably, the first-level evaluation engine is configured to perform the first-level evaluation by accessing the blacklist and whitelist and rules in the in-memory database; the second-level evaluation engine is configured to perform real-time behavioral and contextual feature calculations on the transaction data stream through a stream processing framework; the third-level evaluation engine is configured to perform the third-level evaluation by calling a graph database and a machine learning model.

[0037] Compared with the prior art, the advantages of the present invention are:

[0038] First, this invention strikes a balance between efficiency and accuracy in risk assessment. It employs a multi-layered filtering structure, leveraging lightweight static detection at the first level to quickly eliminate the vast majority of clearly risk-free or high-risk transactions, thereby ensuring a superior user experience. Only a very small number of ambiguous or suspicious transactions are "escalated" to subsequent levels for in-depth analysis, ensuring resources are precisely targeted where they are most needed. Ultimately, the system achieves the highest risk identification accuracy at the lowest average cost.

[0039] Secondly, the multi-tiered architecture of this invention significantly improves the system's interpretability. It provides layered, clear reasons for action: For transactions blocked at lower levels, the reasons are clear (e.g., "blacklist hit"); for transactions blocked at higher levels, the reasons are also relatively specific (e.g., "behavior significantly deviates from short-term profile"). This clear attribution logic greatly facilitates manual review and communication with customers.

[0040] Finally, this invention optimizes the user experience through refined handling strategies. Overly stringent, one-size-fits-all risk control strategies can generate numerous false positives, severely damaging user trust and platform revenue. This solution minimizes disruption to ordinary users by quickly approving the vast majority of legitimate transactions at the first level. Furthermore, for medium-risk transactions, the system can trigger intermediate handling strategies such as requiring secondary verification. This provides genuine users with an opportunity to prove their identity, effectively reversing legitimate transactions that might otherwise be misidentified while ensuring security. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] Figure 1 This is a flow chart of a recharge risk assessment method based on big data proposed by the present invention. DETAILED DESCRIPTION

[0042] In order to make the purpose, technical solutions and advantages of the present invention more clearly understood, the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention.

[0043] Example 1:

[0044] Refer to the following Figure 1 , a recharge risk assessment method based on big data proposed in the present invention is elaborated in detail.

[0045] A recharge risk assessment method based on big data, comprising:

[0046] Data reception and initial processing:

[0047] This process begins when the system receives a real-time top-up transaction request. In a typical application scenario, this request is transmitted to the risk assessment system of the present invention in real time by a front-end business system (such as an e-commerce website, gaming platform, or telecom operator's top-up gateway) via an API call or event posting via a message queue.

[0048] The data packet initially received usually contains the most basic transaction elements, such as: user unique identifier, recharge amount, payment tool identifier, transaction timestamp, transaction initiator's IP address and device fingerprint, etc.

[0049] First level assessment: lightweight static and high-speed testing:

[0050] After receiving a transaction request, it enters the first level of evaluation. This level's goal is to act as a high-speed, low-latency pre-filter, quickly processing the vast majority of transactions with minimal resource consumption. These transactions include both apparently compliant normal transactions and malicious transactions that meet known fraud characteristics. Specific evaluation methods for this level include:

[0051] List matching: Compare key entity information in the transaction (such as user ID, payment card identifier, IP address, device fingerprint) with various lists pre-loaded in the system. These lists include:

[0052] Blacklist: Contains information about entities that have been confirmed to be fraudulent. Transactions that appear on the blacklist should be considered high risk.

[0053] Whitelist: Contains reputable and fully trusted users or payment tools. Transactions that hit the whitelist can be considered low risk.

[0054] Grey list: Contains entities with a record of suspicious behavior but not yet confirmed as fraudulent, which can be used as a reference factor for risk assessment.

[0055] External high-risk lists: can connect and match lists of involved accounts, risky IP addresses, etc. issued by public security, judicial authorities or third-party security agencies.

[0056] Static rules and threshold judgment: compare the key attributes of the transaction with a set of predefined, simple and clear rules. For example:

[0057] Amount threshold: Determine whether the deposit amount exceeds the platform's single deposit limit (e.g., 10,000 yuan) or is below an unreasonable lower limit (e.g., 0.01 yuan).

[0058] Business logic rules: For example, check whether the recharged mobile phone number is a known virtual number segment.

[0059] High-rate detection: Based on a preset rolling time window, the transaction frequency is counted. For example:

[0060] Counts the number of recharge attempts by the same user ID in the past minute.

[0061] Counts the number of different payment cards used by the same IP address in the past 5 minutes.

[0062] The first-level evaluation engine determines the decision based on the evaluation results:

[0063] If a transaction hits a blacklist, violates a static rule (such as an amount exceeding a limit), or triggers a high-rate alarm, the first-level assessment engine directly generates an interception decision and terminates the assessment process.

[0064] If the transaction hits the whitelist and does not trigger any risk rules, the first-level evaluation engine directly generates an approval decision and terminates the evaluation process.

[0065] If the transaction hits neither the blacklist nor the whitelist and does not trigger any clear blocking or approval rules, it is determined that the risk status is unclear and the transaction is passed to the second level.

[0066] Second level assessment: behavioral and contextual anomaly detection:

[0067] If a transaction doesn't yield a clear conclusion in the first level of assessment, it will proceed to the second level for more in-depth analysis. This level analyzes transactions that pass the initial static screening but still require additional context to assess risk. This level focuses on the degree to which the transaction deviates from the user's short-term behavioral patterns and whether there are any anomalies in the immediate context of the transaction.

[0068] Understandably, at this stage, the system will query and obtain additional related data based on information such as the transaction's user ID to "enrich" the initial transaction dataset. This data includes short-term historical transaction statistics, device information, and geographic location. This data acquisition and enrichment operation is only performed on the small number of transactions that have passed the first-level assessment, thus avoiding the system overhead of querying data for all transactions.

[0069] Specific exceptions evaluated at this level include:

[0070] Short-term behavioral profile deviation: compare the current transaction with the user's recent behavioral habits. For example:

[0071] Calculate the difference between the current top-up amount and the average top-up amount over the past 24 hours and normalize it by the standard deviation. An amount that is much higher than the mean (for example, more than 3 standard deviations) may indicate an anomaly.

[0072] Contextual anomalies: Analyze the environmental information in which the transaction occurred. For example:

[0073] Analyze the geographic location of the transaction using IP address or GPS information. Is this location the same country or city as the user's first visit? Does the distance between the current location and the user's last transaction location, combined with the time interval between the two transactions, create a physically impossible movement speed?

[0074] Is the device fingerprint used in the current transaction the first time this user has used it? Has this device been associated with other accounts marked as fraudulent in the past?

[0075] Time pattern anomalies: Analyze the time characteristics of transactions. For example:

[0076] Whether the transaction occurred during a period of inactivity for the user (e.g., a user who is usually only active during the day initiates a large deposit at 3:00 AM).

[0077] The second-level assessment engine combines the outputs of the above-mentioned anomaly detection (which can be Boolean values ​​or continuous scores) into a comprehensive risk score through a preset scoring card model. Decisions are then made based on this comprehensive risk score:

[0078] If the comprehensive risk score is lower than the first low-risk threshold (e.g., 0-20 points), the second-level assessment engine directly generates an approval decision and terminates the assessment process.

[0079] If the comprehensive risk score is higher than the first high-risk threshold (e.g., above 80 points), the second-level assessment engine directly generates an interception decision and terminates the assessment process.

[0080] If the overall risk score falls within the medium risk range (e.g., 61-80), the second-tier assessment engine generates a decision requiring secondary verification. At this point, the system notifies the business platform to suspend the transaction and sends a text message verification code to the user's linked mobile phone, requiring the user to enter the code to complete the verification. If the secondary verification succeeds, the transaction is approved; if it fails, it is blocked.

[0081] If the comprehensive risk score falls into a vague and difficult-to-judge range (e.g., 21-60 points), the risk is deemed to be still undetermined and the transaction is transferred to the third level.

[0082] Third-level assessment: comprehensive portrait and correlation scoring:

[0083] If a transaction still fails to reach a clear conclusion after the second-level assessment, it will proceed to the third level for a more in-depth analysis. This level aims to conduct in-depth and comprehensive analysis of highly ambiguous transactions to reach a final conclusion. This level focuses not only on individual users but also on uncovering group fraud and complex correlation risks hidden in the data.

[0084] This layer uses the user's long-term historical data and the graph relationship data between entities to perform feature engineering, including:

[0085] Long-term behavioral profiling: Analyze users' spending and top-up habits over a longer timeframe (e.g., the past 30 days, 90 days, or even longer) to establish a stable and reliable baseline of "normal" behavior. Compare this long-term baseline to identify slow, gradual fraudulent activity.

[0086] Association network analysis: The system uses graph computing technology to build an association network that includes entities such as users, devices, IP addresses, payment cards, and mobile phone numbers. Through graph algorithms, we can find:

[0087] Group fraud: Are multiple seemingly unrelated accounts being topped up through the same device or IP address? This could indicate a fraud ring or SIM card pooling.

[0088] Risk transmission: Whether the user of the current transaction has a first- or second-degree connection with a known fraudulent account on the graph.

[0089] The third-level assessment engine uses a machine learning model (such as gradient boosting decision tree XGBoost, graph neural network GNN, etc.) to comprehensively score all the above features and generate a final risk score. The decision is then made based on the final risk score:

[0090] If the final score is below the set risk threshold, the third-level assessment engine generates an approval decision.

[0091] If the final score is higher than the set risk threshold, the third-level assessment engine generates an interception decision.

[0092] In a preferred example, if the score falls within a range that is extremely high but still requires manual confirmation, the third-level assessment engine can output a decision for manual review. The transaction will be frozen and a case will be generated and sent to the risk analyst team for further investigation.

[0093] Decision execution and system feedback:

[0094] The decision output module returns the final decision made at any level to the upstream top-up business system via API or other means. The business system then performs the corresponding action based on the decision, such as completing the payment, rejecting the transaction, popping up a secondary verification window, or placing the order in a pending review state.

[0095] The results of the assessment process, especially the final conclusion of the manual review (confirmed as fraudulent or normal), are fed back to the risk assessment system. This process can promote the continuous learning and evolution of the system, for example:

[0096] A user who is manually confirmed as a fraud will have their ID, device fingerprint and other information automatically added to the blacklist so that they can be quickly intercepted at the first level of evaluation.

[0097] A large number of confirmed fraud samples and normal samples can be used to regularly retrain the machine learning models or scorecard models used in the second-level and third-level assessments to adapt to changing fraud patterns.

[0098] Example 2:

[0099] Based on Example 1, a recharge risk assessment system based on big data is provided, including:

[0100] The data receiving module is used to interact with external business systems in real time through APIs or message queues to receive recharge transaction requests;

[0101] a first-level evaluation engine, configured to perform the first-level evaluation on all received transaction requests;

[0102] A second-level assessment engine, configured to perform the second-level assessment upon receiving a transaction determined by the first-level assessment engine to have pending risk and passed on;

[0103] a third-level assessment engine configured to perform the third-level assessment upon receiving a transaction that has been re-determined by the second-level assessment engine as having pending risk and passed on;

[0104] The decision output module is used to generate and output a final disposal decision based on the deterministic evaluation results generated by any of the evaluation engines.

[0105] Among them, the first-level evaluation engine is configured to perform the first-level evaluation by accessing the blacklist and whitelist and rules in the in-memory database; the second-level evaluation engine is configured to perform real-time behavior and context feature calculations on the transaction data stream through the stream processing framework; the third-level evaluation engine is configured to perform the third-level evaluation by calling the graph database and machine learning model.

[0106] Throughout this specification, references to terms such as "one embodiment," "example," or "specific example" indicate that the specific features, structures, materials, or characteristics described in conjunction with that embodiment or example are included in at least one embodiment or example of the present invention. In this specification, schematic representations of these terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples.

[0107] The preferred embodiments of the present invention disclosed above are intended only to help illustrate the present invention. These preferred embodiments do not exhaustively describe all details, nor do they limit the present invention to the specific embodiments described. Obviously, many modifications and variations are possible based on the content of this specification. These embodiments are selected and described in detail in this specification to better explain the principles and practical applications of the present invention, thereby enabling those skilled in the art to better understand and utilize the present invention. The present invention is limited only by the claims and their full scope and equivalents.

Claims

1. A recharge risk assessment method based on big data, characterized in that: The following steps are involved: Receive a top-up transaction request including initial transaction data from the online business platform via an application programming interface or a message queue; Performing a first-level evaluation on the recharge transaction request, wherein the first-level evaluation performs rapid filtering based on preset static data; Based on the results of the first-level assessment, a conditional judgment is performed: if the transaction hits the blacklist or violates static rules, it is judged as high risk and an interception decision is generated; If the transaction hits the whitelist and has no risk characteristics, it is judged as low risk and an approval decision is generated; in both cases, the evaluation process ends; Otherwise, the transaction is judged as pending risk and passed to the next step; If the recharge transaction request is judged as pending risk at the first level, a second level assessment is performed on it. The second level assessment detects anomalies based on the user's short-term behavior data and the transaction context data, and outputs a comprehensive risk score for the transaction; Perform a conditional judgment based on the comprehensive risk score of the second-level assessment: if the score is higher than the first high-risk threshold or lower than the first low-risk threshold, generate a corresponding approval or blocking decision and end the assessment process; If the score falls into the risk range, a secondary verification process is triggered; Otherwise, if the score falls into the fuzzy range, the transaction is again judged as risk pending and passed to the next step; If the recharge transaction request is still judged to be at risk at the second level, a third-level assessment will be performed on it. The third-level assessment will be based on a comprehensive score of the user's long-term behavioral profile data and the associated network data between entities, and a final disposal decision will be generated based on the score.

2. A recharge risk assessment method based on big data according to claim 1, characterized in that: The first level of assessment is based on quick filtering of preset static data, specifically including: List matching: Key entity information in the initial transaction data, including but not limited to user ID, payment instrument hash value, IP address, and device fingerprint, is compared with multiple lists pre-loaded into the system and stored in an in-memory database. The list database includes internally maintained blacklists, whitelists, and graylists, as well as external high-risk entity lists obtained from public security, judicial authorities, or third-party security agencies. Static rule and threshold judgment: comparing the transaction attributes in the initial transaction data with the preset static rule threshold; High-rate detection: Based on a preset short time window, high-rate statistics are performed on the transaction frequency related to the recharge transaction request.

3. A recharge risk assessment method based on big data according to claim 1, characterized in that: Before executing the second-level assessment, a data enrichment step is also included: based on the user ID in the initial transaction data, related data is queried and obtained from the risk variable library or user database to expand the initial transaction data set. The related data specifically includes the user's short-term historical transaction statistics, commonly used device information, and historical geographic location information.

4. The recharge risk assessment method based on big data according to claim 1 is characterized in that: The second-level assessment performs anomaly detection based on the user's short-term behavioral data and transaction context data, outputting a comprehensive risk score for the transaction, specifically including: Short-term behavior profile deviation analysis: Quantitatively compare the key attributes of the current transaction with the user's recent behavior habits obtained from the data enrichment step to determine the degree of behavior deviation; Contextual anomaly analysis: Analyze the geographic location information, device information, or time information of the transaction to determine contextual anomalies; Risk score synthesis: The deviation and the output results of the anomaly detection are combined into a comprehensive risk score through a preset scoring card model, and the disposal decision is determined based on the preset range in which the risk score falls.

5. The recharge risk assessment method based on big data according to claim 1 is characterized in that: The second-level evaluation generates a disposition decision that includes approval, blocking, or requiring secondary authentication.

6. A recharge risk assessment method based on big data according to claim 1, characterized in that: The third level assessment performs comprehensive profiling and relationship scoring, specifically including: Analyzing the user's long-term behavioral profile data to identify deviations from historical patterns; Using the graph neural network model, we construct an association network graph that includes multiple entities such as users, devices, IP addresses, and payment tools as nodes and transaction relationships as edges. We then analyze the network through graph algorithms to discover hidden group fraud patterns.

7. A recharge risk assessment method based on big data according to claim 1, characterized in that: The third-level assessment uses a machine learning model to comprehensively score all deep features and generate a final handling decision. Specifically, when the final score is lower than the risk threshold, an "approval" decision is output; when the final score is higher than the risk threshold, an "interception" decision is output; when the final score is lower than the risk threshold but higher than the review threshold, a "transfer to manual review" decision is output. This decision triggers the system to generate a case and push it to the risk analyst team for investigation.

8. The recharge risk assessment method based on big data according to claim 1 is characterized in that: It also includes a feedback step: the final conclusion of the "transfer to manual review" decision after confirmation by a manual analyst, or the fraud event information discovered and confirmed by other channels, is automatically fed back to the risk assessment system for: automatically adding the entity information confirmed as fraudulent to the blacklist library used for the first-level assessment; and using the confirmed fraud samples and normal transaction samples as new training data for regular retraining and iterative optimization of the machine learning model or scoring card model used in the second and third-level assessments.

9. A recharge risk assessment system based on big data, characterized in that: include: The data receiving module is used to interact with external business systems in real time through APIs or message queues to receive recharge transaction requests; a first-level evaluation engine, configured to perform the first-level evaluation on all received transaction requests; A second-level assessment engine, configured to perform the second-level assessment upon receiving a transaction determined by the first-level assessment engine to have pending risk and passed on; a third-level assessment engine configured to perform the third-level assessment upon receiving a transaction that has been re-determined by the second-level assessment engine as having pending risk and passed on; The decision output module is used to generate and output a final disposal decision based on the deterministic evaluation results generated by any of the evaluation engines.

10. A recharge risk assessment system based on big data according to claim 9, characterized in that: The first-level evaluation engine is configured to perform the first-level evaluation by accessing the blacklist and whitelist and rules in the in-memory database; the second-level evaluation engine is configured to perform real-time behavioral and contextual feature calculations on the transaction data stream through a stream processing framework; the third-level evaluation engine is configured to perform the third-level evaluation by calling a graph database and a machine learning model.

Images