A method for dynamically adjusting the password-free payment limit for mobile payments

Abstract

This invention relates to the field of mobile payment technology, specifically to a method for dynamically adjusting the password-free limit for mobile payments. The method includes the following steps: When a payment terminal initiates a payment request, it collects discrete data on the network environment, device unlocking method, SIM card status, system integrity, and application environment in real time to establish a device security state vector. This invention, by collecting data from multiple dimensions of the discrete states of the network environment, device unlocking method, SIM card status, system integrity, and application environment and constructing a security state vector, can structurally characterize device security before a transaction is initiated, capturing the security fluctuation characteristics during device operation. Using the security product decay value generated by the security state vector, and combined with the user-set maximum password-free limit benchmark value, a comprehensive device security score is output in the form of a non-linear function, achieving quantitative filtering of device trustworthiness before the limit calculation stage.

Description

Technical Field

[0001] This invention relates to the field of mobile payment technology, and in particular to a method for dynamically adjusting the password-free limit for mobile payments. Background Technology

[0002] The dynamic adjustment method for mobile payment password-free limits is a control mechanism used in mobile payment scenarios to dynamically generate password-free payment limits based on transaction behavior and device security status. Its core purpose is to achieve accurate perception and real-time suppression of password-free transaction risks without interfering with the user's payment experience.

[0003] While existing technologies support setting control mechanisms based on transaction behavior and device status in password-free payment scenarios, they lack the ability to jointly perceive device environment and behavior. Regarding device status determination, common methods rely on coarse-grained standards such as whether the device is rooted or whether the network is secure, making it difficult to make detailed judgments under various combinations of security status changes. This leads to transactions being allowed even when risks are not accurately quantified, creating potential vulnerabilities. Therefore, improvements are needed. Summary of the Invention

[0004] The purpose of this invention is to address the shortcomings of existing technologies by proposing a method for dynamically adjusting the password-free limit for mobile payments.

[0005] To achieve the above objectives, the present invention adopts the following technical solution: a method for dynamically adjusting the password-free limit for mobile payments, comprising the following steps:

[0006] When a payment terminal initiates a payment request, it collects discrete data on the network environment, device unlocking method, SIM card status, system integrity, and application environment in real time to establish a device security state vector.

[0007] Based on the payment protocol, the device security status vector is invoked to generate a device security product attenuation value. The maximum password-free limit benchmark value set by the user is calculated with the device security product attenuation value to obtain a comprehensive device security score.

[0008] After receiving a payment request, the payment server extracts the transaction amount, payee account information, product category information, and transaction time information, establishes a cognitive load factor set, and calculates the transaction cognitive load score based on each factor in the cognitive load factor set.

[0009] The transaction cognitive load score is compared with the set cognitive load threshold to establish a transaction risk level determination result. The comprehensive device security score is used as the base limit, and the transaction risk level determination result is called to generate a dynamic password-free payment limit.

[0010] Preferably, the step of obtaining the device security state vector is as follows:

[0011] After receiving a payment request from a user, the payment terminal extracts the device's current network connection type, screen unlock method, whether a SIM card is inserted and its carrier affiliation, whether the system has been tampered with, and the container environment attributes of the running application, and generates five discrete states: network connection type, screen unlock method, SIM card status identifier, system verification status, and container environment attributes.

[0012] Based on the five discrete states of network connection type, screen unlocking method, SIM card status identifier, system verification status and container environment attribute, each discrete state is mapped one by one according to the security level value. The mapping result is assigned the network environment component, device unlocking method component, SIM card status component, system integrity component and application environment component in sequence.

[0013] Based on the network environment component, device unlocking method component, SIM card status component, system integrity component, and application environment component, they are arranged in a unified order to form a column vector, and each component is organized and stored according to the vector structure to generate a device security status vector.

[0014] Preferably, the step of obtaining the device safety product attenuation value is as follows:

[0015] Based on the device security state vector, the network environment component, device unlocking method component, SIM card status component, system integrity component, and application environment component are extracted sequentially to calculate and generate the device security product attenuation value.

[0016] Preferably, the steps for obtaining the integrated equipment security score are as follows:

[0017] The comprehensive equipment security score is calculated based on the equipment security product attenuation value and the maximum password-free limit benchmark value.

[0018] Preferably, the step of obtaining the cognitive load factor set is as follows:

[0019] After receiving a payment request, the payment server extracts the transaction amount field, payee account identifier field, product category field, and transaction time field from the request one by one, and records them in the transaction parameter cache according to the preset structure, thus obtaining the transaction amount field, payee account identifier field, product category field, and transaction time field;

[0020] Based on the transaction amount field, payee account identifier field, product category field, and transaction time field, the mean, frequency, and time distribution indicators of the corresponding fields for users in the transaction history database are called respectively. The deviation value extraction, frequency statistics, and window difference calculation methods are used to calculate the amount deviation factor, payee unfamiliarity factor, product category rarity factor, and time sensitivity factor to obtain the cognitive load factor set.

[0021] Preferably, the step of obtaining the transaction cognitive load score is as follows:

[0022] Calculate the transaction cognitive load score based on the set of cognitive load factors.

[0023] Preferably, the steps for obtaining the transaction risk level determination result are as follows:

[0024] Based on the transaction cognitive load score, the transaction cognitive load score is compared with the system's preset cognitive load threshold value by value. If the transaction cognitive load score is greater than or equal to the cognitive load threshold, the transaction is determined to be in a high-risk state; otherwise, it is determined to be in an acceptable state, and a transaction risk level determination result is generated.

[0025] Preferably, the steps for obtaining the dynamic password-free payment limit are as follows:

[0026] Based on the transaction risk level determination result, select the limit suppression coefficient that matches the determination result from the limit suppression coefficient preset mapping table, and at the same time retrieve the comprehensive device security score as the basic limit value, calculate the limit suppression coefficient and the basic limit value, and generate the initial calculation result of the dynamic password-free limit.

[0027] Based on the initial calculation result of the dynamic password-free limit, unit conversion, numerical precision truncation, and field identifier appending processing are performed to add transaction request number and user unique identifier fields to generate the dynamic password-free payment limit.

[0028] Compared with the prior art, the advantages and positive effects of the present invention are as follows:

[0029] This invention collects data from multiple dimensions—network environment, device unlocking method, SIM card status, system integrity, and discrete states of the application environment—and constructs a security state vector. This allows for a structured characterization of device security before a transaction is initiated, capturing security fluctuations during device operation. Using the security product decay value generated by the security state vector, combined with the user-defined maximum password-free payment limit, a comprehensive device security score is output in the form of a non-linear function, achieving quantitative filtering of device trustworthiness before limit calculation. At the transaction behavior analysis level, a cognitive load factor set is constructed by extracting four elements: transaction amount, payee account information, product category, and transaction time. This forms a structured risk representation oriented towards user behavior, avoiding misjudgments caused by static judgments of single indicators. The cognitive load score is compared with a set threshold to output a transaction risk level. Based on this level, a limit suppression coefficient is dynamically retrieved and calculated with the device security score to output a dynamic password-free payment limit. This ensures that the final limit result is both supported by device trustworthiness and responsive to changes in transaction risk. This processing chain improves the flexibility, security, and targeting of credit limit response while maintaining a stable user experience. It also avoids excessive approval or false rejection of transactions due to environmental changes or behavioral deviations, thereby enhancing the dynamic control accuracy and risk management capabilities of the contactless payment limit. Attached Figure Description

[0030] Figure 1 This is a schematic diagram of the steps of the present invention. Detailed Implementation

[0031] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0032] Please see Figure 1 This invention provides a technical solution: a method for dynamically adjusting the password-free limit for mobile payments, comprising the following steps:

[0033] When a payment terminal initiates a payment request, it collects discrete data on the network environment, device unlocking method, SIM card status, system integrity, and application environment in real time to establish a device security state vector.

[0034] Based on the payment protocol, the device security status vector is invoked to generate a device security product attenuation value. The maximum password-free limit set by the user is calculated with the device security product attenuation value to obtain a comprehensive device security score.

[0035] After receiving a payment request, the payment server extracts the transaction amount, payee account information, product category information, and transaction time information, establishes a cognitive load factor set, and calculates the transaction cognitive load score based on each factor in the cognitive load factor set.

[0036] The transaction cognitive load score is compared with the set cognitive load threshold to establish a transaction risk level determination result. The comprehensive device security score is used as the base limit, and the transaction risk level determination result is called to generate a dynamic password-free payment limit.

[0037] The steps for obtaining the device safety state vector are as follows:

[0038] After receiving a payment request from a user, the payment terminal extracts the device's current network connection type, screen unlock method, whether a SIM card is inserted and its carrier affiliation, whether the system has been tampered with, and the container environment attributes of the running application, and generates five discrete states: network connection type, screen unlock method, SIM card status identifier, system verification status, and container environment attributes.

[0039] Based on five discrete states—network connection type, screen unlocking method, SIM card status identifier, system verification status, and container environment attributes—each discrete state is mapped one-to-one according to the security level value. The mapping results are assigned to the network environment component, device unlocking method component, SIM card status component, system integrity component, and application environment component in sequence.

[0040] Based on network environment components, device unlocking method components, SIM card status components, system integrity components, and application environment components, these components are arranged in a unified order to form a column vector. Each component is then organized and stored according to a vector structure to generate a device security status vector.

[0041] Specifically, after receiving a payment request signal from a user, the payment terminal obtains various device status information by calling the underlying interface of the operating system. The specific execution process is as follows: First, it calls the network status management interface to query the specific type of the currently active network, distinguishing between cellular mobile networks and wireless LANs. If it is a cellular mobile network, it further identifies its technology generation, such as fifth-generation mobile communication technology (5G) or fourth-generation mobile communication technology (4G). If it is a wireless LAN, it obtains its Service Set Identifier (SSID) and compares it with a locally stored list of trusted networks that is automatically accumulated from the user's historical connection records or manually confirmed. If the SSID exists in the trusted list, it is marked as a trusted wireless network; otherwise, it is marked as a public or unknown network, thus obtaining the specific status of the network connection type. Second, it calls the device lock screen management service to check whether the device has enabled security. If the screen is fully locked and enabled, the system further queries the lock method to determine whether it is based on biometric recognition (such as fingerprint or facial recognition) or password or pattern recognition, thus obtaining the specific status of the screen unlock method. Next, it calls the telephone service interface to query the SIM card status, confirming whether the physical SIM card or eSIM card is present and available. If available, it reads the mobile network operator code and compares it with the device's initial activation or frequently used operator history to determine if there has been a SIM card replacement or abnormal location, forming a SIM card status identifier. Then, it executes a system integrity self-check program. This program calculates the checksum of the system's core partition and compares it with the baseline checksum preset at the device's factory or updated through official channels to detect whether system files have been illegally tampered with. Simultaneously, it calls a hardware-level security authentication interface provided by a trusted execution environment, such as Google's SafetyNet. Attestation or Huawei's SafetyDetection are used to obtain encrypted signature reports on the device bootloader status and system integrity level. Based on the results of these two checks, it is determined whether the system has been tampered with. Finally, the list of currently running application processes and the names of installed application packages are scanned and matched with a feature library of known risky applications and frameworks (such as injection or virtualization tools like Xposed and Magisk) that are regularly updated from the payment server. This determines whether the payment application is running in a tampered container environment or has potential monitoring risks. The query and detection results of the above five dimensions are solidified into five discrete states: network connection type, screen unlock method, SIM card status identifier, system verification status, and container environment attributes.

[0042] Based on the five discrete states generated in the previous step—network connection type, screen unlock method, SIM card status identifier, system verification status, and container environment attributes—the system will assign a quantitative security score to each discrete state. This process is accomplished through a preset "discrete state to security score" mapping table. This mapping table is constructed based on risk analysis of massive amounts of historical transaction data. By statistically analyzing the occurrence rate of fraudulent transactions under different device state combinations, the security contribution of each state is quantified. The specific mapping relationship is set as follows: for network connection type, it is labeled as "trusted wireless network" or "4G / 5G". The discrete status mapping for "G cellular network" is the highest security level value of 1.0, while "public or unknown network" is mapped to 0.6, and "2G / 3G network or no network" is mapped to 0.2. For screen unlocking methods, "biometric recognition" is mapped to 1.0, "6-digit or longer numeric or complex password" is mapped to 0.8, "pattern or simple password" is mapped to 0.5, and "no security lock screen" is mapped to 0.1. For SIM card status indicators, "usual SIM card" is mapped to 1.0, "newly replaced SIM card" is mapped to 0.7, and "no SIM card or airplane mode" is mapped to... The security level is set to 0.4. For system verification status, "Passed system checksum and hardware-level security authentication" is mapped to 1.0, "Passed system checksum only but hardware authentication failed" is mapped to 0.5, and "System tampering or rooting detected" is mapped to 0.1. For container environment attributes, "Standard application runtime environment" is mapped to 1.0, "Detected running in an emulator or virtualization container" is mapped to 0.5, and "Injection or Hooking framework detected" is mapped to 0.2. The logic for setting the security level values ​​here is that the baseline security status (such as biometric unlocking) is defined as 1.0, and others... The security level value is calculated by associating with the risk rate. For example, if statistics show that the fraud transaction rate of the public network is 70% higher than that of the trusted network, then its security level value is set to approximately 1 / (1+0.7), which is approximately equal to 0.6, to reflect its increased relative risk. After the mapping table is completed, the system will read the specific values ​​of the five discrete states one by one and look up the corresponding security level value in the mapping table. Then, the five values ​​found will be assigned to five new variables to generate network environment component, device unlocking method component, SIM card status component, system integrity component, and application environment component.

[0043] Based on the five specific values ​​generated in the previous process—network environment component, device unlocking method component, SIM card status component, system integrity component, and application environment component—the system needs to integrate these dispersed components into a unified data structure. This process first establishes a fixed and unchanging order, defined in the payment protocol's technical specifications and embedded in the payment terminal's software development kit (SDK). This ensures that all clients use a completely consistent vector structure. For example, this fixed order is defined as follows: first is the network environment component, second is the device unlocking method component, third is the SIM card status component, fourth is the system integrity component, and fifth is the application environment component. The system strictly follows this order, sequentially filling the five component values ​​into a data array, thus logically forming a five-dimensional column vector. For example, if the five component values ​​obtained in a payment request are 1.0, 1.0, 0.7, 1.0, and 0.5, the resulting column vector is mathematically represented as follows: Subsequently, to facilitate transmission within the payment request data packet, the column vector is organized into a standardized data format. The system creates a temporary, lightweight data object in the application's memory. This object is not written to any permanent storage to prevent data leakage risks. It encapsulates the vector into a key-value pair structure, such as a JSON object represented as {"version": 1, "vector_values": [1.0, 1.0, 0.7, 1.0, 0.5]}, which includes a version number for future structure upgrades and an array of component values ​​arranged in a predetermined order. This structured data object, containing five ordered security components, is ultimately defined and generated as the device security state vector.

[0044] The steps for obtaining the equipment safety product attenuation value are as follows:

[0045] Based on the device security state vector, the network environment component, device unlocking method component, SIM card status component, system integrity component, and application environment component are extracted sequentially to calculate and generate the device security product attenuation value.

[0046] Specifically, based on the device security state vector, which is a structured data object containing five pre-ordered components, the system first parses this vector in a fixed order, extracting five floating-point values: network environment component, device unlocking method component, SIM card status component, system integrity component, and application environment component. For example, the system reads an array of component values ​​from the received device security state vector, assigning the first element to the network environment component, the second element to the device unlocking method component, and so on, until the fifth element is assigned to the application environment component. This extraction process does not involve any transformation of the values; it is only a data location and reading operation. After successfully extracting all five components, the system performs the core multiplication operation, which involves continuously multiplying these five independent security component values, each ranging from 0 to 1. The design logic of this multiplication operation is based on the cumulative effect of risk, that is, the apparent risk of any security dimension increases. Any reduction in security level will disproportionately lower the overall security level. For example, even if a device achieves a perfect score of 1.0 in all four aspects—network, unlocking method, SIM card, and system integrity—if its application environment is detected as running under an injection framework, resulting in an application environment component of only 0.2, the final product will be directly reduced to 0.2 (the calculation process is 1.0 × 1.0 × 1.0 × 1.0 × 0.2). This accurately reflects the disruptive impact of a single critical vulnerability on overall security. Similarly, a device in a medium-security state, with a public network environment (component value 0.6), pattern unlocking (component value 0.5), and the other three aspects being ideal (component values ​​of 1.0 each), will have a calculated result of 0.6 × 0.5 × 1.0 × 1.0 × 1.0, resulting in 0.3. This calculation process is completed instantaneously in the processor, and the final product is the device security product attenuation value.

[0047] The steps to obtain the comprehensive equipment safety score are as follows:

[0048] The comprehensive equipment security score is calculated based on the equipment security product attenuation value and the maximum confidentiality exemption benchmark value. The calculation formula is as follows:

[0049] ;

[0050] in, To determine the overall equipment safety score, The maximum limit for password-free access set for users, in [currency]. This represents the product decay value of equipment safety. For the first Each security state component The system risk sensitivity coefficient is dimensionless, controlling the steepness of the function. The safety state response threshold is dimensionless and represents the acceptable safety level boundary of the system. A sigmoid function is constructed to smooth the output limit control coefficient.

[0051] Specifically, the formula: The advantage of this formula lies in its ability to smoothly and non-linearly map discrete and multidimensional device security states to a continuous limit control coefficient by introducing the standard Sigmoid function. This avoids drastic fluctuations in the password-free limit caused by minor changes in the security score, thus improving the stability of the user experience. Specifically, the formula first uses the device security product attenuation value. This reflects the multiplier effect when multiple security risk factors are combined, meaning that a single serious risk can significantly reduce the overall security assessment. Secondly, regarding... Take the square root This smooths out the excessively rapid decline in the product decay value caused by multiplication, making the function's response to changes in the safety state more moderate over most of the range, exhibiting high sensitivity only near critical risk points. Furthermore, through the system risk sensitivity coefficient... and safety status response threshold These two adjustable parameters give the risk control model great flexibility, allowing payment service providers to dynamically adjust it based on the overall market fraud situation, user risk levels, or risk strategies for specific campaign periods. The value is used to change the sensitivity of the credit limit to risk, adjusting... The value is used to raise or lower the security baseline for triggering credit limit suppression. Ultimately, this credit limit control coefficient, which ranges from 0 to 1, is compared with the user-defined maximum password-free credit limit baseline value. This multiplication achieves an organic combination of personalized settings and dynamic risk control;

[0052] The steps to obtain the (maximum password-free payment limit benchmark value) are as follows: This parameter is set by the user in the payment application client. The process is as follows: After logging into the payment application, the user navigates to the "Settings" menu, selects the "Password-free Payment" option in "Payment Settings," and the system displays a limit setting interface. The user can enter or select a specific value within a valid range preset by the payment service provider (e.g., RMB 100 to 2000 for ordinary users). This value represents the maximum risk limit the user is willing to bear for a single password-free transaction. After the user confirms the input, the value is encrypted and transmitted to the payment server, stored in a database associated with the user's account, and serves as the benchmark upper limit for all subsequent password-free payment limit calculations. For example, if the user sets this benchmark value to RMB 1000 based on their spending habits and risk preferences, then in subsequent calculations… The value is 1000;

[0053] The steps for obtaining the (device security product attenuation value) are as follows: This parameter is a direct output of the previous step of this method and does not need to be recalculated in this step. Its value is based on the five security components (network environment components) in the device security state vector. Device unlocking methods SIM card status components System integrity components Application environment components Multiplying them together yields the result, i.e. It quantifies the overall security level of a device at a given moment, with a value ranging from 0 to 1. A value closer to 1 indicates a more secure device, while a value closer to 0 indicates a higher risk. For example, in the previous step, based on a device state using a public network (component value 0.6), pattern unlock (component value 0.5), and the remaining three ideal values ​​(all component values ​​1.0), the calculated device security product attenuation value is 0.3. Therefore, in this formula calculation, this result is directly used, letting... The value is 0.3;

[0054] The steps for obtaining the (system risk sensitivity coefficient) are as follows: This parameter is a dimensionless coefficient used to control the steepness of the Sigmoid function curve, i.e., the sensitivity of the password-free limit to changes in device security. Its value is determined by the payment service provider's risk control department based on statistical analysis of massive amounts of historical transaction data. The specific setting process is as follows: First, collect data containing information from each transaction... A large-scale dataset is constructed, consisting of the value and records of whether the transaction was ultimately confirmed as fraud. Then, using... Using 's' as the independent variable and 'whether the transaction is fraudulent' ('yes' = 1, 'no' = 0) as the dependent variable, a logistic regression analysis is performed. The regression model will fit a coefficient that directly reflects the degree of influence of changes in security level on the probability of fraud. This regression coefficient is used as the setting... Based on this value, and fine-tuned in conjunction with business strategies, for example, after analyzing hundreds of millions of transactions in the most recent quarter, the logistic regression model shows... The coefficient is 9.87. The risk team, considering the current need to appropriately increase risk sensitivity, will... The value is rounded up and set to 10. This value will be permanently stored in the risk control strategy configuration of the payment server.

[0055] The steps for obtaining the (security status response threshold) are as follows: This parameter defines the boundary of the security level that the system considers acceptable. In the Sigmoid function, it corresponds to the input point where the limit control coefficient is 0.5. Its value is also based on risk strategy and data analysis, aiming to define a critical point between "safe" and "suspicious." The setting process involves the risk analyst first defining a minimum business-acceptable equipment security product decay value. This value is determined with reference to different... Historical average fraud loss rate at a given level, for example, analysis shows that when Below 0.25, the fraud loss rate begins to grow exponentially, exceeding the business's tolerance level; therefore, [the following is likely an error and should be omitted]. Set as a safety threshold, since the formula actually uses As input, therefore, the security state response threshold The square root of the critical point is calculated as, i.e. This threshold means that when a device When the value is exactly 0.5, the amount of password-free credit obtained will be half of the user-set baseline value. This setting means that the credit limit of devices whose security status is just near the critical point will be significantly but not too aggressively suppressed.

[0056] Calculation process:

[0057] Based on the parameter acquisition steps outlined above, we now substitute specific values ​​into the calculation. The specific parameters are as follows:

[0058] Maximum password-free limit benchmark value ;

[0059] Equipment safety product attenuation value ;

[0060] System risk sensitivity coefficient ;

[0061] Safety status response threshold ;

[0062] The calculation process is as follows:

[0063] First, calculate Value:

[0064] ;

[0065] Next, calculate the exponent of the Sigmoid function:

[0066] ;

[0067] Next, calculate the exponent term. The power value:

[0068] ;

[0069] Then, calculate the denominator of the Sigmoid function:

[0070] ;

[0071] Calculate the complete credit limit control coefficient:

[0072] ;

[0073] Finally, calculate the overall equipment safety score. :

[0074] ;

[0075] The result indicates that, under the current equipment security status, the calculated comprehensive equipment security score is 617.1. This value is in units similar to the highest password-free limit benchmark value. The unit is consistent (e.g., yuan), representing a dynamically adjusted upper limit for password-free access based entirely on the device's current security status. This score of 617.1 is higher than half (500 yuan) of the user-set baseline value of 1000 yuan because the device... The value (0.5477) is slightly higher than the safety status response threshold. (0.5) indicates that the system judges the equipment security status to be slightly better than the "acceptable" boundary level, and therefore gives it a credit limit coefficient of more than 50%. This comprehensive equipment security score will be used as the base credit limit and will be used in the subsequent process of combining transaction risk to determine the final credit limit.

[0076] The steps for obtaining the cognitive load factor set are as follows:

[0077] After receiving a payment request, the payment server extracts the transaction amount field, payee account identifier field, product category field, and transaction time field from the request one by one, and records them in the transaction parameter cache according to the preset structure, thus obtaining the transaction amount field, payee account identifier field, product category field, and transaction time field;

[0078] Based on the transaction amount field, payee account identifier field, product category field, and transaction time field, the mean, frequency, and time distribution indicators of the corresponding fields for users in the transaction history database are called respectively. The deviation value extraction, frequency statistics, and window difference calculation methods are used to calculate the amount deviation factor, payee unfamiliarity factor, product category rarity factor, and time sensitivity factor to obtain the cognitive load factor set.

[0079] Specifically, after receiving a payment request, the payment server sends the request to the application gateway in the form of an encrypted HTTPS message. The gateway first verifies the digital signature of the message using a pre-set asymmetric key to confirm the legitimacy of the request source. After successful verification, the server uses the session key to decrypt the payload of the request, parsing it from the raw byte stream into a structured data object. This data object follows a predefined JSON format and contains user identification, device information, encrypted payment credentials, and detailed parameters of the transaction. The server's core business logic layer then iterates through this JSON object, precisely extracting four key transaction information items by accessing specific keys: reading the "amount" field to obtain the transaction amount, reading the "payeeId" field to obtain the unique identifier of the payee's account, reading the "categoryCode" field to obtain the standard classification code for the corresponding goods or services, and reading the "timestamp" field to obtain the ISO-compliant information generated by the payment terminal. The four data points extracted from the 8601 standard transaction initiation timestamp—transaction amount, payee account identifier, product category, and transaction time—are immediately written into a memory cache associated with a unique ID for the current transaction request. This cache is an efficient key-value storage structure, such as Redis or an in-process hash table. Its pre-defined structure ensures that the subsequent risk calculation engine can access these parameters with extremely low latency, ultimately yielding the transaction amount, payee account identifier, product category, and transaction time fields available for real-time analysis.

[0080] Based on the transaction amount, payee account identifier, product category, and transaction time fields obtained from the transaction parameter cache in the previous step, the system initiates four independent calculation tasks in parallel to generate four cognitive load factors. First, for the calculation of the amount deviation factor, the system uses the user's unique identifier as an index to query the transaction history database, retrieves all successful transaction records of the user in the past 90 days, and calculates the average and standard deviation of these transaction amounts. Then, by calculating the absolute value of the difference between the current transaction amount and the historical average, the system divides this difference by the historical standard deviation. The difference is used to obtain a dimensionless deviation factor as the amount deviation factor. For example, if a user's historical average spending is 80 yuan, the standard deviation is 50 yuan, and the current transaction is 300 yuan, then the amount deviation factor is the absolute value of (300-80) divided by 50, resulting in 4.4. Secondly, for calculating the payee unfamiliarity factor, the system uses the current payee account identifier field to query the user's list of counterparties over the past year, counting the total number of times the payee appears. The payee unfamiliarity factor is defined as the reciprocal of the number of occurrences plus one. If the payee appears for the first time, the number of occurrences is... 0. The factor value is 1. If there have been 19 transactions, the factor value is 1 divided by (19+1), which is 0.05. Next, for the calculation of the category rarity factor, the system analyzes the distribution frequency of all product categories in the user's transaction records over the past year, calculates the percentage of the current product category, and sets the category rarity factor to the reciprocal of this percentage plus a smoothing term of 0.01. If a certain category accounts for 2% of transactions, its rarity factor is 1 divided by 0.02, which is 50. Finally, for the calculation of the time sensitivity factor, the system first uses the user's historical transaction timestamps. The system groups and counts users by hour, identifying the two most active time periods, such as 9:00 AM to 11:00 AM and 7:00 PM to 9:00 PM. Then, it calculates the time difference between the current transaction time and the nearest boundary of these two active time periods, in hours. If the current transaction is at 3:00 AM, and the nearest boundary (9:00 PM or 9:00 AM) is 6 hours away, then the time sensitivity factor is 6. Through the above four independent calculation processes, the system finally aggregates the obtained amount deviation factor, payee unfamiliarity factor, category rarity factor, and time sensitivity factor to obtain the cognitive load factor set.

[0081] The steps to obtain the transaction cognitive load score are as follows:

[0082] Based on the set of cognitive load factors, the trading cognitive load score is calculated using the following formula:

[0083] ;

[0084] in, For transaction cognitive load score, The normalized amount deviation factor represents the standard deviation multiple of the transaction amount relative to the historical average. The normalized payee unfamiliarity factor represents the proportion of payee accounts that have not appeared in historical records. The normalized category scarcity factor represents the inverse offset of the category's share in historical transactions. This is a normalized time sensitivity factor, representing the degree to which transaction time deviates from users' typical active time periods. These are the base coefficients corresponding to the four normalization factors, This is the interaction coefficient between the amount and the unfamiliarity factor with the payee. This refers to the collaborative risk item between the amount and the recipient.

[0085] Specifically, the formula: The advantage of this formula lies in its construction of a multi-dimensional, non-linear transaction risk assessment model, which can more accurately characterize the features of fraudulent transactions than simple linear weighting. The core innovation of this formula is the introduction of an interaction coefficient. and collaborative risk items This collaborative risk term is specifically designed to capture the exponentially growing compound risk that arises when two high-risk factors, "large transactions" and "unknown payees," occur simultaneously. This is a typical pattern of malicious behaviors such as theft and fraud. Simple linear models cannot effectively express the synergistic amplification effect of this risk. By taking the geometric mean of the normalized values ​​of these two factors, this term not only reflects the correlation between the two, but its square root form also makes the growth rate of this term between linear and square. It can effectively amplify the risk signal while avoiding the excessive dominance of extreme values ​​on the total score. In addition, all factors in the formula have been normalized to eliminate the differences in the dimensions and numerical ranges of different risk dimensions, making the allocation of weight coefficients more interpretable and fair. Finally, through weighted summation, the risks derived from user transaction behavior habits, other than device security, are quantified into a single, intuitive transaction cognitive load score.

[0086] The steps to obtain the (normalized amount deviation factor) are as follows: This parameter represents the degree to which the current transaction amount deviates from the user's normal spending habits. First, obtain the original amount deviation factor calculated in the previous step. That is, the standard deviation multiple of the difference between the transaction amount and the historical mean, because Theoretically, there is no upper limit, but normalization is required to map it to the [0, 1] interval. Normalization uses a linear scaling method with threshold truncation, and the specific calculation formula is as follows: ,in, This is a preset upper limit for the amount deviation. It is set based on statistical analysis of historical fraud cases across the entire platform. The analysis found that when the amount deviation exceeds 8 standard deviations, the increase in the probability of fraud tends to level off, but the risk is already extremely high. Therefore, it is set to... Setting it to 8 prevents extremely large transactions from disproportionately impacting the risk score. For example, if the user's amount deviation factor was calculated in the previous step... If the value is 4.4, then its normalized value is 4.4. ;

[0087] The steps to obtain the (normalized payee unfamiliarity factor) are as follows: This parameter quantifies the degree of unfamiliarity between the current counterparty and the user, and its original factor... The reciprocal of the number of times the payee appears plus one naturally falls within the range of (0, 1]. A larger value indicates greater unfamiliarity, already possessing good comparability. Therefore, its normalization process is an identity mapping, requiring no additional transformation. This direct approach preserves the non-linear relationship of the original factor based on the reciprocal of transaction frequency; that is, the decrease in unfamiliarity is most significant from 0 to 1 times, which aligns with the user's cognitive process of becoming familiar with the payee. For example, if the current payee is making their first transaction, their number of occurrences is 0, and the original factor... for Then the normalized payee unfamiliarity factor The value is 1.0;

[0088] The steps to obtain the (normalized category scarcity factor) are as follows: This parameter measures whether the goods or services a user purchases fall within their regular consumption range; the original category scarcity factor... The reciprocal of the historical percentage of the category has a large range and needs to be normalized. The normalization method also uses linear scaling with threshold truncation, and the calculation formula is as follows: The logarithmic transformation is used here because the distribution of product category frequencies often exhibits a long-tail characteristic. Directly using the reciprocal would lead to excessively large factor values ​​for extremely low-frequency product categories. The logarithmic transformation can effectively compress the data range while preserving its magnitude relationship and upper limit threshold. Based on the analysis of the rarity distribution of all user categories, the 99th percentile is selected, for example, 500, to cover the vast majority of cases. For instance, if a user's historical purchase rate for a certain category is 0.5%, then the original factor... The normalized value is ;

[0089] The steps to obtain the (normalized time sensitivity factor) are as follows: This parameter reflects whether the transaction time falls during the user's inactive period, and the original factor... It is the hourly difference between the current time and the boundary of the most recent active time period. The larger the value, the higher the risk. The normalization formula is: Upper limit threshold The time sensitivity factor is set to 12 hours because within a 24-hour cycle, the maximum difference between any point in time and a given time period will not exceed 12 hours. This setting allows it to linearly reflect the degree of deviation. For example, if the time sensitivity factor is calculated in the previous step... If the time is 6 hours, then the normalized value is ;

[0090] The steps for obtaining the (base coefficients and interaction coefficients) are as follows: these weight coefficients are not manually set, but are obtained by training a logistic regression model on massive amounts of historical transaction data that includes labels for "fraud" and "normal". The input features of the model are the aforementioned five parts: and collaborative risk items The optimization objective of the model is to maximize the log-likelihood function. The regression coefficients of each input feature, obtained through gradient descent, are used as weights here. The magnitude of these coefficients directly reflects the contribution of the corresponding factor to determining whether a transaction is fraudulent. For example, after training on 1 billion transaction data points from the past 6 months, the standardized regression coefficients obtained are: ;

[0091] Calculation process:

[0092] Based on the parameter acquisition steps outlined above, we now substitute specific values ​​into the calculation. The specific parameters are as follows:

[0093] Normalized amount deviation factor ;

[0094] Normalized payee unfamiliarity factor ;

[0095] Normalized category rarity factor ;

[0096] Normalized time sensitivity factor ;

[0097] base coefficient ;

[0098] Interaction coefficient ;

[0099] The calculation process is as follows:

[0100] First, calculate the value of the collaborative risk item:

[0101] ;

[0102] Next, calculate the value of each weighted term:

[0103] ;

[0104] ;

[0105] ;

[0106] ;

[0107] ;

[0108] Finally, by summing all the items, we obtain the transaction cognitive load score. :

[0109] The results indicate that the cognitive load score for this transaction is 0.8768, a dimensionless value between 0 and 1.15 (the sum of all weights). This score comprehensively assesses the degree to which the transaction deviates from the user's historical behavior pattern across four dimensions: amount, payee, category, and time. It also takes into account the synergistic effect of abnormal amounts and payees. The higher the score, the greater the degree of abnormality in the transaction and the higher the potential risk. A score close to 0.9 is generally considered a high-risk signal because it significantly deviates from the "normal" transaction behavior space learned by the model. This score will be directly used in the next step to compare with a preset threshold to determine the final risk level of the transaction.

[0110] The steps to obtain the transaction risk level assessment result are as follows:

[0111] Based on the transaction cognitive load score, the transaction cognitive load score is compared with the system's preset cognitive load threshold value by value. If the transaction cognitive load score is greater than or equal to the cognitive load threshold, the transaction is determined to be in a high-risk state; otherwise, it is determined to be in an acceptable state, and a transaction risk level determination result is generated.

[0112] Specifically, based on the transaction cognitive load score calculated in the previous process, the system compares this score with a dynamically adjusted cognitive load threshold. This threshold is not a fixed value but is determined through continuous analysis of historical transaction data across the entire platform. Specifically, the risk analysis team first extracts all transaction records from the past three months from the data warehouse. Each record includes its calculated transaction cognitive load score and a clear label (i.e., "fraudulent" or "normal," derived from subsequent user complaints, case investigations, or automated fraud detection systems). Using this large labeled dataset, the system constructs a Receiver Operational Characteristic (ROC) curve. By progressively moving the threshold from 0 to the highest score, it calculates the true positive rate (the proportion of fraudulent transactions identified) and the false positive rate (the proportion of normal transactions mistakenly identified as fraud) at each threshold point. The risk strategy department then determines the false positive rate based on business objectives, such as controlling the false positive rate to 0.1%. Under the following conditions, the system maximizes the true positive rate to select the optimal threshold point from the ROC curve. For example, analysis shows that when the threshold is set to 0.75, 85% of fraudulent transactions can be captured, while only 0.08% of normal transactions are falsely blocked. This balance point is considered the optimal choice within the current business cycle. Therefore, the system's preset cognitive load threshold is set to 0.75. This threshold is automatically recalculated and updated weekly. After obtaining the threshold, the system performs a simple floating-point comparison. For example, if the cognitive load score (GH) calculated in the previous step is 0.8768, the system determines that 0.8768 is greater than or equal to 0.75, and therefore classifies the risk level of this transaction as "high risk." Conversely, if the calculated score is 0.6, it is determined to be less than 0.75, and the risk level is "acceptable." Finally, this binary judgment is encapsulated into a data structure containing a status code and descriptive text to generate the transaction risk level judgment result.

[0113] The steps to obtain a dynamic password-free payment limit are as follows:

[0114] Based on the transaction risk level assessment result, select the limit suppression coefficient that matches the assessment result from the limit suppression coefficient preset mapping table, and at the same time retrieve the comprehensive equipment security score as the basic limit value to calculate the limit suppression coefficient and the basic limit value, and generate the initial calculation result of the dynamic password-free limit.

[0115] Based on the initial calculation result of the dynamic password-free limit, unit conversion, numerical precision truncation and field identifier appending processing are performed, and transaction request number and user unique identifier fields are added to generate the dynamic password-free payment limit.

[0116] Specifically, based on the transaction risk level assessment result generated in the previous step, the system immediately queries the corresponding suppression coefficient from a globally configured "credit limit suppression coefficient preset mapping table" loaded in memory. This mapping table is a simple set of key-value pairs, the contents of which are defined by the risk management strategy team and embedded in the payment server's configuration file. The table is constructed based on the risk mitigation measures to be taken under different risk levels. Specifically, when the transaction risk level assessment result is "acceptable," the system considers the current transaction to conform to the user's normal behavior pattern and the risk to be within a controllable range. Therefore, the corresponding credit limit suppression coefficient is set to 1.0, indicating that no credit limit suppression is performed and the credit limit derived from the device security assessment is fully adopted. When the transaction risk level assessment result is "high-risk," the system considers the transaction to have a significant possibility of fraud and requires the strongest intervention measures. At this time, the corresponding credit limit suppression coefficient is set to 1.0. The restriction coefficient is set to 0.0. This is to reduce the dynamic password-free limit to zero, thereby forcing users to use strong identity verification such as password, fingerprint, or facial recognition to complete the payment. After finding a matching limit restriction coefficient, the system retrieves the comprehensive device security score calculated in the previous steps from the current transaction's session context. This score is a monetary value representing the available limit based on the device environment, such as 617.1 yuan. Subsequently, the system performs a multiplication operation, multiplying the comprehensive device security score by the retrieved limit restriction coefficient. For example, if the judgment result is "high-risk status", the calculation process is 617.1 multiplied by 0.0, and the result is 0.0. If the judgment result is "acceptable status", the calculation process is 617.1 multiplied by 1.0, and the result is 617.1. The final value of this multiplication operation is the initial calculation result of the dynamic password-free limit.

[0117] Based on the initial calculation result of the dynamic password-free limit generated in the previous step, the system will perform a series of standardization and encapsulation processes on this raw floating-point number. First, unit conversion and numerical precision truncation are performed. The core accounting module of the payment system uniformly uses the smallest currency unit for processing. For example, for RMB, the smallest unit is "fen" (cent). Therefore, the system will multiply the initial calculation result in "yuan" (yuan) by 100 and round it down. For example, if the initial calculation result is 617.1 yuan, it will be converted to 61710 fen; if the initial calculation result is 0.0 yuan, it will still be converted to 0 fen. Next, to comply with financial message standards, the system will format this integer value into a specific precision value. For example, for scenarios where it needs to be displayed in yuan, the system will divide it by 100 and truncate it to two decimal places. The decimal value is 617.10 or 0.00. Next comes the additional processing of field identifiers. The system creates a new data object, stores this processed value as the core field, and appends several necessary context identifier fields. These fields are directly read from the current transaction's session cache. Specifically, this includes appending a unique transaction request number to identify this payment request, such as a 32-bit string generated from a timestamp and a random number, and appending a unique user identifier field to identify the payment initiator, such as the user's internal ID or encrypted mobile phone number. This process integrates the scattered calculation results and transaction context information into a unified, self-contained data structure, such as generating a JSON object {"dynamic_limit_in_cents": 0, "formatted_limit": "0.00", "currency": "CNY", "transaction_id": "...", "user_id":"..."}. This complete data structure, containing the final limit, currency unit, transaction, and user identifier, is the final generated dynamic password-free payment limit.

[0118] The above are merely preferred embodiments of the present invention and are not intended to limit the present invention in any other way. Any person skilled in the art may make changes or modifications to the above-disclosed technical content to create equivalent embodiments that can be applied to other fields. However, any simple modifications, equivalent changes, and modifications made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the protection scope of the present invention.

Claims

1. A method for dynamically adjusting the mobile payment password-free limit, characterized in that, Includes the following steps: When a payment terminal initiates a payment request, it collects discrete data on the network environment, device unlocking method, SIM card status, system integrity, and application environment in real time to establish a device security state vector. Based on the payment protocol, the device security status vector is invoked to generate a device security product attenuation value. The maximum password-free limit benchmark value set by the user is calculated with the device security product attenuation value to obtain a comprehensive device security score. After receiving a payment request, the payment server extracts the transaction amount, payee account information, product category information, and transaction time information, establishes a cognitive load factor set, and calculates the transaction cognitive load score based on each factor in the cognitive load factor set. The transaction cognitive load score is compared with the set cognitive load threshold to establish a transaction risk level determination result. The comprehensive device security score is used as the base limit, and the transaction risk level determination result is called to generate a dynamic password-free payment limit. The steps for obtaining the device security state vector are as follows: After receiving a payment request from a user, the payment terminal extracts the device's current network connection type, screen unlock method, whether a SIM card is inserted and its carrier affiliation, whether the system has been tampered with, and the container environment attributes of the running application, and generates five discrete states: network connection type, screen unlock method, SIM card status identifier, system verification status, and container environment attributes. Based on the five discrete states of network connection type, screen unlocking method, SIM card status identifier, system verification status and container environment attribute, each discrete state is mapped one by one according to the security level value. The mapping result is assigned the network environment component, device unlocking method component, SIM card status component, system integrity component and application environment component in sequence. Based on the network environment component, device unlocking method component, SIM card status component, system integrity component, and application environment component, they are arranged in a unified order to form a column vector, and each component is organized and stored according to the vector structure to generate a device security status vector.

2. The method for dynamically adjusting the mobile payment password-free limit according to claim 1, characterized in that, The steps for obtaining the device safety product attenuation value are as follows: Based on the device security state vector, the network environment component, device unlocking method component, SIM card status component, system integrity component, and application environment component are extracted sequentially to calculate and generate the device security product attenuation value.

3. The method for dynamically adjusting the mobile payment password-free limit according to claim 1, characterized in that, The steps for obtaining the integrated equipment safety score are as follows: The comprehensive equipment security score is calculated based on the equipment security product attenuation value and the maximum password-free limit benchmark value.

4. The method for dynamically adjusting the mobile payment password-free limit according to claim 1, characterized in that, The steps for obtaining the set of cognitive load factors are as follows: After receiving a payment request, the payment server extracts the transaction amount field, payee account identifier field, product category field, and transaction time field from the request one by one, and records them in the transaction parameter cache according to the preset structure, thus obtaining the transaction amount field, payee account identifier field, product category field, and transaction time field; Based on the transaction amount field, payee account identifier field, product category field, and transaction time field, the mean, frequency, and time distribution indicators of the corresponding fields for users in the transaction history database are called respectively. The deviation value extraction, frequency statistics, and window difference calculation methods are used to calculate the amount deviation factor, payee unfamiliarity factor, product category rarity factor, and time sensitivity factor to obtain the cognitive load factor set.

5. The method for dynamically adjusting the mobile payment password-free limit according to claim 1, characterized in that, The steps for obtaining the transaction cognitive load score are as follows: Calculate the transaction cognitive load score based on the set of cognitive load factors.

6. The method for dynamically adjusting the mobile payment password-free limit according to claim 1, characterized in that, The steps for obtaining the transaction risk level determination result are as follows: Based on the transaction cognitive load score, the transaction cognitive load score is compared with the system's preset cognitive load threshold value by value. If the transaction cognitive load score is greater than or equal to the cognitive load threshold, the transaction is determined to be in a high-risk state; otherwise, it is determined to be in an acceptable state, and a transaction risk level determination result is generated.

7. The method for dynamically adjusting the mobile payment password-free limit according to claim 1, characterized in that, The steps for obtaining the dynamic password-free payment limit are as follows: Based on the transaction risk level determination result, select the limit suppression coefficient that matches the determination result from the limit suppression coefficient preset mapping table, and at the same time retrieve the comprehensive device security score as the basic limit value, calculate the limit suppression coefficient and the basic limit value, and generate the initial calculation result of the dynamic password-free limit. Based on the initial calculation result of the dynamic password-free limit, unit conversion, numerical precision truncation, and field identifier appending processing are performed to add transaction request number and user unique identifier fields to generate the dynamic password-free payment limit.

Images