A big data-based recharging risk assessment method and system

Abstract

The application relates to the technical field of security and risk control, in particular to a recharge risk assessment method and system based on big data. The method comprises the following steps: performing first-level lightweight static detection on all transaction requests, using black and white list and other means to process most of the transactions with explicit security or high risk; if the first level cannot make a clear judgment, the transaction is passed to the second level, which performs behavior and context anomaly detection by introducing the user's short-term behavior portrait and transaction context information; for suspicious transactions that cannot be qualitatively determined by the second level, the third level assessment is started, and the long-term user portrait and graph calculation correlation network are used for comprehensive scoring. Through the multi-layer filtering structure, the computing resources are allocated to transactions with different risk levels as needed, unnecessary in-depth analysis of low-risk transactions is avoided, and thus the overall processing efficiency of the system is improved while the high-risk identification accuracy is ensured.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of security and risk control, in particular to a recharge risk assessment method and system based on big data. BACKGROUND

[0002] With the vigorous development of digital economy, online recharge business has penetrated into various aspects such as e-commerce, telecommunications services, network games, and life services, and has become an indispensable payment scenario in users' daily life. However, the convenience and high frequency of online recharge business also make it a high-risk area for fraudulent activities. Fraudsters use various means, such as using stolen credit card information to make a recharge, subscribing to fraud through a recharge platform, etc., which brings huge economic losses and trust crisis to the platform and users.

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

[0004] Risk identification system based on static rules: This type of system usually has a rule engine built-in, which pre-sets a series of static and fixed logical rules according to the experience of domain experts. For example, the rule can be set as: if the IP address of the transaction initiator is located in the blacklist of known high-risk fraud areas, then the transaction is directly rejected; or if the single recharge amount exceeds a pre-set hard threshold, then a risk alert is triggered. This type of system has clear logic, easy to understand and implement, and responds quickly to known, pattern-fixed fraudulent activities. However, it has poor flexibility and adaptability. Due to the lack of in-depth understanding of user behavior and transaction context, this type of system is prone to a large number of "false positives" and "false negatives", and its risk identification accuracy and coverage cannot meet the current complex fraud countermeasures needs.

[0005] Risk assessment system based on models: In order to make up for the shortcomings of static rules, many modern risk control systems turn to advanced machine learning or deep learning models. These systems can learn and identify complex, non-linear, hidden fraud patterns by training on massive historical transaction data, thereby significantly improving the accuracy of risk identification. However, this type of technical solution also has two significant challenges. First, the training and real-time inference of complex models require huge computing resources and time. For a high-concurrency recharge system, calling a heavy deep learning model for comprehensive analysis on each transaction is difficult to bear in terms of cost and performance, which may cause transaction delays and affect user experience. Second, many advanced AI models, especially deep neural networks, have a decision-making process like a "black box", which makes it difficult to clearly explain to business personnel or regulatory agencies the basis for making a specific risk judgment. This lack of explainability feature poses obstacles to system auditing, model iterative optimization, and compliance requirements.

[0006] In summary, the prior art generally faces the problem of being difficult to achieve an ideal balance between "efficiency" and "accuracy" in risk identification. Simple rule systems are efficient but lack accuracy, while complex AI models are accurate but inefficient and cost ineffective. In addition, with the popularity of automated decision-making systems, the transparency and explainability of the decision-making process have become an important business pain point. SUMMARY

[0007] To solve the problem of the prior art in achieving an ideal balance between "efficiency" and "accuracy" in risk identification, the present application proposes a recharge risk assessment method and system based on big data.

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

[0009] receiving a recharge transaction request containing initial transaction data from an online business platform via an application programming interface or a message queue;

[0010] performing a first-level assessment on the recharge transaction request, which is based on pre-set static data for rapid filtering;

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

[0012] If the recharge transaction request is determined to be risk pending at the first level, a second-level assessment is performed, which is based on the user's short-term behavior data and the transaction's context data for anomaly detection, and outputs the comprehensive risk score of this transaction;

[0013] Based on the comprehensive risk score of the second-level assessment, a conditional judgment is made: if the score is higher than the first high-risk threshold or lower than the first low-risk threshold, the corresponding approval or blocking decision is generated and the evaluation process is ended; if the score falls within the risk interval, a secondary verification process is triggered; otherwise, if the score falls within the fuzzy interval, the transaction is again determined to be risk pending and passed to the next step;

[0014] If the recharge transaction request is still determined to be risk pending at the second level, a third-level assessment is performed, which is based on the user's long-term behavior portrait data and the correlation network data between entities for comprehensive scoring, and generates a final disposal decision according to the score.

[0015] Preferably, the first level assessment is based on preset static data for rapid filtering, specifically including:

[0016] List matching: comparing key entity information in the initial transaction data, including but not limited to user ID, hash value of payment tool, IP address, device fingerprint, with a plurality of lists preloaded in the system and stored in the memory database, wherein the list library includes an internally maintained blacklist, whitelist, gray list, and external high-risk entity list obtained from public security, judicial organs or third-party security agencies;

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

[0018] High-speed rate detection: based on a preset short time window, the transaction frequency related to the recharge transaction request is statistically analyzed at a high speed.

[0019] Preferably, before performing the second level assessment, a data enrichment step is further included: according to the user ID in the initial transaction data, querying and obtaining associated data from a risk variable library or a user database to expand the initial transaction data set, wherein the associated data specifically includes short-term historical transaction statistical information, commonly used device information, and historical geographic location information of the user.

[0020] Preferably, the second level assessment is based on user short-term behavior data and transaction context data for anomaly detection, and outputs a comprehensive risk score of this transaction, specifically including:

[0021] Short-term behavior portrait deviation analysis: quantitatively comparing key attributes of the current transaction with recent behavior habits of the user obtained from the data enrichment step to determine the behavior deviation degree;

[0022] Context anomaly analysis: analyzing the geographic location information, device information or time information of the transaction to determine the context anomaly;

[0023] Risk score synthesis: combining the deviation degree and the output result of anomaly detection through a preset scoring card model to form a comprehensive risk score, and determining the disposal decision according to the preset interval into which the risk score falls.

[0024] Preferably, the disposal decision generated by the second level assessment includes approval, interception or requiring secondary identity verification.

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

[0026] Analyzing the long-term behavior portrait data of the user to identify deviations from historical patterns;

[0027] By using a graph neural network model, a correlation network graph is constructed, which contains users, devices, IP addresses, payment tools as nodes, and transaction relationships as edges. The network is analyzed by graph algorithm to discover hidden group fraud patterns.

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

[0029] Preferably, it further includes a feedback step: the final conclusion of the "forward to manual review" decision confirmed by the artificial analyst, or the fraud event information discovered and confirmed by other channels, is automatically fed back to the risk assessment system, which is used to: automatically supplement the entity information confirmed as fraud into the blacklist library used in the first level assessment; use the confirmed fraud samples and normal transaction samples as new training data to periodically retrain and iteratively optimize the machine learning models or scoring card models used in the second and third level assessments.

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

[0031] A data receiving module for real-time data interaction with external business systems through API or message queue to receive recharge transaction requests;

[0032] A first level assessment engine for performing the first level assessment on all received transaction requests;

[0033] A second level assessment engine for performing the second level assessment when receiving transactions determined as risk pending and passed by the first level assessment engine;

[0034] A third level assessment engine for performing the third level assessment when receiving transactions determined as risk pending and passed by the second level assessment engine again;

[0035] A decision output module for generating and outputting a final disposal decision according to the deterministic assessment results generated by any of the assessment engines.

[0036] Preferably, the first level assessment engine is configured to perform the first level assessment by accessing the whitelist and rules in the in-memory database; the second level assessment engine is configured to perform real-time behavior and context feature calculation on transaction data stream by a stream processing framework; and the third level assessment engine is configured to perform the third level assessment by invoking a graph database and a machine learning model.

[0037] Compared with the prior art, the present application has the advantages that:

[0038] Firstly, the present application achieves a balance between efficiency and accuracy of risk assessment. The present application adopts a multi-level filtering structure, uses lightweight static detection of the first level to quickly process most transactions that are definitely risk-free or high-risk, thereby guaranteeing user experience. Only a small number of ambiguous and suspicious transactions are "upgraded" to subsequent levels for in-depth analysis, ensuring that resources are accurately used in the most needed scenarios, and ultimately achieving the highest risk identification accuracy at the lowest average cost on the system as a whole.

[0039] Secondly, the multi-level architecture of the present application significantly improves the explainability of the system. The present application provides layered and clear reasons for handling: transactions intercepted at the low level have clear reasons (such as "hitting the blacklist"); transactions intercepted at the high level also have relatively specific reasons (such as "behavior and short-term profile deviate significantly"). This clear attribution logic greatly facilitates manual review and customer communication.

[0040] Finally, the present application optimizes user experience through fine-grained handling strategies. Overly strict "one-size-fits-all" risk control strategies can generate a large number of "false positives", which can seriously damage user trust and platform revenue. The present application scheme quickly releases most normal transactions at the first level, minimizing interference with ordinary users. And for transactions of medium risk, the system can trigger intermediate handling strategies such as "requiring secondary verification". This provides a chance for real users to prove their identity, effectively recovering normal transactions that may be misjudged, while ensuring security. BRIEF DESCRIPTION OF DRAWINGS

[0041] Figure 1 A method flowchart of a recharge risk assessment method based on big data is proposed for the present application. DETAILED DESCRIPTION

[0042] In order to make the purpose, technical scheme and advantages of the present application clearer and more understandable, the present application will be further described in detail below in combination with the drawings and examples. It should be understood that the specific examples described herein are only used to explain the present application and do not limit the present application.

[0043] Example 1:

[0044] The following refers to Figure 1 A big data-based recharge risk assessment method is described in detail.

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

[0046] Data reception and initial processing:

[0047] The starting point of this process is that the system receives a real-time recharge transaction request. In a typical application scenario, the request is transmitted to the risk assessment system of the application in real time by the application program interface call or the message queue event publishing method of the front-end business system (such as an e-commerce website, a game platform, or a recharge gateway of a telecommunications operator).

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

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

[0050] After receiving the transaction request, the first-level assessment is entered. The goal of this level is to serve as a high-speed, low-latency pre-filter to quickly process most transactions with extremely low resource consumption. These transactions include obviously compliant normal transactions and malicious transactions that meet known fraud characteristics. The specific ways of this level assessment include:

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

[0052] Blacklist: contains entity information that has been confirmed as fraudulent. Transactions that hit the blacklist should be considered high-risk.

[0053] Whitelist: contains users or payment tools with good reputation and full trust. Transactions that hit the whitelist can be considered low-risk.

[0054] Gray list: contains entities with suspicious behavior records but not yet confirmed as fraudulent, which can be used as a reference factor for risk judgment.

[0055] External high-risk list: can be connected and matched with lists of accounts involved in cases, risk IPs, etc. published by public security, judicial organs or third-party security institutions.

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

[0057] Amount threshold: Determine if the amount of the transaction exceeds the upper limit set by the platform (e.g., 10,000 yuan) or falls below an unreasonable lower limit (e.g., 0.01 yuan).

[0058] Business logic rules: For example, check if the mobile number of the recharge is a known virtual number segment.

[0059] High-rate detection: Based on a pre-set rolling time window, the frequency of transactions is counted. For example:

[0060] Count the number of recharge attempts by the same user ID within the past 1 minute.

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

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

[0063] If the transaction hits the blacklist, or violates a certain static rule (such as amount exceeding the limit), or triggers a high-rate alarm, the first level evaluation engine directly generates an interception decision and terminates the evaluation 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 does not hit the blacklist or the whitelist, and does not trigger any explicit interception or approval rules, it is determined that the risk situation is not clear, and the transaction is passed to the second level.

[0066] Second level evaluation: Behavior and context anomaly detection:

[0067] If the transaction cannot be clearly determined in the first level evaluation, it will enter the second level for more in-depth analysis. The goal of this level is to analyze transactions that have passed the initial static screening but still need to be combined with more context information to determine the risk. This level focuses on the degree of deviation of transaction behavior from the user's short-term behavior pattern, and whether the immediate context of the transaction is abnormal.

[0068] It can be understood that at this stage, the system will query and obtain more associated data according to the user ID and other information of the transaction, to "enrich" the initial transaction data set. These data include the user's short-term historical transaction statistics, device usage information, geographic location information, etc. This data acquisition and enrichment operation is only performed on a small number of transactions that have passed the first level evaluation, thereby avoiding the system overhead caused by querying all transactions.

[0069] The specific anomalies 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 its average top-up amount in the past 24 hours, and normalize it with the standard deviation. An amount much higher than the mean (e.g., more than 3 standard deviations) may indicate an anomaly.

[0072] Contextual anomaly: Analyze the environmental information in which the transaction occurs. For example:

[0073] Resolve the geographical location of the transaction through IP address or GPS information. Is this location the first country or city the user has ever appeared in? Is the distance between the current location and the user's last transaction location combined with the time interval between the two transactions a physically impossible speed of movement?

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

[0075] Temporal pattern anomaly: Analyze the time characteristics of the transaction. For example:

[0076] Does the transaction occur during the user's inactive period (e.g., a user who is usually active during the day initiates a large top-up at 3 a.m.)?

[0077] The second-level evaluation engine combines the outputs of the above types of anomaly detection (which can be Boolean values or continuous scores) through a pre-set scoring card model to form a comprehensive risk score. Based on the comprehensive risk score, the decision is determined:

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

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

[0080] If the comprehensive risk score falls within a medium-risk interval (e.g., 61-80 points), the second-level evaluation engine generates a decision requiring secondary verification. At this time, the system notifies the business platform to suspend the transaction and sends an SMS verification code to the user's bound mobile phone, requiring the user to input it to complete the verification. Secondary verification success approves the transaction, and failure intercepts.

[0081] If the comprehensive risk score falls within a fuzzy, difficult-to-judge interval (e.g., 21-60 points), it is determined that the risk is still pending, and the transaction is passed to the third level.

[0082] Third-level evaluation: Comprehensive profiling and association scoring:

[0083] If the second level evaluation still cannot reach a clear conclusion, it will enter the third level for more in-depth analysis. The goal of this level is to conduct a deep and comprehensive mining analysis on highly ambiguous transactions to make a final judgment. This level not only focuses on individual users, but also focuses on discovering group fraud and complex correlation risks hidden behind the data.

[0084] This level uses long-term historical data of users and graph relationship data between entities for feature engineering, specifically including:

[0085] Long-term behavior profiling: Analyze the user's consumption and recharge habits over a longer time span (such as the past 30 days, 90 days, or even longer) to establish a stable and reliable "normal" behavior baseline. Compare with this long-term baseline to discover slow and gradual fraudulent behavior.

[0086] Correlation network analysis: The system uses graph computing technology to build a correlation network containing entities such as users, devices, IP addresses, payment cards, and mobile phone numbers. Through graph algorithms, it can discover:

[0087] Gang fraud: Whether multiple seemingly unrelated accounts initiate recharges through the same or a small number of devices, IP addresses? This may point to a fraud gang or SIM card pool fraud.

[0088] Risk transmission: Does the user of the current transaction have a one or two degree correlation with a known fraudulent account in the graph?

[0089] The third level evaluation engine calls a machine learning model (such as gradient boosting decision tree XGBoost, graph neural network GNN, etc.) to comprehensively score all the above features, generating a final risk score. And according to the final risk score, determine the decision:

[0090] If the final score is lower than the set risk threshold, the third level evaluation engine generates an approval decision.

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

[0092] In a preferred example, if the score falls within a certain extremely high but still requires manual confirmation interval, the third level evaluation engine can output a manual review decision. The transaction will be frozen and a case will be generated to push to the risk analyst team for in-depth investigation.

[0093] Decision execution and system feedback:

[0094] The decision output module returns the final treatment decision generated by any level to the upstream recharge business system through API or other means. The business system performs corresponding operations according to the decision, such as completing payment, rejecting the transaction, popping up a secondary verification window, or placing the order in a pending review state.

[0095] Wherein, the results of the evaluation process, especially the final conclusion of manual review (confirmed as fraud or confirmed as normal), will be fed back to the risk assessment system. This process can facilitate the continuous learning and evolution of the system, for example:

[0096] A user confirmed as fraud by manual review will have their ID, device fingerprint, and other information automatically added to the blacklist, so that they can be quickly intercepted during the first level of evaluation.

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

[0098] Embodiment 2:

[0099] Based on Embodiment 1, a big data-based recharge risk assessment system is provided, comprising:

[0100] A data receiving module for real-time data interaction with external business systems through API or message queues to receive recharge transaction requests;

[0101] A first level evaluation engine for performing the first level evaluation on all received transaction requests;

[0102] A second level evaluation engine for performing the second level evaluation when receiving transactions determined as risk pending and passed by the first level evaluation engine;

[0103] A third level evaluation engine for performing the third level evaluation when receiving transactions determined as risk pending and passed by the second level evaluation engine again;

[0104] A decision output module for generating and outputting a final treatment decision based on the deterministic evaluation results generated by any of the evaluation engines.

[0105] Wherein, the first level evaluation engine is configured to access the blacklist and rules in the in-memory database to perform the first level evaluation; the second level evaluation engine is configured to perform real-time behavior and context feature calculation on transaction data streams through a stream processing framework; and the third level evaluation engine is configured to call a graph database and machine learning models to perform the third level evaluation.

[0106] In the description of the specification, reference to "one embodiment", "an example", "a specific example" or the like means that a particular feature, structure, material or characteristic described in connection with the embodiment or example is included in at least one embodiment or example of the application. The appearances of the phrases "in one embodiment", "an example", "a specific example" or the like in various places in the specification are not necessarily referring to the same embodiment or example. Furthermore, the particular features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0107] The preferred embodiments of the application disclosed above are only to help explain the application. The preferred embodiments do not describe all the details of the application and limit the application to the specific embodiments described. Obviously, many modifications and variations can be made in light of the contents of the specification. The specification selects and specifically describes these embodiments in order to better explain the principles and practical application of the application, so that those skilled in the art can well understand and utilize the application. The application is limited only by the claims and their full scope and equivalents.

Claims

1. A big data based risk assessment method for recharging, characterized in that, The method comprises the following steps: receiving a recharge transaction request containing initial transaction data from an online business platform via an application program interface or a message queue; performing a first-level evaluation on the recharge transaction request, which is based on preset static data for rapid filtering; based on the result of the first-level evaluation, making a conditional judgment: if the transaction hits a blacklist or violates static rules, determining it as high risk and generating an interception decision; if the transaction hits a whitelist and has no risk features, determining it as low risk and generating an approval decision; in both cases, ending the evaluation process; otherwise, determining the transaction as risk pending and passing it to the next step; if the recharge transaction request is determined as risk pending in the first level, performing a second-level evaluation on it, which is based on short-term behavioral data of the user and contextual data of the transaction for anomaly detection, and outputting a comprehensive risk score of this transaction; based on the comprehensive risk score of the second-level evaluation, making a conditional judgment: if the score is higher than a first high-risk threshold or lower than a first low-risk threshold, generating a corresponding approval or interception decision and ending the evaluation process; if the score falls into a risk interval, triggering a secondary verification process, at which point the system notifies the business platform to suspend the transaction and sends an SMS verification code to the user's bound mobile phone, requiring the user to input it to complete verification, and if the secondary verification is successful, approving the transaction, otherwise, if the secondary verification fails, intercepting the transaction; otherwise, if the score falls into a fuzzy interval, determining the transaction as risk pending again and passing it to the next step; if the recharge transaction request is still determined as risk pending in the second level, performing a third-level evaluation on it, which is based on long-term behavioral portrait data of the user and correlation network data between entities for comprehensive scoring, and generating a final disposal decision according to the score. 2.The method of claim 1, wherein, The first-level evaluation is based on preset static data for rapid filtering, specifically including: list matching: comparing key entity information in the initial transaction data, including but not limited to user ID, hash value of payment tool, IP address, and device fingerprint, with a list library preloaded in the system and stored in a memory database, wherein the list library includes an internally maintained blacklist, whitelist, and gray list, and an external high-risk entity list obtained from public security, judicial organs, or third-party security agencies; static rule and threshold judgment: comparing transaction attributes in the initial transaction data with preset static rule thresholds; high-speed rate detection: based on a preset short-time window, performing high-speed rate statistics on transaction frequency related to the recharge transaction request. 3.The method of claim 1, wherein, Before performing the second-level evaluation, a data enrichment step is further included: querying and obtaining associated data from a risk variable library or a user database according to the user ID in the initial transaction data, to expand the initial transaction data set, wherein the associated data specifically includes short-term historical transaction statistical information, commonly used device information, and historical geographic location information of the user. 4.The method of claim 1, wherein, The second-level evaluation is based on short-term behavioral data of the user and contextual data of the transaction for anomaly detection, and outputs a comprehensive risk score of this transaction, specifically including: Short-term behavioral profile deviation analysis: quantitatively compare the key attributes of the current transaction with the user's recent behavioral habits obtained from the data enrichment step to determine the degree of behavioral deviation; Context anomaly analysis: analyze the geographic location information, device information, or time information of the transaction to determine the context anomaly; Risk score synthesis: combine the deviation degree and the output of anomaly detection through a pre-set scoring card model to synthesize a comprehensive risk score, and determine the disposal decision according to the pre-set interval into which the risk score falls. 5.The method of claim 1, wherein, The disposal decision generated by the third level assessment includes approval, interception, or requiring secondary identity verification. 6.The method of claim 1, wherein, The third level assessment performs comprehensive profiling and correlation scoring, specifically including: Analyzing the user's long-term behavioral profile data to identify deviations from historical patterns; Using a graph neural network model, a correlation network graph is constructed containing users, devices, IP addresses, and payment tools as nodes and transaction relationships as edges, and the network is analyzed through graph algorithms to discover hidden group fraud patterns.

7. The method of claim 1, wherein, The third level assessment generates a final disposal decision by calling a machine learning model to comprehensively score all deep features, specifically including: when the final score is below the risk threshold, outputting an "approval" decision; when the final score is above the risk threshold, outputting an "interception" decision; when the final score is below the risk threshold but above the review threshold, outputting a "forward to manual review" decision, which triggers the system to generate a case and push it to the risk analyst team for investigation. 8.The method of claim 7, wherein, It also includes a feedback step: the final conclusion of the "forward to manual review" decision confirmed by the artificial analyst, or the fraud event information discovered and confirmed by other channels, is automatically fed back to the risk assessment system, which is used to: automatically supplement the entity information confirmed as fraud into the blacklist library used by the first level assessment; confirmed fraud samples and normal transaction samples are used as new training data to periodically retrain and iteratively optimize the machine learning models or scoring card models used in the second and third level assessments.

9. A big data based recharge risk assessment system for implementing a big data based recharge risk assessment method according to claims 1-8, characterized in that, It includes: A data receiving module for real-time data interaction with external business systems through API or message queue to receive recharge transaction requests; A first level assessment engine for performing the first level assessment on all received transaction requests; A second level assessment engine for performing the second level assessment when receiving transactions determined by the first level assessment engine as risk pending and passed; A third level assessment engine for performing the third level assessment when receiving transactions determined by the second level assessment engine as risk pending and passed again; A decision output module for generating and outputting a final disposal decision based on the deterministic assessment results generated by any of the assessment engines. 10.The big data based recharge risk assessment system according to claim 9, wherein, The first level assessment engine is configured to perform the first level assessment by accessing the whitelist and blacklist and rules in a memory database; the second level assessment engine is configured to perform real-time behavior and context feature calculation on a transaction data stream through a stream processing framework; and the third level assessment engine is configured to perform the third level assessment by invoking a graph database and a machine learning model.

Images