Platform payment risk control method and system based on new retail e-commerce

Abstract

The invention discloses a platform payment risk control method and system based on new retail e-commerce, and relates to the technical field of network transaction security control, and the method comprises the steps: collecting multi-dimensional data containing user credit data and transaction scene data in real time, building a risk control evaluation model through a machine learning algorithm, and carrying out the risk control evaluation model; the method comprises the following steps: performing weighted scoring on collected multi-dimensional data to obtain a user and transaction combination risk level, dividing the user and transaction combination risk level into a low risk level, a middle risk level and a high risk level, dynamically configuring risk control parameters according to different risk levels, performing real-time monitoring on a transaction whole process, and recording a transaction success rate and a fund safety rate after parameter adjustment. According to the method and the system, through online and offline fusion and data driving of new retail, dynamic adjustment can be performed in combination with user credit and transaction scenes, and the user experience is improved while transaction risk control is guaranteed.

Description

Technical Field

[0001] This invention belongs to the field of network transaction security control technology, specifically relating to a platform payment risk control method and system based on new retail e-commerce. Background Technology

[0002] Platform payment is an indispensable process in e-commerce activities. Online fund settlement services through e-commerce platforms or third-party payment platforms connect payers, payees, and banks or financial institutions to achieve convenient online transactions. In some scenarios, funds need to be temporarily held in the platform account, such as in the escrow transaction model, and then transferred to the payee after the transaction is confirmed, so as to achieve a balance between the two parties and the risks. To enhance transaction security, the platform's payment risk control methods currently include multi-factor authentication and payment limit control. The registration module collects basic user information to create an identity profile, and the password authentication module verifies login credentials, ultimately achieving precise identity verification. During registration, basic data such as address, contact number, and identity information are collected. Login passwords support three forms: numeric password, fingerprint password, and facial recognition. Upon login, the password authentication module compares the entered password with the registered and stored information to verify consistency and ensure user authenticity. Payment limit control utilizes the online payment platform's cloud server's built-in payment limit setting function, forcibly setting the maximum amount for a single payment and the maximum amount for a single day, limiting the scope of risk exposure from the transaction scale and preventing large-scale one-time losses.

[0003] However, the core parameters of existing risk control solutions (payment limit and fund holding period, the latter being common in escrow transactions and typically set at 1 week to 3 months) are all fixed values. They are not dynamically adjusted based on user credit ratings (such as high-quality users versus newly registered users) and transaction scenario characteristics (such as product type, purchase frequency, and historical cooperation records between the transacting parties). This leads to a disconnect between risk control and actual needs: low-risk transactions (such as small-amount daily necessities purchases) suffer from delayed fund arrival times due to fixed holding periods, affecting capital turnover efficiency; high-risk transactions (such as large-amount luxury goods purchases) require users to initiate payments multiple times due to fixed payment limits, which not only increases operational costs but may also lead to transaction interruptions due to repeated risk control interception of multiple transactions. This fails to meet user needs and restricts the platform's transaction coverage. Summary of the Invention

[0004] The purpose of this invention is to provide a platform payment risk control method and system based on new retail e-commerce. By integrating online and offline channels and using data-driven approaches, the system can dynamically adjust based on user credit and transaction scenarios, thereby improving user experience while ensuring transaction risk control and solving the problems mentioned in the background.

[0005] To achieve the above objectives, the present invention adopts the following technical solution: A platform payment risk control method based on new retail e-commerce includes the following steps: S1. Real-time collection of multi-dimensional data including user credit data and transaction scenario data. User credit data includes historical transaction performance records, third-party credit scores, and platform membership levels; transaction scenario data includes product category risk levels, consumption frequency, historical cooperation between the transacting parties, and payment terminal security coefficient. S2. Construct a risk control assessment model through machine learning algorithms, weight score the collected multi-dimensional data, obtain the risk level of users and trading portfolios, and divide the risk level of users and trading portfolios into three risk levels: low, medium and high. S3. Dynamically configure risk control parameters according to different risk levels, specifically: The risk control parameters for low-risk configurations are to shorten the temporary holding period of funds and increase the payment limit; The risk control parameters for medium-risk configurations are the maintenance baseline parameters; The risk control parameters configured for high-risk scenarios include extending the temporary storage period, triggering additional identity verification, and dynamically adjusting the payment limit. S4. Real-time monitoring of the entire transaction process, recording the transaction success rate and capital security rate after parameter adjustments, and iteratively optimizing the parameters of the risk control assessment model based on real-time monitoring data to achieve matching between risk control parameters and actual risks.

[0006] Preferably, when collecting multi-dimensional data, the platform system for acquiring the data is first determined according to the type of data to be collected, then the real-time acquisition interface is defined according to the platform system, and finally the data acquired by the real-time acquisition interface is preprocessed and stored.

[0007] Preferably, when defining the real-time data collection interface, the internal data interface synchronizes incremental data from the transaction system and membership system in real time through the CDC tool, calls the real-time query API of a third-party credit reporting agency through the external data interface to obtain the user's credit score, and then collects the security information of the payment terminal through the SDK.

[0008] The preferred risk control assessment model construction process is as follows: A1. Extract core features from the structured feature dataset and construct a feature matrix. The core features include user credit features containing credit scores and fulfillment rates, as well as scenario features containing product risk scores and terminal security coefficients. A2. The information gain algorithm is used to calculate the weights of user credit features and scenario features respectively; A3. Use the logistic regression algorithm to build a binary classification model, use historical data as the training set, and optimize the parameters of the binary classification model through gradient descent. A4. Based on the risk probability output by the binary classification model, a comprehensive score is calculated by combining the feature weighting results, and a level threshold is set to classify low, medium and high risk levels.

[0009] Preferably, in step A3, the binary classification model construction process is as follows: A31. Data preparation and division: Using historical transaction data as the dataset, each sample contains core features and labels. The data is divided into training set, validation set and test set in a 7:2:1 ratio. A32. Define the feature vector, label, and model parameters of a single sample as a weight vector and bias term; A33. Initialize the model parameters, and initialize the bias term to 0; A34. Calculate the linear score through linear regression, and then map it to probability using the sigmoid function; A35. Use the cross-entropy loss function to measure the error between the predicted probability and the true label; A36. Update the parameters calculated during forward propagation by minimizing the loss function; A37. Repeat A34-A36 until the loss value of the loss function is minimized to the optimal value.

[0010] Preferably, before dynamically configuring risk control parameters, a risk control parameter library should be established first, and then a real-time decision engine should be developed for dynamic configuration. The real-time decision engine is based on a rule engine to build a mapping logic between risk levels and parameters. The establishment of the risk control parameter library includes configuration of low-risk, medium-risk, and high-risk risk control parameters.

[0011] The preferred process for constructing the mapping logic between risk level and parameters is as follows: B1. When a user submits a payment request on the new retail platform, the payment system simultaneously sends a risk parameter configuration request to the real-time decision engine. B2. The decision engine automatically retrieves preset rules from the user and transaction portfolio risk level and risk control parameter library; B3. The payment system must complete the process from request initiation to parameter return within 100ms to meet the low latency requirements of payment scenarios. This is achieved through the efficient matching capabilities of the rule engine and its interaction with the payment system's interface.

[0012] The preferred approach for real-time monitoring of the entire transaction process is as follows: F1. Determine monitoring priorities from three dimensions: safety goals, experience goals, and efficiency goals; F2. Construct a three-level indicator library based on monitoring priorities. The three-level indicator library includes outcome indicators, process indicators, and root cause analysis indicators. F3. Build a monitoring panel using Prometheus + Grafana, and display it in modules according to risk level and indicator type.

[0013] Preferably, the parameter iterative optimization process for the risk control assessment model is as follows: G1. Set iteration trigger conditions, which include active and passive triggers. Active triggering occurs when monitoring indicators fail to meet standards, risk patterns change, or data accumulation reaches a threshold. Passive triggering occurs when business needs change or monitoring policies are adjusted. G2. Select 3 months of labeled data and divide them into an iterative training set and an iterative test set in a 7:3 ratio to ensure that the data distribution is consistent with the current business scenario. If new risk factors are found, add the feature of the payment period risk coefficient during feature extraction and recalculate the feature weights. G3. Retrain the risk control assessment model using the iterative training set, and perform dual-dimensional verification on the trained model. If both dual-dimensional verifications meet the standards, proceed to A / B testing. If the dual-dimensional verifications fail to meet the standards, perform root cause analysis and secondary optimization. G4. Gradually expand the coverage of the new model by 20%-50%-100%, with a 24-hour interval between each step. Use monitoring tools to continuously track the indicators and review the tracked indicators every week. If the review finds that the indicators have fallen, immediately trigger the next iteration and re-execute G1-G3.

[0014] Based on the above-described platform payment risk control method for new retail e-commerce, the present invention also provides a platform payment risk control system for new retail e-commerce, including: a data acquisition module, which collects multi-dimensional data containing user credit data and transaction scenario data in real time, and performs standardized processing on the multi-dimensional data; The risk assessment module builds a risk control assessment model based on machine learning algorithms. It also receives standardized data from the data acquisition module, extracts key variables, and assigns weighted scores to each variable. Finally, based on the scoring results, users and trading portfolios are divided into three risk levels: low, medium, and high. The risk control decision module transforms risk assessment results into specific risk control strategies and dynamically configures risk control parameters based on these strategies. The monitoring and iteration module monitors the entire transaction process in real time, records the transaction success rate and fund security rate after parameter adjustments, and iteratively optimizes the parameters of the risk control assessment model based on real-time monitoring data.

[0015] The payment risk control method and system proposed in this invention based on new retail e-commerce platforms have the following advantages compared with existing technologies: 1. This invention first collects user credit and transaction scenario data in real time, then uses a machine learning model to classify user and transaction combinations into low, medium, and high risk levels. Finally, it dynamically configures the fund holding period and payment limit based on the level, and combines real-time monitoring data to iterate the parameters of the risk control assessment model to achieve matching between risk control parameters and actual parameters. When risk control parameters are dynamically configured, the fund holding period for low-risk transactions is shortened, accelerating the merchant's capital turnover; high-risk transactions are managed in a tiered manner instead of a one-size-fits-all limit, reducing the cost of split payment operations and the risk of misjudgment, improving the accuracy of risk control, increasing the capital turnover efficiency of low-risk transactions, increasing the success rate of high-risk transactions, and reducing the risk of large-scale capital loss. This approach balances platform security and user experience, and expands the platform's transaction coverage. 2. This invention enables the system to dynamically adapt to changes in user behavior and expansion of business scenarios through the cooperation of a data acquisition module, a risk assessment module, a risk control decision-making module, and a monitoring iteration module, thereby avoiding a disconnect between risk control strategies and actual needs. Attached Figure Description

[0016] Figure 1 A flowchart of a platform payment risk control method according to an embodiment of the present invention is shown; Figure 2 A flowchart illustrating the construction process of a risk control assessment model according to an embodiment of the present invention is shown. Figure 3 A flowchart illustrating the mapping logic construction process between risk levels and parameters according to an embodiment of the present invention is shown. Figure 4 A block diagram of a platform payment risk control system according to an embodiment of the present invention is shown. Detailed Implementation

[0017] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. The specific embodiments described herein are merely used to explain the present invention and are not intended to limit the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0018] This invention provides, for example Figure 1-3 The method for platform payment risk control based on new retail e-commerce, as shown, includes the following steps: S1. Real-time collection of multi-dimensional data including user credit data and transaction scenario data. User credit data includes historical transaction performance records, third-party credit scores, and platform membership levels; transaction scenario data includes product category risk levels, consumption frequency, historical cooperation between the transacting parties, and payment terminal security coefficient. When collecting multi-dimensional data, the platform system for acquiring the data is first determined based on the data collection type. Then, the real-time acquisition interface is defined according to the platform system. Finally, the data acquired by the real-time acquisition interface is preprocessed and stored. The platform system includes the platform's internal transaction system, third-party credit reporting agency APIs, a product management system, user behavior logs, historical data of both parties in a transaction, and a terminal security system. The platform's internal transaction system is used to obtain historical transaction performance records and membership levels. The third-party credit reporting agency APIs include Sesame Credit and Baihang Credit. The product management system is used to obtain the risk level of product categories, such as luxury goods and virtual goods, which are preset to high risk. User behavior logs are used to obtain consumption frequency, which can be statistically analyzed by day, week, and month. Historical data of both parties in a transaction is used to obtain expert store ratings, the number of historical transactions between buyers and sellers, and disputes. The terminal security system is used to obtain the IP address and fingerprint of the payment device. When defining the real-time data collection interface, the internal data interface synchronizes incremental data from the transaction system and membership system in real time through the CDC tool, and calls the real-time query API of the third-party credit reporting agency through the external data interface to obtain the user's credit score. Then, the SDK collects the security information of the payment terminal, such as the device instruction generation tool.

[0019] When preprocessing and storing the acquired data, first clean the missing and outlier values ​​in the data, and then normalize the processed data of different magnitudes to generate a structured feature dataset.

[0020] By covering user credit and transaction scenarios with multi-dimensional data, misjudgments caused by a single dimension are avoided. Real-time data collection ensures data timeliness and meets the low-latency requirements of payment scenarios.

[0021] S2. Construct a risk control assessment model through machine learning algorithms, weight score the collected multi-dimensional data, obtain the risk level of users and trading portfolios, and divide the risk level of users and trading portfolios into three risk levels: low, medium and high. The risk control assessment model construction process is as follows: A1. Extract core features from the structured feature dataset and construct a feature matrix. The core features include user credit features containing credit scores and fulfillment rates, as well as scenario features containing product risk scores and terminal security coefficients. A2. The information gain algorithm is used to calculate the weights of user credit features and scenario features respectively. The formula for the information gain algorithm is: , in, Y represents the information gain value, and Y represents the number of categories in the dataset. Let X be the probability of a sample of class k in the dataset, and V be the number of possible values ​​for feature X. This is a subset of the dataset where feature X takes the value v. For a subset of datasets The number of samples, The number of samples in the original dataset D. For a subset of datasets Information entropy.

[0022] A3. Use the logistic regression algorithm to build a binary classification model, use historical data as the training set, and optimize the parameters of the binary classification model through gradient descent. The process for constructing a binary classification model is as follows: A31. Data preparation and division: Using historical transaction data as the dataset, each sample contains core features and labels. The data is divided into training set, validation set and test set in a 7:2:1 ratio. A32. Define the feature vector of a single sample as x=[x1,x2,…,xn], the label as y∈{0,1}, and the model parameters as the weight vector [w1,w2,…,wn] and the bias term b; A33. Initialize the model parameters by setting the weight vector w to small random numbers, such as uniformly distributed in [-0.01, 0.01], to avoid gradient vanishing due to zero initialization, and initialize the bias term b to 0. A34. The linear score is calculated by linear regression and then mapped to probability by the sigmoid function. The formula for calculating the linear score is: Z=w1*x1+w2*x2+…+wn*xn+b, where Z is the linear score value. The formula for calculating the prediction probability is: ,in, Let y = 1 represent the probability that the sample is of high risk. Let z be the sigmoid function, z be the linear score, and e be the natural constant. A35. The cross-entropy loss function is used to measure the error between the predicted probability and the true label. The error calculation formula is as follows: , in, Let m be the total number of samples in the training set. Let i be the true label of the i-th sample. Let be the predicted probability of the i-th sample; A36. Update the parameters calculated during forward propagation by minimizing the loss function; A37. Repeat A34-A36 until the loss value of the loss function is minimized to the optimal value; A4. Based on the risk probability output by the binary classification model, a comprehensive score is calculated by combining the feature weighting results, and a level threshold is set to classify low, medium and high risk levels. When setting the risk level thresholds, the low-risk level threshold is set to a risk probability of less than 0.3, the medium-risk level threshold is set to a risk probability of 0.3-0.7, and the high-risk level threshold is set to a risk probability of greater than 0.7. By outputting the risk probability of users and trading portfolios through the risk control assessment model, accurate risk stratification of users and trading portfolios can be achieved, avoiding misjudgments in risk control with a one-size-fits-all approach. S3. Dynamically configure risk control parameters according to different risk levels, specifically: The risk control parameters for low-risk configurations are to shorten the temporary holding period of funds and increase the payment limit; The risk control parameters for medium-risk configurations are the maintenance baseline parameters; The risk control parameters configured for high-risk scenarios include extending the temporary storage period, triggering additional identity verification, and dynamically adjusting the payment limit. Before dynamically configuring risk control parameters, a risk control parameter library must be established, and then a real-time decision engine must be developed for dynamic configuration. The real-time decision engine is based on a rule engine to build a mapping logic between risk levels and parameters to ensure consistency in all aspects. The process of building the mapping logic between risk levels and parameters is as follows: B1. When a user submits a payment request on the new retail platform, the payment system simultaneously sends a risk parameter configuration request to the real-time decision engine. B2. The decision engine automatically retrieves preset rules from the user and transaction portfolio risk level and risk control parameter library; B3. The payment system must complete the process from request initiation to parameter return within 100ms to meet the low latency requirements of payment scenarios. This is achieved through the efficient matching capabilities of the rule engine and its interaction with the payment system's interface.

[0023] The establishment of the risk control parameter library includes the configuration of low-risk, medium-risk, and high-risk risk control parameter libraries. The configuration process for the low-risk risk control parameter library is as follows: C1. Bind a rule ID to the low-risk level in the risk control parameter library. The content of the rule ID is: IF Risk Level = Low Risk → THEN Fund Temporary Storage Period = 1h, Payment Limit = User Account Default Limit, Identity Verification = No Verification Required. C2. Link user credit tags to ensure accurate matching of low-risk users, such as those with a historical performance rate of ≥98% and a third-party credit score of ≥800 who are VIP members of the platform; C3. After the payment system initiates a request, the decision engine first obtains the risk level of the transaction and quickly matches the ID address using the rule ID; C4. The decision engine calls the user account system interface to obtain the user's default payment limit and confirms that no adjustment is needed. C5 completes rule matching within 10ms, generates low-risk parameter configuration results and returns them to the payment system. The low-risk parameter configuration results are: funds temporarily stored for 1 hour, unlimited payment and no verification required. C6. After receiving the parameter configuration results, the payment system will directly redirect to the payment channel without popping up any verification page; C7. After a user makes a successful payment, the funds are temporarily held in the platform's transitional account and frozen for only 1 hour. After 1 hour, the funds will be automatically transferred to the merchant. If a user appeal occurs within 1 hour, such as an erroneous payment, the transfer will be suspended and manual review will be triggered. Otherwise, the settlement will be completed on time. C8. Record and archive the execution results. The execution results record includes the transaction ID, risk level, parameter configuration, fund transfer time, and user feedback. For example, a VIP user on the platform purchases daily necessities using a frequently used device. If there are no fulfillment issues in the past 100 transactions, a low-risk process is triggered. The merchant receives the funds within one hour of payment, and the user does not need to take any additional action.

[0024] The configuration process for the medium-risk risk control parameter library is as follows: D1. Bind rule ID, such as Rule_M001. The content of the ID rule is: IF Risk Level = Medium Risk → THEN Funds Temporary Holding Period = 24 hours, Payment Limit = 50,000 RMB / transaction, Identity Verification = SMS Verification; D2. Associate scenario tags to ensure accurate coverage of medium-risk scenarios, such as new users (registered for less than 30 days) + purchasing home appliances (category risk level 0.5) + historical transaction count <10. D3. After the decision engine obtains the medium risk level, it matches the ID address, such as Rule_M001, and first verifies the payment amount: if the user's current payment amount is 30,000 yuan (≤50,000 yuan upper limit), no adjustment is needed; if it is 60,000 yuan (>50,000 yuan), a split payment prompt will be automatically triggered. For example, if the single payment limit is 50,000 yuan, it can be split into 2 payments. D4. The engine calls the SMS gateway interface to generate a temporary verification code. The verification code is valid for 5 minutes, and the command requiring SMS verification is synchronized to the payment system. D5. Matching and verification code generation are completed within 30ms. The medium-risk parameter configuration result is returned. The medium-risk configuration result is that funds are temporarily stored for 24 hours and the payment limit is 50,000. SMS verification is required. D6. The payment system will pop up an SMS verification window. The user must enter the verification code and pass the verification before being redirected to the payment channel. If the verification code is incorrect (≤3 retries), the process will continue if the retries are successful; otherwise, the payment request will be frozen (it can be re-initiated after 1 hour). D7. After successful payment, the funds will be temporarily held in the platform's transition account for 24 hours. During this period, the platform will monitor for any risks such as counterfeit goods or fraudulent transactions. If no abnormalities are found, the funds will be transferred to the merchant after 24 hours. D8. Record and archive the execution results, and track key indicators, namely the SMS verification pass rate under the medium risk level. For example, the target is ≥95%. If it is lower than 90%, it is necessary to investigate whether it is a verification code delay issue.

[0025] For example, a new user who has been registered for 15 days purchases a refrigerator worth 30,000 yuan (of medium risk) using their usual mobile phone. With only two small transactions in the past, the medium risk process is triggered. After completing SMS verification, the payment is made and the funds arrive in the merchant's account 24 hours later.

[0026] The configuration process for the high-risk risk control parameter library is as follows: E1. Bind rule ID, rule content: IF risk level = high risk → THEN fund temporary storage period = 72h, payment limit = MAX (user's average transaction amount in the past 30 days × 50%, 1000 yuan), identity verification = face + bank card four elements; E2. Associate with high-risk tags, such as new devices from other locations (IP address does not match the usual location + device fingerprint does not match) + purchase of luxury goods (category risk level 0.9) + third-party credit score <600, to avoid misjudgment; E3. After the decision engine obtains the high-risk level, it processes it in the following two steps: 1) Calculate the payment limit: Call the user behavior database to extract the average payment amount of valid transactions in the past 30 days. For example, if there are 3 transactions in the past 30 days totaling 30,000 yuan, with an average payment of 10,000 yuan per transaction, then the current limit = 10,000 yuan × 50% = 5,000 yuan; if the user has no transactions in the past 30 days (new user), then the minimum limit of 1,000 yuan preset in the parameter library will be executed. 2) Trigger multiple verifications: Call the platform's facial recognition interface (such as connecting to Baidu AI and SenseTime) and the bank card four-factor authentication interface (connecting to UnionPay) to generate verification tasks; E4. The upper limit calculation and verification interface call is completed within 80ms, and the high-risk parameter configuration result is returned. The high-risk parameter configuration result is that the funds are temporarily stored for 72 hours and the payment limit is 5,000 yuan. Multiple verifications are required. E5. Enter the verification process, which first guides the user to complete facial recognition. Facial recognition requires real-time capture and comparison with the real-name authentication photo reserved on the platform. The pass rate must be ≥90%. After the facial recognition is successful, the user is redirected to the bank card four-element filling page. After the user submits the information, the system calls the UnionPay interface for verification in real time. If the verification fails, a message will be displayed indicating that the information is inconsistent. Please check and try again. There are a maximum of 2 attempts. If the payment limit is 5,000 yuan and the user's current payment amount is 6,000 yuan, the current payment limit of 5,000 yuan will be forcibly displayed. The user can reduce the purchase amount or make multiple payments (each payment ≥24 hours apart). E6. After verification and payment, the funds will be temporarily held in the platform's transition account for 72 hours. During this period, the risk control system will conduct additional checks to see if the merchant is a high-risk merchant and whether the transaction involves IP proxy spoofing. If there is no risk, the funds will be transferred after 72 hours. If a risk is found, such as a report of fraudulent transactions, the funds will be frozen and a manual investigation will be triggered. E7. Record and archive execution results. Records include transaction ID, risk level (high risk), parameter configuration (temporarily stored for 72 hours, payment limit of 5,000 yuan, face + four-factor authentication), verification pass rate, fund freeze / transfer status, and risk investigation results. If a high-risk transaction is reported as fraudulent within 72 hours, the user's device fingerprint and IP address will be added to the blacklist, and subsequent transactions with the same device / IP will be directly upgraded to high risk.

[0027] Example: A user registers in Guangdong and purchases a luxury handbag worth 20,000 yuan (high-risk category) for the first time using an unfamiliar mobile phone from Henan (without fingerprint registration). The user's credit score is 580, triggering a high-risk process: the user needs to complete facial recognition and bank card verification. The payment limit is set at 5,000 yuan (if the user has no transactions in the past 30 days, a minimum guarantee of 1,000 yuan is provided; if the user has no transactions in the past 30 days, the parameter database presets a minimum guarantee of 1,000 yuan, then the user needs to make the payment in 20 separate transactions or reduce the purchase amount. The funds are temporarily held for 72 hours, and will be transferred if there is no risk during this period).

[0028] By dynamically configuring parameters, we can flexibly adapt to different trading scenarios and avoid a one-size-fits-all approach that could lead to a decline in user experience or oversight of risks.

[0029] S4. Real-time monitoring of the entire transaction process, recording the transaction success rate and capital security rate after parameter adjustments, and iteratively optimizing the parameters of the risk control assessment model based on real-time monitoring data to achieve matching between risk control parameters and actual risks.

[0030] The process of real-time monitoring of the entire transaction process is as follows: F1. The monitoring priority is determined from three dimensions: security goals, experience goals, and efficiency goals. Among them, the security goals are: risk transaction interception rate ≥99.5% and fund loss rate ≤0.01%; the experience goals are: low-risk transaction success rate ≥99% and user complaint rate ≤0.01%; and the efficiency goals are: risk control decision time ≤100ms and manual review rate ≤5%. F2. Construct a three-level indicator library based on monitoring priorities. The three-level indicator library includes outcome-based indicators, process-based indicators, and root cause analysis indicators. Among them, outcome-based indicators include transaction success rate, fund security rate, and user complaint rate; process-based indicators include verification pass rate, parameter configuration execution rate, and abnormal transaction identification rate; root cause analysis indicators include the proportion of abnormal transactions by devices, the proportion of high-risk transactions by new users, and the risk occurrence rate of specific product categories. F3. Build a monitoring panel using Prometheus + Grafana, and display it in modules according to risk level and indicator type, such as low-risk transaction success rate trend and high-risk verification pass rate dashboard; F4. Configure alarm rules. Alarm rules include triggering multi-level alarms when there are abnormalities and associating the abnormal transaction ID for easy traceability. For example, when the indicator deviates from the threshold by 10%, the risk control specialist will be notified via SMS. If the indicator deviates from the threshold by 20%, the person in charge will be notified by phone.

[0031] The parameter iterative optimization process for the risk control assessment model is as follows: G1. Set iteration trigger conditions. Trigger conditions include active triggering and passive triggering. Active triggering will be carried out when the monitoring indicators fail to meet the standards, the risk mode changes, or the data volume accumulates to the threshold. The method for judging the monitoring indicators to fail to meet the standards is that any one of the following core indicators fails to meet the standards for 12 consecutive hours: low-risk transaction success rate < 99%, high-risk fund security rate < 99%, and user complaint rate > 0.1%. The change in risk patterns is manifested in the discovery of new fraud scenarios in the feedback data, and the risk proportion of such scenarios is greater than 5%, such as remote devices + virtual goods + payment on behalf of others; The data volume accumulates to a threshold, such as 50,000 new labeled data entries during the promotional period and 100,000 new data entries during the non-promotional period, and the data coverage rate for post-event risk assessment is ≥90%; If the changes are triggered passively due to changes in business requirements or adjustments to monitoring policies, such as the addition of cross-border payment scenarios to the platform, features such as exchange rate fluctuation risk and cross-border device IP risk need to be added; if the changes in monitoring policies are triggered by the addition of biometrics to identity verification, the feature weights related to the verification method in the model need to be adjusted. G2. Select 3 months of labeled data and divide them into an iterative training set and an iterative test set in a 7:3 ratio to ensure that the data distribution is consistent with the current business scenario. If new risk factors are found, such as the higher risk of payment during the 2-4 am period, add the feature of the payment period risk coefficient during feature extraction and recalculate the feature weights. G3. Retrain the risk control assessment model using the iterative training set, and perform dual-dimensional verification on the trained model. If both dual-dimensional verifications meet the standards, proceed to A / B testing. If the dual-dimensional verifications fail to meet the standards, perform root cause analysis and secondary optimization. The two-dimensional verification includes effectiveness verification and interpretability verification. The effectiveness verification metrics are that the safety rate of high-risk funds and the success rate of low-risk transactions have improved compared to the old model, and the user complaint rate has decreased compared to the old model. The interpretability verification uses SHAP values ​​to analyze the importance of features, ensuring that the weights of key features are consistent with business understanding and that there are no abnormally high-weight features. Key feature weights include device security coefficients and third-party credit scoring weights. Abnormally high weights, such as an irrelevant feature weight greater than 0.2, require investigation of data leakage. When performing root cause analysis, additional feedback data is required. If the success rate of low-risk transactions does not meet the target, the reasons for low-risk transaction failures in the feedback data need to be checked to determine whether the limit is unreasonable because the user's historical payment amount is not included in the features. Secondary optimization should be performed based on the root cause analysis results. After secondary optimization, G3 should be executed repeatedly until the dual-dimensional verification meets the target. During the second optimization, if the problem is with the data, the erroneous data needs to be re-labeled and missing scenario samples need to be added, such as adding promotional period and cross-border transaction data, to ensure that the sample size meets the requirements of the new risk factor samples; if the problem is with the model, the hyperparameters need to be adjusted and the model retrained; if the problem is with the features, weakly correlated features need to be removed and features that have been validated in the feedback data need to be added, such as user complaint history. A / B testing involves randomly dividing users into a test group and a control group, then deploying the optimized model and parameters to 5% of the user traffic, and comparing the core metrics of the test group and the control group. For example, the test group might show a 5% increase in the success rate of high-risk transactions and a 3% decrease in the complaint rate. G4. Gradually expand the coverage of the new model by 20%-50%-100%, with a 24-hour interval between each step. Use monitoring tools to continuously track the indicators and review the tracked indicators every week. If the review finds that the indicators have fallen, immediately trigger the next iteration and re-execute G1-G3. The review includes comparing the fund security rate, transaction success rate, and complaint rate before and after the iteration, calculating actual business benefits such as the reduction in fund losses and the percentage decrease in user churn, and recording new risk factors, effective hyperparameters, and feature weight ranges to provide a reference for the next iteration.

[0032] By first collecting user credit and transaction scenario data in real time, and then using machine learning models to classify user and transaction combinations into low, medium, and high risk levels, the platform dynamically configures the fund holding period and payment limit based on the level. Simultaneously, it iterates the parameters of the risk control assessment model using real-time monitoring data, achieving a match between risk control parameters and actual parameters. When risk control parameters are dynamically configured, low-risk transactions have shorter fund holding periods, accelerating merchants' cash flow; high-risk transactions are managed through tiered controls instead of a blanket limit, reducing the cost of split payment operations and the risk of misjudgments, improving risk control accuracy, increasing the efficiency of low-risk transaction cash flow, and increasing the success rate of high-risk transactions. This also reduces the risk of large-scale financial losses, balancing platform security and user experience, and expanding the platform's transaction coverage.

[0033] Based on the above-described platform payment risk control method for new retail e-commerce, this invention also provides a platform payment risk control system for new retail e-commerce, such as... Figure 4 As shown, it includes a data acquisition module, a risk assessment module, a risk control decision module, and a monitoring iteration module. The data acquisition module collects multi-dimensional data containing user credit data and transaction scenario data in real time, and performs standardized processing on the multi-dimensional data. The risk assessment module constructs a risk control assessment model based on machine learning algorithms, while receiving standardized data output from the data acquisition module, extracting key variables, and weighting and scoring each variable. Finally, based on the scoring results, users and transaction portfolios are divided into three risk levels: low, medium, and high. The risk control decision module transforms the risk assessment results into specific risk control strategies and dynamically configures risk control parameters based on the risk control strategies. The monitoring iteration module monitors the entire transaction process in real time, records the transaction success rate and fund security rate after parameter adjustments, and iteratively optimizes the parameters of the risk control assessment model based on real-time monitoring data.

[0034] The data acquisition module pushes the cleaned and standardized data to the risk assessment module in real time. The risk assessment module outputs the risk level results and synchronizes them to the risk decision module. The risk control decision module generates parameter configurations in real time to ensure that there is no significant delay in the payment process. The risk control parameters and transaction results executed by the risk decision module are fed back to the monitoring iteration module. The monitoring iteration module sends the optimized risk control assessment model weights and parameter rules back to the risk assessment module and the risk control decision module to complete the iteration. The feedback data from the monitoring iteration module provides a basis for correcting the risk assessment model and risk control decision strategy, enabling the system to dynamically adapt to changes in user behavior (such as user credit improvement) and business scenario expansion (such as adding new product categories), avoiding a disconnect between risk control strategies and actual needs.

[0035] Finally, it should be noted that the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing embodiments or make equivalent substitutions for some of the technical features. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A platform payment risk control method based on new retail e-commerce, characterized in that: Includes the following steps: S1. Real-time collection of multi-dimensional data including user credit data and transaction scenario data. User credit data includes historical transaction performance records, third-party credit scores, and platform membership levels; transaction scenario data includes product category risk levels, consumption frequency, historical cooperation between the transacting parties, and payment terminal security coefficient. S2. Construct a risk control assessment model through machine learning algorithms, weight score the collected multi-dimensional data, obtain the risk level of users and trading portfolios, and divide the risk level of users and trading portfolios into three risk levels: low, medium and high. S3. Dynamically configure risk control parameters according to different risk levels, specifically: The risk control parameters for low-risk configurations are to shorten the temporary holding period of funds and increase the payment limit; The risk control parameters for medium-risk configurations are the maintenance baseline parameters; The risk control parameters configured for high-risk scenarios include extending the temporary storage period, triggering additional identity verification, and dynamically adjusting the payment limit. S4. Real-time monitoring of the entire transaction process, recording the transaction success rate and capital security rate after parameter adjustments, and iteratively optimizing the parameters of the risk control assessment model based on real-time monitoring data to achieve matching between risk control parameters and actual risks.

2. The platform payment risk control method based on new retail e-commerce according to claim 1, characterized in that: When collecting multi-dimensional data, first determine the platform system for acquiring the data based on the type of data to be collected, then define the real-time acquisition interface based on the platform system, and finally preprocess and store the data acquired by the real-time acquisition interface.

3. The platform payment risk control method based on new retail e-commerce according to claim 2, characterized in that: When defining the real-time data collection interface, the internal data interface synchronizes incremental data from the transaction system and membership system in real time through the CDC tool, and calls the real-time query API of the third-party credit reporting agency through the external data interface to obtain the user's credit score. Finally, the SDK collects the security information of the payment terminal.

4. The platform payment risk control method based on new retail e-commerce according to claim 3, characterized in that: The risk control assessment model construction process is as follows: A1. Extract core features from the structured feature dataset and construct a feature matrix. The core features include user credit features containing credit scores and fulfillment rates, as well as scenario features containing product risk scores and terminal security coefficients. A2. The information gain algorithm is used to calculate the weights of user credit features and scenario features respectively; A3. Use the logistic regression algorithm to build a binary classification model, use historical data as the training set, and optimize the parameters of the binary classification model through gradient descent. A4. Based on the risk probability output by the binary classification model, a comprehensive score is calculated by combining the feature weighting results, and a level threshold is set to classify low, medium and high risk levels.

5. The platform payment risk control method based on new retail e-commerce according to claim 4, characterized in that: In step A3, the binary classification model construction process is as follows: A31. Data preparation and division: Using historical transaction data as the dataset, each sample contains core features and labels. The data is divided into training set, validation set and test set in a 7:2:1 ratio. A32. Define the feature vector, label, and model parameters of a single sample as a weight vector and bias term; A33. Initialize the model parameters, and initialize the bias term to 0; A34. Calculate the linear score through linear regression, and then map it to probability using the sigmoid function; A35. Use the cross-entropy loss function to measure the error between the predicted probability and the true label; A36. Update the parameters calculated during forward propagation by minimizing the loss function; A37. Repeat A34-A36 until the loss value of the loss function is minimized to the optimal value.

6. The platform payment risk control method based on new retail e-commerce according to claim 5, characterized in that: Before dynamically configuring risk control parameters, a risk control parameter library must be established first, and then a real-time decision engine must be developed for dynamic configuration. The real-time decision engine is based on a rule engine to build a mapping logic between risk levels and parameters. The establishment of the risk control parameter library includes configuration of low-risk, medium-risk, and high-risk risk control parameters.

7. The platform payment risk control method based on new retail e-commerce according to claim 6, characterized in that: The mapping logic between risk levels and parameters is constructed as follows: B1. When a user submits a payment request on the new retail platform, the payment system simultaneously sends a risk parameter configuration request to the real-time decision engine. B2. The decision engine automatically retrieves preset rules from the user and transaction portfolio risk level and risk control parameter library; B3. The payment system must complete the process from request initiation to parameter return within 100ms to meet the low latency requirements of payment scenarios. This is achieved through the efficient matching capabilities of the rule engine and its interaction with the payment system's interface.

8. The platform payment risk control method based on new retail e-commerce according to claim 7, characterized in that: The process of real-time monitoring of the entire transaction process is as follows: F1. Determine monitoring priorities from three dimensions: safety goals, experience goals, and efficiency goals; F2. Construct a three-level indicator library based on monitoring priorities. The three-level indicator library includes outcome indicators, process indicators, and root cause analysis indicators. F3. Build a monitoring panel using Prometheus + Grafana, and display it in modules according to risk level and indicator type.

9. A platform payment risk control method based on new retail e-commerce according to claim 8, characterized in that: The parameter iterative optimization process for the risk control assessment model is as follows: G1. Set iteration trigger conditions. Trigger conditions include active triggering and passive triggering. Active triggering will be performed when the monitoring indicators fail to meet the standards, the risk mode changes, or the data volume accumulates to the threshold. This will be triggered passively when business needs change or monitoring policies are adjusted. G2. Select 3 months of labeled data and divide them into an iterative training set and an iterative test set in a 7:3 ratio to ensure that the data distribution is consistent with the current business scenario. If new risk factors are found, add the feature of the payment period risk coefficient during feature extraction and recalculate the feature weights. G3. Retrain the risk control assessment model using the iterative training set, and perform dual-dimensional verification on the trained model. If both dual-dimensional verifications meet the standards, proceed to A / B testing. If the dual-dimensional verifications fail to meet the standards, perform root cause analysis and secondary optimization. G4. Gradually expand the coverage of the new model by 20%-50%-100%, with a 24-hour interval between each step. Use monitoring tools to continuously track the indicators and review the tracked indicators every week. If the review finds that the indicators have fallen, immediately trigger the next iteration and re-execute G1-G3.

10. A platform payment risk control system based on new retail e-commerce, used to implement the platform payment risk control method based on new retail e-commerce as described in any one of claims 1-9, characterized in that: include: The data acquisition module collects multi-dimensional data, including user credit data and transaction scenario data, in real time, and performs standardized processing on the multi-dimensional data. The risk assessment module builds a risk control assessment model based on machine learning algorithms. It also receives standardized data from the data acquisition module, extracts key variables, and assigns weighted scores to each variable. Finally, based on the scoring results, users and trading portfolios are divided into three risk levels: low, medium, and high. The risk control decision module transforms risk assessment results into specific risk control strategies and dynamically configures risk control parameters based on these strategies. The monitoring and iteration module monitors the entire transaction process in real time, records the transaction success rate and fund security rate after parameter adjustments, and iteratively optimizes the parameters of the risk control assessment model based on real-time monitoring data.

Images