Transaction security control method and apparatus, electronic device, and storage medium

Abstract

This application provides a transaction security control method, apparatus, electronic device, and storage medium, relating to the field of financial technology. The method includes: determining a location deviation value based on current location information; determining a user behavior value based on historical trajectory profiles; determining a transaction amount value based on the current transaction amount; determining a target risk value based on the target party information; obtaining location deviation weight, user behavior weight, transaction amount weight, and transaction target weight; calculating the sum of the products of the location deviation weight and location deviation value, the user behavior weight and user behavior value, the transaction amount weight and transaction amount value, and the transaction target weight and target risk value to obtain a transaction risk value; determining a risk level based on the transaction risk value; and performing transaction control based on the risk level. This method improves the accuracy of transaction risk identification.

Description

Technical Field

[0001] This application relates to the field of financial technology, and in particular to a transaction security control method, device, electronic device and storage medium. Background Technology

[0002] With the acceleration of globalization and digitalization, users are increasingly engaging in cross-border travel, business trips, and online payments, making it difficult for traditional static security lock mechanisms to meet dynamic risk control needs.

[0003] Existing transaction security risk assessments typically rely on automated interception models based on simple rules. These systems use pre-set static rules to determine risk, comparing the transaction location with the user's "frequently used" locations. For example, when a user commutes between locations A and B, the system might frequently trigger verification due to a failure to recognize this recurring behavior. In complex environments like airports, GPS location drift might misjudge the user's location as being overseas, leading to the interception of legitimate transactions. Such rules, relying solely on geographical location, result in a high false positive rate. Clearly, current technology over-depends on the single dimension of geographical location, leading to insufficient ability to identify user transaction risks.

[0004] Therefore, a method is needed to improve the accuracy of identifying user transaction security risks in order to protect user transaction security. Summary of the Invention

[0005] This application provides a transaction security control method, device, electronic device, and storage medium to solve the technical problem of low accuracy in identifying user transaction risks.

[0006] In a first aspect, embodiments of this application provide a transaction security control method, comprising: acquiring a user's current location information; determining a location deviation value based on the current location information, wherein the location deviation value represents the degree of deviation between the current location information and a preset location; determining a user's historical trajectory profile; determining a user behavior value based on the historical trajectory profile, wherein the user behavior value represents the degree of deviation between the current location information and the historical trajectory profile; acquiring a user's current transaction amount; determining a transaction amount value based on the current transaction amount, wherein the transaction amount value represents the degree of deviation between the transaction amount and a preset amount; acquiring transaction target information; determining a target risk value based on the transaction target information, wherein the target risk value represents the number of transactions between the user and the transaction target, and the transaction target information characterizes the identity of the transaction target; acquiring a location deviation weight, a user behavior weight, a transaction amount weight, and a transaction target weight; calculating the sum of the product of the location deviation weight and the location deviation value, the product of the user behavior weight and the user behavior value, the product of the transaction amount weight and the transaction amount value, and the product of the transaction target weight and the target risk value to obtain a transaction risk value; determining a risk level based on the transaction risk value, and performing transaction control based on the risk level.

[0007] In one possible embodiment, obtaining the user's current location information includes: identifying the user's current scenario; if the current scenario is a public transportation scenario, obtaining the current location information through a first positioning method; if the current scenario is not a public transportation scenario, obtaining the current location information through a second positioning method, wherein the positioning accuracy of the first positioning method is higher than that of the second positioning method.

[0008] In one possible embodiment, obtaining current location information through a first positioning method includes: obtaining the user's location information in a global positioning system to obtain first location information; obtaining the location information of the user's device in a wireless local area network to obtain second location information; obtaining the user's location information in a Bluetooth positioning system to obtain third location information; and fusing the first location information, second location information, and third location information to obtain current location information.

[0009] In one possible embodiment, determining a user's historical trajectory profile includes: obtaining the user's historical location within a predetermined historical time period to obtain a location time series; performing a Fourier transform on the location time series to obtain a spectrum sequence corresponding to the location time series; and training the above spectrum sequence using a neural network model to obtain a historical trajectory profile, wherein the neural network model is trained using multiple sets of data, and each set of data includes a historical spectrum sequence and a historical trajectory profile.

[0010] In one possible embodiment, obtaining the location deviation weight, user behavior weight, transaction amount weight, and transaction target weight includes: obtaining the basic location deviation weight, basic user behavior weight, basic transaction amount weight, and basic transaction target weight; determining the scenario factor coefficient based on the current location information, and determining the behavior factor coefficient based on the current location information and historical trajectory profile, wherein the scenario factor coefficient represents the risk level of the location corresponding to the current location information, and the behavior factor coefficient represents the risk level of the user's behavior; calculating the product of the basic location deviation weight, the scenario factor coefficient, and the behavior factor coefficient to obtain the location deviation weight; calculating the product of the basic user behavior weight, the scenario factor coefficient, and the behavior factor coefficient to obtain the user behavior weight; calculating the product of the basic transaction amount weight, the scenario factor coefficient, and the behavior factor coefficient to obtain the transaction amount weight; and calculating the product of the basic transaction target weight, the scenario factor coefficient, and the behavior factor coefficient to obtain the transaction target weight.

[0011] In one possible embodiment, determining the risk level based on the transaction risk value includes: obtaining a basic threshold, a trajectory stability coefficient, and a travel frequency coefficient, where the trajectory stability coefficient represents the stability of the user's travel trajectory and the travel frequency coefficient represents the frequency of the user's travel; calculating the product of the basic threshold, the trajectory stability coefficient, and the travel frequency coefficient to obtain a risk threshold; calculating the sum of the transaction risk value and the risk threshold to obtain a total transaction risk value; determining the risk level as high risk if the total transaction risk value is greater than a first preset threshold; and determining the risk level as medium risk if the total transaction risk value is greater than a second preset threshold and less than or equal to the first preset threshold, where the second preset threshold is less than the first preset threshold.

[0012] In one possible embodiment, transaction control based on risk level includes: freezing the user's transaction account when the risk level is high, obtaining multiple verification information of the user, verifying the verification information, and unfreezing the transaction account if the verification is successful, with the verification information used to verify the user's identity; and obtaining the user's physiological verification information when the risk level is medium, verifying the physiological verification information, and allowing the transaction if the verification is successful.

[0013] In one possible embodiment, after controlling transactions based on risk levels, the method further includes: if a transaction is locked, obtaining the user's real-time scene information and transportation voucher information; determining the user's destination information based on the real-time scene information and transportation voucher information, and comparing the destination information with the current location information; if the destination information and the current location information represent the same location, unlocking the transaction; if the destination information and the current location information represent different locations, continuing to lock the transaction.

[0014] In one possible embodiment, the method further includes: after unlocking a transaction, marking the transaction as a negative sample, inputting the negative sample into a neural network model of historical trajectory profile for training, so as to obtain a more accurate neural network model; after continuing to lock transactions, marking the transaction as a positive sample, and increasing the target weight of the transaction.

[0015] Secondly, embodiments of this application provide a transaction security control device, comprising: a first determining module, configured to acquire a user's current location information and determine a location deviation value based on the current location information, wherein the location deviation value represents the degree of deviation between the current location information and a preset location; a second determining module, configured to determine a user's historical trajectory profile and determine a user behavior value based on the historical trajectory profile, wherein the user behavior value represents the degree of deviation between the current location information and the historical trajectory profile; a third determining module, configured to acquire a user's current transaction amount and determine a transaction amount value based on the current transaction amount, wherein the transaction amount value represents the degree of deviation between the transaction amount and a preset amount; and a fourth determining module, configured to acquire... The system comprises five modules: a transaction target information module, a transaction target party information module, and a transaction target information module. The first module is used to determine the target risk value based on the transaction target information. The target risk value represents the number of transactions between the user and the transaction target party, and the transaction target information identifies the transaction target party. The second module is used to obtain the location deviation weight, user behavior weight, transaction amount weight, and transaction target weight. The third module is used to calculate the sum of the products of the location deviation weight and the location deviation value, the user behavior weight and the user behavior value, the transaction amount weight and the transaction amount value, and the transaction target weight and the target risk value, thus obtaining the transaction risk value. The fourth module is used to determine the risk level based on the transaction risk value and to perform transaction control based on the risk level.

[0016] Thirdly, embodiments of this application provide an electronic device, including: a processor, and a memory communicatively connected to the processor; the memory stores computer-executable instructions; the processor executes the computer-executable instructions stored in the memory to implement the method provided above.

[0017] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the methods provided above.

[0018] The transaction security control method, device, electronic device, and storage medium provided in this embodiment determine the location deviation value by acquiring the current location information, determining the user behavior value based on historical trajectory profiles, determining the transaction amount value based on the current transaction amount, and determining the target risk value based on the transaction target information. By combining the location deviation weight, user behavior weight, transaction amount weight, and transaction target weight, the transaction risk value is calculated. This enables a multi-dimensional and comprehensive risk characterization of the transaction scenario, reducing misjudgments caused by relying solely on static rules or a single location dimension. Furthermore, differentiated transaction control is implemented based on the risk level corresponding to the transaction risk value. This improves the accuracy and continuity of transaction risk control while also taking into account the user verification burden, thereby enhancing the accuracy of identifying user transaction risks. Attached Figure Description

[0019] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0020] Figure 1 This is a schematic flowchart of a transaction security control method provided in an embodiment of this application;

[0021] Figure 2 A flowchart illustrating a mechanism for dynamic positioning accuracy adjustment provided in this application embodiment;

[0022] Figure 3 A schematic diagram of a specific transaction security control method provided in this application embodiment;

[0023] Figure 4 A decision-making flowchart for a dynamic security lock mechanism provided in an embodiment of this application;

[0024] Figure 5 This is a schematic diagram of a transaction security control device provided in an embodiment of this application.

[0025] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0026] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0027] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of the relevant data all comply with the relevant laws, regulations, and standards of the relevant regions, have taken necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation portals for users to choose to authorize or refuse.

[0028] Furthermore, the technical solution involved in this application, which involves big data analysis of user information (including but not limited to personal biometrics, identity data, consumption data, asset data, electronic terminal operation data, etc.) and the use of artificial intelligence technology for automated decision-making, and makes decisions that have a significant impact on personal rights based on the results of automated decision-making, provides users with corresponding operation entry points for users to choose to agree to or reject the results of automated decision-making; if the user chooses to reject, the process will proceed to the expert decision-making process.

[0029] It should be noted that the transaction security control method, device, electronic device and storage medium provided in this application can be used in the field of financial technology, or in any field other than financial technology. The application field of the transaction security control method, device, electronic device and storage medium in this application is not limited.

[0030] The specific application scenario of this application is user transaction or payment scenarios. When a user initiates a transfer or transaction request on a financial client, the financial client verifies the request in the cloud. If the verification is successful, the transaction or transfer requested by the user is approved, and the merchant or the transaction target party receives the transaction amount or transfer from the user, thus the transaction is successful.

[0031] Financial transaction risk control technology is primarily applied to scenarios such as account security management, online and offline payment control, and cross-regional transaction risk identification for financial institutions. It is typically deployed in the collaborative links between the core business systems, mobile clients, payment acceptance terminals, and merchant transaction systems of financial institutions. When users initiate card swiping, QR code scanning, or online payment transactions at locations such as shopping malls, airports, ports, subway stations, and cross-border transportation hubs, the financial institution's risk control system needs to consider the user's current location, account usage history, transaction amount, and counterparty information to determine whether to allow the transaction, whether verification is required, or whether it should be blocked. Especially in high-fluidity scenarios such as cross-border commuting, frequent business trips, and cross-regional consumption, transaction requests are often time-sensitive and continuous. The risk control system must ensure the ability to identify abnormal transactions while minimizing disruption to normal transactions; therefore, this type of technology has become a crucial foundational capability in financial transaction security control.

[0032] Existing financial transaction risk control solutions typically fall into two categories. One involves users manually enabling or disabling security measures, such as temporarily disabling overseas transaction restrictions before departure and re-enabling them upon return. In this case, the system primarily executes user-defined rules. The other involves financial institutions automatically assessing risks based on preset rules. For example, the system compares the user's current location with preset locations such as their usual residence, account opening location, or historically frequently used areas. When significant location deviations, abnormal transaction amounts, or unfamiliar counterparties are detected, transaction interception, SMS verification codes, or manual verification are triggered. These solutions largely operate around several static thresholds, combining factors such as location, amount, and transaction counterparties individually or in simple combinations to arrive at a risk assessment result. However, these solutions have significant limitations in practical applications. First, existing solutions are heavily reliant on location factors and typically rigidly compare the current location with preset locations. This makes it difficult to adapt to users' continuous movement behaviors, such as cross-border commuting or periodic business trips, potentially leading to even legitimate transactions being flagged as abnormal. Secondly, users' historical travel and consumption patterns are often not effectively extracted into behavioral benchmarks for decision-making. The system cannot distinguish between normal deviations that "frequently occur" and abnormal deviations that "never happen," making it easier for high-frequency mobile users to repeatedly trigger verifications at airports, ports, and business trips. Thirdly, the assessment of abnormal amounts and transaction risk in traditional solutions is usually rather crude, failing to establish a linkage analysis with location and behavioral deviations. This can easily lead to a single factor amplifying overall risk or insufficient identification of multiple factors. Furthermore, in cases of location drift, signal obstruction, or unreasonable preset location settings, risk assessment results may significantly deviate from the actual scenario, resulting in false locking, transaction interruptions, and increased verification burden, making it difficult to balance the accuracy and continuity of risk control with user experience.

[0033] In view of this, how to more accurately identify transaction risks in complex mobile scenarios and reduce interference with normal transactions while controlling abnormal transactions has become an urgent technical problem to be solved.

[0034] The transaction security control method, device, electronic equipment, and storage medium provided in this application are intended to solve the above-mentioned technical problems of the prior art.

[0035] The technical solution of this application and how it solves the technical problems will be described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will be described below with reference to the accompanying drawings.

[0036] Figure 1 This is a schematic flowchart of a transaction security control method provided in an embodiment of this application, such as... Figure 1 As shown, it includes:

[0037] S101: Obtain the user's current location information, determine the location deviation value based on the current location information, and the location deviation value indicates the degree of deviation between the current location information and the preset location.

[0038] In this embodiment of the application, the user's current location information is location data used to characterize the user's current location. Its function is to serve as the basic input for calculating the location deviation value and to participate in subsequent transaction risk assessment.

[0039] Location deviation value is a numerical value used to indicate the degree of deviation between the current location information and the preset location. Its function is to reflect whether the user's current location is abnormal and to serve as a factor in the calculation of transaction risk value.

[0040] In practice, the implementing entity can be a risk control server deployed in the core transaction system of a financial institution, or a risk control engine that is linked with mobile financial institution clients, payment gateways, and acquiring systems.

[0041] Upon receiving a transaction request initiated by a user, the system first extracts the user identifier, transaction time, terminal type, and transaction initiation channel corresponding to the transaction from the transaction context, and collects the current location information based on the transaction time.

[0042] After obtaining the location data, the system preprocesses it, including timestamp alignment, coordinate system unification, drift point removal, and reliability assessment. If multiple location results exist at the same time, the system can determine the target location result based on location accuracy, update time, and historical stability, or use a weighted fusion method to obtain unified current location information.

[0043] Preset locations can be a user's frequently used location, a pre-defined permitted transaction location, the user's account opening location, long-term residence, workplace, or a geographical area set by the financial institution according to its risk strategy. The system can read the set of preset locations from the user profile database and select the currently valid preset location according to transaction time, transaction type, or account status. For example, the workplace can be the primary preset location during weekdays, and the residence can be the primary preset location at night. Cross-border accounts can also be configured with two preset location sets: a domestic permanent residence area and a frequently used overseas area.

[0044] After determining the current location information and the preset location, the system generates a location deviation value based on the difference between the two.

[0045] In one possible embodiment, the system directly calculates the geographical distance between the current location point and the preset location center point, and maps this distance to a standardized deviation value.

[0046] In another possible embodiment, the system determines whether the current location point falls within a preset electronic fence. When the location point is within the fence, the position deviation value is taken as a lower range. When the location point is outside the fence and the radius gradually increases, the position deviation value increases proportionally. The degree of deviation can also be represented by regional difference, administrative difference, or city difference.

[0047] In an exemplary implementation, the location deviation value can be represented as Dpos = f(Lcur, Lpre), where Lcur represents the current location information, Lpre represents the preset location, and f can be a distance difference function, a fence difference function, or a normalized area difference function. When the user is near the preset location, the location deviation value is close to a low value; when the user is far from the preset location and in an area inconsistent with historical activity, the location deviation value increases.

[0048] Through processing, the system transforms raw location data into numerical results that can participate in unified risk quantification, establishing a locational basis for risk identification in complex mobile scenarios. Analysis shows that this step, by standardizing the collection and deviation quantification of current location information, reduces the crude judgments caused by relying solely on static geographical comparisons. This helps retain the ability to identify location factors in high-frequency mobile and cross-regional transaction scenarios, while avoiding the direct judgment of normal transactions as abnormal due to simple location changes.

[0049] S102: Determine the user's historical trajectory profile, and determine the user's behavior value based on the historical trajectory profile. The user behavior value represents the degree of deviation between the current location information and the historical trajectory profile.

[0050] In this embodiment of the application, the user's historical trajectory profile is profile information used to characterize the user's historical travel and location distribution characteristics. Its function is to serve as a basis for judging whether the user's behavior conforms to historical patterns.

[0051] User behavior value is a numerical value used to represent the degree of deviation between current location information and historical trajectory profile. Its function is to measure whether the user's current behavior deviates from the existing trajectory pattern and to participate in the calculation of transaction risk value.

[0052] In practice, after receiving a current transaction request, the system can retrieve the user's location records, transaction location records, device login location records, and auxiliary geographic records related to legal authorization from the historical behavior database within a preset time period. The system will then map these records to a time axis and spatial coordinate system to construct a sample set of the user's historical activities.

[0053] The preset time period can be the past 30 days, the past 90 days, the past 6 months, or a rolling time window based on weeks or months, to ensure that the historical trajectory profile can reflect stable habits and can be dynamically updated as users' lifestyles or work patterns change.

[0054] Historical trajectory profiles can be stored in a structured record format, including the region center point, region radius, time label, frequency label, period label, and credibility label, or they can be represented in a vector format for quick matching with current location information.

[0055] After determining the historical trajectory profile, the system generates a user behavior value based on the degree of deviation between the current location information and the profile. In an exemplary implementation, the system first determines whether the current location falls within the core activity area or an identified periodic passage area in the historical trajectory profile, and then determines the degree of matching by combining the current time with whether it coincides with the high-frequency occurrence time period in the profile. If both spatial location and temporal characteristics match, the user behavior value is low, indicating that the current behavior is consistent with historical patterns. If the spatial location deviates but belongs to a low-frequency area where the user has appeared multiple times, the user behavior value is in the middle range. If both spatial location and temporal characteristics are significantly inconsistent with the profile, the user behavior value is high.

[0056] User behavior values ​​can be represented as Dbeh = g(Lcur, Puser), where Lcur represents the current location information, Puser represents the historical trajectory profile, and g represents a function that comprehensively calculates spatial deviation, temporal deviation, and periodic deviation. This function can use weighted distance, cluster center deviation, trajectory similarity, or the reverse mapping result of a normalized matching score. It should be understood that this example is for demonstration purposes only and is not limiting. The method of forming the historical trajectory profile and calculating the user behavior values ​​can be adjusted according to the actual application scenario, as long as it can represent the degree of deviation between the current location information and the historical trajectory profile.

[0057] By introducing historical trajectory profiling, this application's embodiments do not simply make a rigid comparison between the current location and a single fixed location. Instead, they determine whether the current location has historical interpretability based on the user's long-term behavioral patterns. For frequently occurring business districts, airports, ports, remote offices, or cross-border commuting routes outside the user's usual residence, the system can identify them as recurring normal activity patterns, thereby reducing the probability of false positives. Based on analysis, this step can effectively distinguish between frequently occurring normal deviations and unprecedented abnormal deviations, thus improving the problem of repeated verification triggers in high-mobility scenarios and enhancing the consistency between risk control results and actual behavior.

[0058] S103: Obtain the user's current transaction amount, determine the transaction amount value based on the current transaction amount, and the transaction amount value indicates the degree of deviation between the transaction amount and the preset amount.

[0059] In this embodiment of the application, the user's current transaction amount is used to represent the amount of the transaction that has occurred, and its function is to serve as one of the input factors for judging transaction risk.

[0060] The transaction amount value is a numerical value used to indicate the degree of deviation between the transaction amount and the preset amount. Its function is to reflect whether the transaction scale is abnormal and to participate in the calculation of the transaction risk value.

[0061] In practice, upon receiving a transaction authorization request, the system extracts information such as the transaction amount, currency, merchant category, transaction channel, and transaction type from the transaction message. If necessary, it converts the foreign currency amount to the account's base currency to eliminate the impact of different currencies on subsequent comparison calculations. For special scenarios such as installment transactions, pre-authorized transactions, and rescinded / retransmitted transactions, the system can also convert the current transaction amount into a comparable standard amount according to business rules, such as using the frozen amount, the initial installment amount, or the equivalent converted amount.

[0062] The preset amount is used as a comparison benchmark. It can be a pre-configured amount threshold, a user's frequently used transaction amount, a typical transaction amount under a specific merchant category, or a reference amount formed by multi-dimensional historical statistical results.

[0063] In an exemplary implementation, the system can extract the average transaction amount, median transaction amount, quantile amount, and amount distribution for various scenarios from the user's historical transaction records over a recent period, and select a suitable preset amount based on the current transaction scenario. For example, for high-frequency consumption scenarios such as dining, transportation, and retail, the preset amount can be the historical median value for that scenario; for large-amount transfers or cross-border payments, the preset amount can be a scenario threshold. This approach avoids distortion caused by direct comparisons between different consumption types.

[0064] After determining the current transaction amount and the preset amount, the system obtains the transaction amount value by comparing the difference between the two. In one possible embodiment, the transaction amount value is obtained by normalizing the difference between the current transaction amount and the preset amount; in another possible embodiment, the transaction amount value is generated by mapping the ratio of the two, and when the current transaction amount is significantly higher than the preset amount, the transaction amount value increases as the excess ratio increases; for cases where the amount is lower than the preset amount but significantly deviates from the lower limit of the normal distribution, a corresponding deviation value can also be generated according to preset rules to deal with risk patterns such as tentative small-amount fraud.

[0065] In an exemplary implementation, the transaction amount can be represented as Damt = h(Acur, Aref), where Acur represents the current transaction amount, Aref represents the preset amount, and h represents the difference function, ratio function, or deviation function based on probability distribution. To ensure that the transaction amount can stably participate in subsequent weighted summations, the system can normalize the calculation results to a uniform numerical range, such as between zero and one or between zero and one hundred, and truncate extreme outliers to prevent a single monetary factor from infinitely amplifying the overall risk.

[0066] Through this processing, the system can quantify the anomalies in transaction amounts based on users' habitual spending patterns and the current transaction scenario, rather than simply applying fixed thresholds. For users who frequently travel for work and have relatively high normal spending, the system will not directly identify risk simply because the absolute value of the amount is high; for transactions occurring in low-frequency, high-amount, or unusually small-amount scenarios, the system can promptly increase the intensity of risk identification. Analysis shows that this step elevates the amount factor from a static rule to a dynamic indicator linked to user history and scenario, which helps reduce the crudeness of amount judgment and enhances the adaptability of risk assessment to real spending patterns.

[0067] S104: Obtain the transaction target party information, determine the target risk value based on the transaction target party information, the target risk value represents the number of transactions between the user and the transaction target party, and the transaction target party information represents the identity of the transaction target party.

[0068] In this embodiment of the application, the transaction target information is information used to characterize the identity of the transaction target, and its function is to identify the transaction object and assess the risks related to the transaction object.

[0069] The identity of the transaction target party is used to identify the identity attributes of the transaction target party, providing a basis for identifying transaction objects and assessing risks.

[0070] The target risk value is a numerical value used to represent the risk corresponding to the number of transactions between a user and the target party. Its function is to reflect the degree of transaction correlation between the user and the target party, and it serves as a component of the transaction risk value calculation.

[0071] In practice, the system extracts merchant ID, merchant name, terminal ID, payment account identifier, payment institution identifier, acquiring institution identifier, merchant category code, and necessary device fingerprint information from the current transaction message. It then uses an identity mapping table to uniformly convert fields from different sources into identifiable identity identifiers for the transaction target. For situations where the same merchant has multiple terminals, multiple stores, or multiple payment accounts, the system can establish hierarchical identity associations at the merchant entity level, store level, or terminal level to balance recognition accuracy and statistical stability.

[0072] After obtaining the information of the target party in the transaction, the system retrieves the transaction records between the user and the target party from the historical transaction database to count the number of historical transactions between the two parties, the time of the most recent transaction, the transaction frequency, and the continuity of the transaction scenario.

[0073] In one possible embodiment, the system aggregates historical records according to the identity of the transaction target party to obtain the cumulative number of transactions between the user and the target party, and uses this number as the direct basis for the target risk value. In another possible embodiment, in addition to considering the cumulative number of transactions, the system also combines the recent transaction time interval for correction. If the target party has appeared continuously recently, the target risk value shows a relatively stable familiar relationship. If the target party has never appeared or has only appeared once and the current transaction scenario is abnormal, the target risk value shows a corresponding unfamiliar relationship.

[0074] Since the target risk value in this application represents the number of transactions between the user and the target party, the number of transactions can be converted into a target relationship score during the specific numerical mapping, and then further mapped into a standardized value that can participate in risk calculation. In order to maintain consistency with the direction of the risk summation model, the system can pre-define mapping rules, such as the lower the number of transactions, the higher the corresponding risk representation; or first generate a transaction count value, and then convert it into a target risk value with a consistent risk direction in the subsequent unified mapping stage.

[0075] In an exemplary implementation, the target risk value can be represented as Drisk = t(Nuser-target, Idtarget), where Nuser-target represents the number of historical transactions between the user and the target party, Idtarget represents the identity of the target party, and t represents a function that performs counting, grading, or normalization mapping based on the number of transactions. When a user has a long-term and stable transaction relationship with a merchant, a payee, or a terminal, the system can identify the target party as a familiar transaction partner, thereby reducing the risk increase caused by unfamiliarity with the target party during comprehensive evaluation. When the target party appears for the first time, and its location, time, or amount characteristics are simultaneously abnormal, this factor can provide a significant indication of overall risk. It should be understood that the example is for demonstration purposes only and is not limiting; the target risk value can be determined by counting, grading, or other methods that reflect the number of transactions.

[0076] Analysis shows that this step, by introducing the dimension of the transaction target, supplements the information on the relationship between the parties beyond location and amount. This allows risk control judgment to focus not only on where the transaction occurs and the amount, but also on who the transaction takes place with. This can reduce false interceptions when the user is in motion or the location is significantly off but the transaction partner remains stable over a long period. It can also promptly detect potential risks when the location seems normal but the transaction partner suddenly becomes unfamiliar, thereby enhancing the comprehensiveness of risk identification.

[0077] S105: Obtain the weights of location deviation, user behavior, transaction amount, and transaction target.

[0078] In this embodiment, the position deviation weight is a coefficient used to weight the position deviation value, and its function is to control the degree of influence of position factors in the calculation of transaction risk value.

[0079] Among them, user behavior weight is a coefficient used to weight user behavior values, and its function is to control the degree of influence of historical behavior factors in the calculation of transaction risk value.

[0080] Among them, the transaction amount weight is a coefficient used to weight the transaction amount value, and its function is to control the degree of influence of the amount factor in the calculation of transaction risk value.

[0081] Among them, the target weight is a coefficient used to weight the target risk value. Its function is to control the degree of influence of the target factor in the calculation of the target risk value.

[0082] In practice, the system can read various basic weights from the risk strategy configuration library and dynamically adjust the basic weights in combination with the current transaction scenario, account status, historical behavior stability and business supervision requirements, so as to obtain the four types of weights that actually participate in the risk calculation of this transaction.

[0083] By acquiring and dynamically adjusting weights, the system achieves fine-grained control over the contribution of multiple risk factors. Compared to simple equal-weighting, this step allows the risk model to adapt to different business scenarios. For example, in high-traffic areas such as airports and ports, location itself does not necessarily represent high risk; in this case, the location factor can be flexibly adjusted based on the stability of historical behavior. In scenarios involving large-amount transfers to unfamiliar recipients, abnormal characteristics can be highlighted by increasing the weight of the target and amount. Based on analysis, this step makes the subsequent comprehensive risk value more closely resemble the real transaction environment, reducing the interference of single-factor distortion on the overall judgment, and is an important support for achieving accurate risk control.

[0084] S106: Calculate the sum of the products of position deviation weight and position deviation value, user behavior weight and user behavior value, transaction amount weight and transaction amount value, and transaction target weight and target risk value to obtain the transaction risk value.

[0085] In this embodiment of the application, the transaction risk value is a comprehensive risk value that summarizes multiple risk factors. Its function is to serve as a direct basis for judging the risk level and executing transaction control.

[0086] In specific implementation, after the system completes the determination of the position deviation value, user behavior value, transaction amount value, target risk value and corresponding weights, each factor is input into the risk calculation module. To ensure that data from different sources and with different dimensions can participate in operations under a unified framework, the system may first perform standardization processing on the four types of factors before weighted summation to map them to a consistent numerical interval. The standardization method may adopt min-max normalization, segmented normalization, quantile mapping or risk level mapping, as long as the factors are comparable with each other.

[0087] In a possible embodiment, the system may further provide a direction unification module before summation, so as to ensure that all factors follow the unified rule that a larger numerical value indicates a higher risk. For example, when the target risk value is initially represented by the number of transactions, the system may first perform reverse mapping according to the number of transactions, so that a smaller number of transactions corresponds to a higher risk value, and a larger number of transactions corresponds to a lower risk value, before being included in the weighted summation. For abnormal and extreme individual factors, the system may further set an upper limit truncation and exception buffer mechanism to prevent the overall risk value from being distorted due to a single input noise. After the calculation is completed, the transaction risk value is written into the current transaction risk control record and sent to the level determination module.

[0088] In this step, the system of the present application no longer makes isolated judgments on a single factor, but forms a multi-factor linkage analysis result. For high-mobility users, even if the position deviation value is relatively large, as long as the historical trajectory portrait matching degree is high, the amount is in the normal range, and the transaction target is a familiar object, the comprehensive risk value can still be maintained in a reasonable interval; for the scenario where the position is seemingly normal but the transaction amount increases sharply and the transaction target is unfamiliar, the comprehensive risk value will rise significantly. Based on the analysis, this step realizes the unified quantitative expression of multiple risk factors through a linear combination method, which helps to improve the stability, accuracy and interpretability of transaction risk identification, thereby solving the problem of high misjudgment rate caused by the fragmented judgment of static thresholds in traditional solutions.

[0089] S107: Determine a risk level according to the transaction risk value, and perform transaction control according to the risk level.

[0090] In the embodiment of the present application, the risk level is a result obtained by grading the transaction risk value, and its function is to determine a subsequent transaction control strategy.

[0091] Transaction control is a process for controlling whether a transaction continues, whether verification is performed, or whether freezing is performed, and its function is to take corresponding measures according to the risk level to ensure transaction security.

[0092] In practice, after obtaining the transaction risk value, the system compares this value with a preset threshold range and maps it to the corresponding risk level. The preset thresholds can be configured by the bank based on historical risk event statistics, business tolerance requirements, and regulatory rules, or they can be set separately for different transaction types. After determining the risk level, the system executes the transaction control strategy that matches that level.

[0093] To enhance the model's closed-loop capability, the system can also write back the current risk level, the final control result, the user's subsequent appeal results, and the transaction authenticity label to the training sample library and the profile update module. This way, when a certain type of transaction is confirmed as genuine after multiple verifications, relevant thresholds or profile parameters can be gradually adjusted, thereby reducing interference from subsequent normal transactions of the same type. When an unfamiliar target or abnormal trajectory pattern is confirmed to be related to fraud, the system can increase the sensitivity of the corresponding strategy. Based on the analysis, a linkage exists between risk level and transaction control, enabling the transaction security control method not only to output risk assessment results but also to directly drive actual business processing actions, ensuring that abnormal transactions are suppressed while providing the smoothest possible processing experience for normal transactions. It should be understood that this example is for demonstration purposes only and is not limiting; the risk level classification method and the transaction control execution method can be adjusted according to actual needs.

[0094] The transaction security control method provided in this embodiment comprehensively quantifies current location deviation, historical behavior deviation, transaction amount deviation, and the relationship between the transaction target parties, and forms a transaction risk value under a unified weight framework. Then, risk levels are classified according to the transaction risk value, and release, verification, or interception controls are executed in conjunction with the risk level. This improves the accuracy of transaction risk judgment in complex mobile scenarios such as cross-border commuting, frequent business travel, and cross-regional consumption, reduces the false interference of traditional static threshold schemes on normal transactions, and maintains the ability to identify and suppress abnormal transactions, thereby improving the accuracy of identifying user transaction risks. It should be understood that this example is merely illustrative and not limiting. In one possible embodiment, the source of acquisition of various factors, the calculation model, the weight configuration method, and the transaction control strategy can all be adjusted according to the financial institution's business system architecture and actual risk control needs, but this does not affect the basic implementation principle of this application embodiment.

[0095] In one possible implementation, obtaining the user's current location information in step S101 can be achieved through the following steps:

[0096] Step S1011: Identify the user's current scenario. If the current scenario is a public transportation scenario, obtain the current location information through the first positioning method.

[0097] The current scenario characterizes the user's transaction or application environment and serves as the basis for determining the location mode switching. The public transportation scenario indicates that the user is in an environment with strong displacement continuity and signal change characteristics, such as subways, buses, intercity railways, airport express lines, and port connections. The current location information characterizes the user's current location and serves as the basic input for subsequent transaction risk assessment.

[0098] In its implementation, the system can identify the current scene based on network environment information reported by the terminal, base station switching characteristics, Bluetooth or wireless access point change characteristics, geofence hit results, and vehicle status information. When the identification result indicates that the user is in a public transportation scene, the terminal or server side activates a first positioning method to obtain the current location information. The first positioning method can be a combination of satellite positioning, WiFi fingerprint database, and Bluetooth beacon to improve the location reliability in public transportation scenarios such as tunnel passage, platform stops, and vehicle movement.

[0099] Step S1012: If the current scenario is not a public transportation scenario, obtain the current location information through the second positioning method. The positioning accuracy of the first positioning method is higher than that of the second positioning method.

[0100] The first positioning method is used to obtain high-precision positioning results in public transportation scenarios, while the second positioning method is used to obtain positioning results that meet business needs in non-public transportation scenarios.

[0101] When the identification result indicates that the user is not in a public transportation scenario, the second positioning method is activated to obtain the current positioning information. The second positioning method can use methods such as base station positioning to reduce terminal power consumption and reduce positioning resource consumption.

[0102] For example, when a user is in the core area of ​​a city, a coarse positioning of 200 meters is first generated based on the timing advance (TA) measurement of the base station combined with the radio frequency pattern map (RFPM). Then, the geomagnetic anomaly features are collected by the magnetometer built into the smartphone (sampling rate 10Hz), and the pattern is matched with the geomagnetic reference library to improve the positioning accuracy to 150-200 meters.

[0103] When the user is in the suburbs / countryside, enable dual-mode reception of GPS (Global Positioning System) and GLONASS (GLONASS) (with ≥6 visible satellites), introduce a digital elevation model (DEM) for terrain occlusion compensation, and finally use the least squares method to optimize the coordinate solution.

[0104] The first positioning method and the second positioning method can be executed by the positioning module within the same mobile terminal, or they can be completed collaboratively by the terminal and the server. In practical applications, the positioning module can also be selected from other models, and this application embodiment does not limit this.

[0105] Furthermore, to address complex situations such as signal loss and interference, this application also employs anti-interference compensation technology. First, a signal loss prediction model is established, using an exponential attenuation function based on historical signal attenuation data. The environmental attenuation coefficient τ is obtained through machine learning fitting (e.g., τ=0.3 in an airport scenario corresponds to metal structure penetration loss, and τ=0.8 in a tunnel scenario corresponds to rock absorption effect). Second, a multi-modal compensation mechanism is employed. For example, in enclosed underground spaces: when the prediction confidence level is <0.5, a 9-axis inertial measurement unit (IMU) is activated for dead reckoning, simultaneously scanning the MAC addresses of shop WiFi hotspots and matching them with a geofence database to achieve 72% accuracy recovery. Finally, for special geographical areas, such as: within a 10-kilometer buffer zone along the border, BeiDou RDSS short message communication is forcibly enabled, achieving 100% positioning availability through three GEO satellites; in desert / marine environments, ephemeris orbital parameters are used for prediction, combined with the user's historical path for cubic spline interpolation, controlling positioning drift within 5 kilometers.

[0106] Figure 2 A flowchart illustrating a dynamic positioning accuracy adjustment mechanism provided in this application embodiment is shown below. Figure 2 As shown, the process includes: startup; real-time scene recognition; determining whether the location is a transportation hub. If yes, high-precision mode is activated, integrating GPS, WiFi fingerprint, and Bluetooth beacon positioning, and incorporating base station triangulation compensation, outputting a positioning accuracy of ≤50 meters. If no, normal mode is activated, using GPS + base station positioning, outputting an accuracy of 500 meters to 1 kilometer.

[0107] In this process, the system first identifies the user's current scenario, then selects the appropriate positioning method based on the scenario type to obtain the current location. This ensures positioning accuracy in scenarios with rapid movement and complex environments, such as public transportation, while balancing positioning stability and resource consumption in ordinary scenarios. This method ensures that the current location information remains usable and reliable in different scenarios and provides a more reliable input for location deviation calculation in transaction security control. By adopting this implementation method, positioning methods can be dynamically switched according to the scenario, reducing location errors caused by insufficient accuracy of ordinary positioning methods in public transportation scenarios, thus reducing the probability of misjudging abnormal transactions. Simultaneously, in non-public transportation scenarios, positioning costs are reduced and acquisition stability is improved, thereby balancing positioning accuracy, continuity, and user experience.

[0108] In one possible implementation, step S1011, which obtains the current location information through a first positioning method, can be achieved through the following steps:

[0109] Step S1013: Obtain the user's location information in the Global Positioning System to obtain the first location information;

[0110] Among them, the Global Positioning System is used to provide the user's latitude and longitude location in the outdoor environment, and the first location information is obtained by the satellite positioning module based on the analysis of received satellite signals;

[0111] Step S1014: Obtain the location information of the user's device in the wireless local area network to obtain the second location information;

[0112] Wireless LAN is used to provide a device's location reference in a local network environment. The second location information is obtained by the terminal scanning the surrounding access point identifiers and matching them with a hotspot database.

[0113] Step S1015: Obtain the user's location information in the Bluetooth positioning system to obtain third-party location information;

[0114] Bluetooth positioning systems are used to provide positioning references in near-field scenarios. The third location information is obtained by the terminal receiving Bluetooth beacon broadcasts and combining them with beacon coordinate mapping.

[0115] Step S1016: Merge the first location information, the second location information and the third location information to obtain the current location information.

[0116] A user's location information can be represented as a coordinate point, a geographical region, or a location confidence interval, while the current location information is the unified location result after fusion.

[0117] In practical implementation, the terminal can simultaneously activate data acquisition channels for satellite positioning, Wi-Fi positioning, and Bluetooth positioning, and perform time synchronization processing on the position coordinates output by each channel to ensure that the three types of position information correspond to the same moment. During fusion, weights can be generated based on the signal strength, availability, historical stability, and positioning accuracy of each positioning source. The first, second, and third position information are then weighted and solved to output the fused coordinates as the current positioning information. When a signal from a certain source is missing or the error exceeds the limit, its weight can be reduced while retaining the valid results from other sources, thereby improving the continuity and reliability of the positioning results. For example, using Differential Global Positioning System (DGPS) to obtain an initial accuracy of 50 meters, spatial matching is performed by fusing a pre-built WiFi fingerprint database (collection point distance ≤ 10 meters). When a Bluetooth beacon (RSSI (Received Signal Strength Indicator) ≥ -70dBm) is detected, triangulation is initiated, ultimately converging the positioning error to within 50 meters. In practical applications, the weight calculation module can also adopt other models or implementation forms, and this application embodiment does not limit this.

[0118] This implementation method, by jointly acquiring and fusing information from different positioning sources, can leverage the wide coverage of the Global Positioning System, the availability of Wi-Fi in indoor scenarios, and the precision capabilities of Bluetooth positioning systems in close-range environments. This reduces the deviation caused by obstruction, drift, or environmental interference from a single positioning source, making the output current positioning information more consistent with the user's actual location.

[0119] This approach can improve positioning accuracy in complex scenarios such as shopping malls, airports, ports, and subway stations, and provide a more stable location input for subsequent transaction risk assessment. It also reduces false interceptions and verification disruptions caused by single-source positioning errors, thereby improving the accuracy of transaction security control and user experience.

[0120] Based on the aforementioned embodiments, step S102, which determines the user's historical trajectory profile, can be achieved through the following steps:

[0121] Step S1021: Obtain the user's historical location within a predetermined historical time period to obtain the location time series;

[0122] Among them, the predetermined historical time period is used to define the statistical interval of historical location. The user's historical location is the location record formed by the user within this time interval. The location time series is used to organize historical location data in chronological order to characterize the change process of user trajectory over time.

[0123] Step S1022: Perform a Fourier transform on the location time series to obtain the spectrum sequence corresponding to the location time series;

[0124] Fourier transform is used to map the location time series in the time domain to the frequency domain expression, and the spectrum sequence is used to present the amplitude distribution of different frequency components, which makes it easier to identify repetitive patterns in the trajectory.

[0125] Step S1023: Train the spectral sequence using a neural network model to obtain a historical trajectory profile.

[0126] The user's trajectory period is used to characterize the time intervals in which the user's historical trips are repeated, and the historical trajectory profile is used to summarize the characteristics of this period to reflect the user's regular movement patterns.

[0127] In its implementation, the system can obtain historical locations within a predetermined historical period from location services, electronic fence records, payment terminal location records, or locations reported by mobile terminals, and sort them according to the sampling timestamp to form a location time series.

[0128] Location can be represented by latitude and longitude coordinates, geographic raster encoding, or standardized location identifiers. Missing points can be interpolated to fill in gaps, and noisy points can be smoothed to improve sequence continuity.

[0129] Subsequently, discrete Fourier transforms were performed on the time series of this location to obtain the corresponding spectral sequences. The dominant frequency components with amplitudes exceeding a set threshold were then identified within these spectral sequences. The trajectory period was determined based on the reciprocal of the frequency corresponding to the dominant frequency component. When multiple significant peaks exist, the period can be comprehensively determined by combining peak weights, inter-peak intervals, and the number of stable occurrences, thereby forming a historical trajectory profile that reflects the user's recurring travel patterns.

[0130] This processing method utilizes frequency domain analysis to extract periodic features from location changes, enabling historical trajectory profiles to include not only information about the user's usual location but also periodic behavioral characteristics such as commuting, business travel, or cross-border trips. Therefore, in subsequent transaction risk control, the current location can be compared with historical periodic patterns, reducing misjudgments of frequently moving users and improving the accuracy of behavioral deviation detection.

[0131] By adopting this specific implementation, the system can identify stable trajectory cycles of users from discrete location records, avoiding risk assessment biases caused by relying solely on static location comparisons. At the same time, historical trajectory profiles have a strong ability to represent periodic activities, providing a more reliable basis for calculating user behavior values, thereby improving the continuity, robustness, and scenario adaptability of transaction risk assessment.

[0132] Based on the foregoing embodiments, further, step S105, obtaining the location deviation weight, user behavior weight, transaction amount weight, and transaction target weight, can be achieved through the following steps:

[0133] Step S1051: Obtain the basic weight of location deviation, basic weight of user behavior, basic weight of transaction amount, and basic weight of transaction target;

[0134] Among them, the location deviation base weight is used as the initial weight for the location deviation dimension, the user behavior base weight is used as the initial weight for the user behavior dimension, the transaction amount base weight is used as the initial weight for the transaction amount dimension, and the transaction target base weight is used as the initial weight for the transaction target dimension. The transaction target can be a merchant or other recipient. For example, the location deviation base weight (Loc_Dev) can be 0.4. When the transaction IP location does not match the mobile base station location code, the overseas transaction coefficient (+0.1) is triggered. If the transaction location matches the residential grid code (geohash6), the residential area coefficient (-0.2) is activated. The basic weight of user behavior (Beh_Alert) can be 0.1. When the device is changed (device fingerprint similarity <85%), the risk multiplier is activated and the weight value can be increased; the basic weight of transaction amount (Amt_Index) can be 0.3. In the UTC time interval of 22:00-06:00, the night transaction enhancement coefficient (+0.15) is enabled; the basic weight of transaction target (Mer_Risk) can be 0.2. The first appearance of the merchant ID triggers the new merchant coefficient (×1.5).

[0135] Step S1052: Determine the scene factor coefficient based on the current location information, and determine the behavior factor coefficient based on the current location information and historical trajectory profile. The scene factor coefficient represents the risk level of the location corresponding to the current location information, and the behavior factor coefficient represents the risk level of the user's behavior.

[0136] The scenario factor coefficient is used to characterize the risk level of the location corresponding to the current location information, and the behavior factor coefficient is used to characterize the risk level of user behavior. Together, they are used to dynamically adjust the basic weights so that the weights can be adjusted as the scenario changes and the historical trajectory changes.

[0137] Step S1053: Calculate the product of the position deviation base weight, the scene factor coefficient, and the behavior factor coefficient to obtain the position deviation weight;

[0138] Step S1054: Calculate the product of the user behavior base weight, the scenario factor coefficient, and the behavior factor coefficient to obtain the user behavior weight;

[0139] Step S1055: Calculate the product of the transaction amount base weight, the scenario factor coefficient, and the behavior factor coefficient to obtain the transaction amount weight;

[0140] Step S1056: Calculate the product of the basic weight of the transaction target, the scenario factor coefficient, and the behavior factor coefficient to obtain the weight of the transaction target.

[0141] In practical implementation, the system can first read the basic weights of location deviation, user behavior, transaction amount, and transaction target from the risk control model parameter library. The parameter library can be obtained offline by the bank based on historical transaction samples, rejection samples, and manual verification results, and can be configured according to account type, transaction channel, or region.

[0142] The scenario factor coefficient can be calculated based on the location type, geographical risk level, and whether it is located in an airport, port, transportation hub, or high-frequency abnormal trading area corresponding to the current location information. When the current location risk is high, the scenario factor coefficient takes a larger value to enhance the contribution of each risk dimension in the scenario.

[0143] The behavioral factor coefficient can be determined by combining current location information with historical trajectory profiles. When the current location deviates significantly from the user's usual activity range, periodic travel trajectory, or frequently used commuting trajectory, the behavioral factor coefficient will increase accordingly to reflect the degree of inconsistency between the current behavior and historical behavior patterns.

[0144] Subsequently, the system multiplies each basic weight by the scenario factor coefficient and the behavior factor coefficient, respectively, to obtain the location deviation weight, user behavior weight, transaction amount weight, and transaction target weight, which are then used as input parameters for calculating the subsequent transaction risk value. If the weight model needs to be extended in practical applications, different parameter storage formats or model versions can be used; this embodiment does not limit this.

[0145] The weighted calculation method allows the same risk dimension to simultaneously consider the impact of both the scenario environment and user behavior characteristics, thereby avoiding risk judgment bias caused by relying solely on static weights. By combining the basic contributions of location, behavior, amount, and transaction objective with dynamic coefficients, the system can improve its ability to identify cross-border commuting, cross-regional consumption, and high-mobility scenarios, and reduce the probability of misjudging normal transactions. Because each weight has scenario-adaptive characteristics, the system can form a weight allocation that more closely reflects actual risk when facing different locations, different users, and different transaction objects, thereby improving the overall risk control accuracy and transaction continuity.

[0146] Based on the foregoing embodiments, step S107, which determines the risk level according to the transaction risk value, can be achieved through the following steps:

[0147] Step S1071: Obtain the basic threshold, trajectory stability coefficient, and travel frequency coefficient. The trajectory stability coefficient represents the stability of the user's travel trajectory, and the travel frequency coefficient represents the frequency of the user's travel.

[0148] Among them, the basic threshold is used as a benchmark for risk level classification, and its value can be jointly set by the account's historical risk level, business scenario risk preference, and risk control strategy parameters.

[0149] The trajectory stability coefficient is used to characterize the continuity and repeatability of a user's travel trajectory. It is usually obtained by normalizing the location information sequence, trajectory periodicity, and trajectory offset amplitude within a predetermined historical period.

[0150] The travel frequency coefficient is used to characterize how frequently a user travels within a unit of time. It can be determined by combining historical travel frequency, cross-regional travel intervals, and the number of times a user switches between familiar locations.

[0151] The base threshold is represented by T_base, the trajectory stability coefficient can be expressed as (1 + α×Stab_Index), and the travel frequency coefficient can be expressed as exp(β×Cross_Freq), where α=0.6 (trajectory stability coefficient) and β=0.15 (cross-border frequency coefficient) are determined by gradient descent optimization; Stab_Index represents the stability quantification coefficient, Stab_Index = 1-0.5×σ / σ_max, where σ is the standard deviation of trajectory coordinates over the past 30 days, and σ_max is a constant related to city size (0.5 degrees for megacities); Cross_Freq represents the intensity of cross-border frequency.

[0152] Step S1072: Calculate the product of the basic threshold, the trajectory stability coefficient, and the trip frequency coefficient to obtain the risk threshold;

[0153] The risk threshold is formed by the product of three factors. Its function is to dynamically adjust the risk judgment benchmark according to changes in user movement patterns, so as to avoid excessive interception of high-frequency mobile users by a fixed threshold.

[0154] In its implementation, after obtaining the transaction risk value calculated in the preceding steps, the system first acquires the basic threshold associated with the current user, then extracts the trajectory stability coefficient based on the historical trajectory profile, and calculates the travel frequency coefficient by combining the travel records within the most recent scheduled period. Finally, the three are multiplied to obtain the risk threshold.

[0155] The risk threshold can be calculated using the following formula: , This indicates the risk threshold.

[0156] When a user crosses a member state border (base station location code changes), the threshold multiplier is automatically increased (×2.0), and a "cross-border movement marker" is added to the behavior trajectory chain. This mechanism has been verified by actual data, reducing the false lock rate from 12.3% to 2.1%.

[0157] Step S1073: Calculate the sum of the transaction risk value and the risk threshold to obtain the total transaction risk value;

[0158] Then, the risk threshold is added to the transaction risk value to form the total transaction risk value, and the total transaction risk value is compared with two pre-configured thresholds.

[0159] Step S1074: If the total risk value of the transaction is greater than the first preset threshold, determine the risk level as high risk level;

[0160] Step S1075: If the total risk value of the transaction is greater than the second preset threshold and less than or equal to the first preset threshold, the risk level is determined to be medium risk level, and the second preset threshold is less than the first preset threshold.

[0161] When the total transaction risk value exceeds the first preset threshold, it indicates that the overall transaction risk has reached a high level, and the system determines the risk level as high risk. When the total transaction risk value is between the second preset threshold and the first preset threshold, it indicates that the overall transaction risk is at a medium level, and the system determines the risk level as medium risk.

[0162] The first and second preset thresholds can be configured by the risk control model according to business type, channel type and account status, and the second preset threshold is less than the first preset threshold to form a tiered judgment range.

[0163] In practice, more refined risk levels can be defined, with each risk level employing a different verification strategy. For example, there are medium-risk levels (60-70 points), high-risk levels (70-80 points), and extremely high-risk levels (>80 points). Transactions with scores below 60 points will not be verified as risky.

[0164] By processing, the risk level is no longer determined solely by the risk value of a single transaction. Instead, the risk threshold is dynamically adjusted by combining the stability of the user's travel trajectory and the frequency of travel. This makes it easier for normal transactions in scenarios such as high-frequency business travel and cross-border commuting to fall into the medium-risk range, while abnormal transactions are more likely to be identified as high-risk. This improves the accuracy of risk classification and reduces the probability of false interception.

[0165] In one possible implementation, step S107, which controls transactions based on risk levels, can be achieved through the following steps:

[0166] Step S1076: If the risk level is high, freeze the user's trading account, obtain multiple verification information from the user, verify the verification information, and unfreeze the trading account if the verification is successful. The verification information is used to verify the user's identity.

[0167] The trading account is used to hold the user's trading funds and trading permissions. When a high-risk level is triggered, the account control module temporarily restricts the account's trading ability to prevent unconfirmed entities from initiating further transactions.

[0168] Multiple verification information refers to various verification materials used to represent the authenticity of a user's identity. These may include one or more of the following: dynamic password, SMS verification code, ID information, confirmation information corresponding to the reserved mobile phone number, and device binding information. The system compares and verifies these to confirm whether the transaction initiator and the account holder are consistent.

[0169] In practice, when the risk level is determined to be high based on the transaction risk value, the target transaction account is marked as restricted, and new payment authorizations, transfer authorizations, or consumption confirmation requests under that account are prevented from being executed, i.e., the account is frozen.

[0170] Subsequently, the user's identity is verified by acquiring multiple verification pieces of information and performing consistency and validity checks. These checks may include verifying whether the verification code is within its validity period, whether the identification information matches the account opening profile, whether the pre-registered contact information is reachable, and whether the device identifier is on a trusted list. When the verification results meet the preset pass conditions, the system generates an unfreezing command, restoring the trading account to a tradable state and allowing interrupted transaction requests to continue. In high-risk situations, using multiple verification pieces of information for joint verification can improve the strength of identity confirmation and reduce the probability of fraudulent account use for abnormal transactions.

[0171] Step S1077: If the risk level is medium risk, obtain the user's physiological verification information, verify the physiological verification information, and allow the transaction if the verification is successful.

[0172] Physiological verification information refers to verification data that reflects a user's physiological characteristics, including fingerprints, irises, facial features, palm prints, or voiceprints. The system completes verification based on pre-collected and stored physiological feature templates. Transaction approval means removing restrictions on the current transaction request, allowing it to continue forward to the payment clearing chain.

[0173] When the risk level is medium, the system does not directly freeze the account. Instead, it collects the user's physiological verification information and matches it against local or remote biometric templates. The collection of physiological verification information can be done via a mobile terminal camera, fingerprint sensor, microphone, or a dedicated biometric terminal. Once the system detects a match score that reaches a threshold, it determines that the verification is successful and allows the transaction to proceed with authorization and settlement. This method maintains high security while minimizing disruption to normal user interactions, making it suitable for cross-regional transactions, short-term high-frequency payments, or rapid confirmation in mobile scenarios.

[0174] In practical implementation, even more granular risk levels can be defined, with each risk level employing a different verification strategy, for example:

[0175] Medium risk level (60-70 points): Uses AES-128 encrypted SMS verification codes, dynamically generates keys (rotating every 60 seconds), and enables SSL Pinning at the transport layer (SSL certificate pinning is a security measure used to ensure that the certificate used when establishing a secure SSL / TLS connection with the server is indeed the expected server certificate) to prevent man-in-the-middle attacks.

[0176] High-risk level (70-80 points): Voiceprint biometrics is activated, requiring the user to read aloud the dynamic transaction amount. The text is generated in real time by TTS (Text-to-Speech) method, and is extracted by MFCC (Mel-scale Frequency Cepstral Coefficients) feature extraction and compared with the pre-registered voiceprint template (similarity threshold ≥92%). The communication link is encrypted end-to-end.

[0177] Extremely high risk level (>80 points): Triggers a fund freeze based on a smart contract, transaction feature data (including location evidence chain) is simultaneously uploaded to the blockchain for evidence storage, data fingerprints are generated using SHA-256 (cryptographic hash algorithm), and manual review requires verification of more than 3 related verification factors.

[0178] By establishing a correspondence between transaction control and risk levels, a control mechanism linking account freezing and multi-factor authentication is adopted in high-risk scenarios, while physiological feature verification is used to achieve lightweight confirmation in medium-risk scenarios. This balances account security, transaction continuity, and user experience, and enhances the risk control system's ability to distinguish between abnormal and normal transactions.

[0179] In one possible implementation, the method further includes the following steps:

[0180] Step S108: If the transaction is locked, obtain the user's real-time scene information and transportation voucher information;

[0181] Real-time scene information refers to the scene in which the user is currently located.

[0182] Real-time scene information can be obtained by landmark AR (Augmented Reality) scanning: calling the mobile phone's AR module to perform SLAM (Simultaneous Localization and Mapping) mapping, extracting SIFT (Scale-Invariant Feature Transform) feature points and matching them with the geographic information database (error < 1 meter), thereby obtaining the user's real-time scene information.

[0183] Transportation voucher information is information that represents the means of transportation a user is using.

[0184] The travel voucher information can be airline tickets, train tickets, etc. The ticket is recognized by OCR (Optical Character Recognition) and a CRNN (Convolutional Recurrent Neural Network) network (99.2% accuracy) is used to verify the ticket status in real time and obtain the travel voucher information.

[0185] Step S109: Determine the user's destination information based on real-time scene information and transportation voucher information, and compare the destination information with the current location information;

[0186] The user's destination information is determined from real-time scene information, and the destination information is extracted from transportation voucher information to verify whether the two are consistent.

[0187] At this point, the current location information can be obtained in a more detailed way through collaborative positioning: establish a Bluetooth Mesh network (communication radius 50 meters), and use RSSI (Received Signal Strength Indication) method to measure distance and locate, which requires 3 certified devices to cooperate and verify.

[0188] Then the destination information is compared with the current location information, for example, by comparing the latitude and longitude information of the two.

[0189] Step S110: If the destination information and the current location information represent the same location, unlock the transaction;

[0190] The fact that the destination information is the same indicates that the users' location information is consistent, the risk is low, the transaction was mistakenly locked, and therefore the account is unlocked.

[0191] Step S111: If the destination information and the current location information represent different locations, continue to lock the transaction.

[0192] Different destination information indicates inconsistent user location information, which may pose a risk; therefore, the transaction remains locked.

[0193] In practical applications, the accidental lock recovery mechanism can also include situations where users actively report their trips. Users can submit their trips in advance, and a zero-knowledge proof can be generated based on the user's trip. The user is deemed to have no risk during the trip, and the transaction is allowed. The zero-knowledge proof includes the destination and trip time of the trip.

[0194] Financial institutions use elliptic curve pairing verification to prove validity (verification time <50ms), without obtaining specific location coordinates throughout the process, reducing the risk of privacy leakage by 97% compared to traditional GPS coordinate transmission.

[0195] By implementing these steps, it is possible to re-verify whether a user is in a high-risk state when a transaction is locked, thereby correcting the risk assessment mechanism and reducing misjudgments in transactions.

[0196] In one possible implementation, the method further includes the following steps:

[0197] Step S112: After unlocking the transaction, the transaction is marked as a negative sample. The negative sample is then input into the neural network model of the historical trajectory profile for training to obtain a more accurate neural network model.

[0198] After unlocking a mistakenly locked transaction, it indicates that the system's risk assessment of that sample was inaccurate. Therefore, it is marked as a negative sample and used as input to train the neural network model of the historical trajectory profile in order to correct the historical trajectory profile and make the profile more consistent with the user's actual trajectory.

[0199] Step S113: After continuing to lock the transactions, mark the transactions as positive samples and increase the target weight of the transactions.

[0200] The fact that the transaction remains locked indicates that the transaction itself is indeed risky, possibly due to risks associated with the target party, i.e., the merchant. Therefore, the weight of the target party in the transaction is increased.

[0201] After user verification, the accidental locking event generates labeled samples:

[0202] Validation passed: Mark as negative samples and input into the LSTM trajectory model for retraining (sequence length = 30 steps).

[0203] Validation failed: Mark as a positive sample and increase the weight of merchant risk features (incremental learning rate η=0.01).

[0204] Monthly model update: An ensemble learning strategy is adopted, and the weight of the new model is equal to the weight of the old model × 0.7 + the weight of the incremental data × 0.3. The model meets certain convergence conditions.

[0205] Self-evolution capability verification: The false lock rate decreased by 8.3% in the first month (from 5.6% to 5.1%); the accuracy of merchant risk identification increased by 12.7% quarter-on-quarter (incremental data contributed 68%).

[0206] Specifically, this application also provides a self-healing evolutionary model for mis-locking, mainly including LSTM model retraining driven by negative samples and online parameter updates (β coefficient adjusted by an average of 0.04 per month), forming a continuously optimized decision-making agent. Specific examples are as follows:

[0207] 1. Location perception stage:

[0208] When a user's location enters the 3-kilometer electronic fence of the airport, the terminal's indoor map (including 127 Bluetooth beacons + 86 WiFi hotspots) is automatically loaded.

[0209] During flight, the user switches to ephemeris prediction mode and uses ADS-B (Automatic Dependent Surveillance-Broadcast) signals to calibrate the track (updating predicted coordinates every 5 minutes).

[0210] 2. An example of the dynamic unlocking decision-making process is as follows:

[0211] Calculate the difference between the current location coordinates (e.g., 35.765, 140.386) and the transaction coordinates (e.g., 35.772, 140.392) to obtain the location deviation, i.e., the location deviation value (e.g., 0.8km).

[0212] Assuming this is the user's 8th cross-border trip of the year, the travel frequency coefficient can be exp(β×Cross_Freq)== 3.32;

[0213] The trajectory stability coefficient can be calculated based on (1 + α × Stab_Index). Further calculation yields a final transaction risk value of 32 points. If the score is less than 60 points, an automatic transaction release instruction is triggered.

[0214] 3. Accidental lock recovery mechanism:

[0215] If a 70-point alarm is triggered at the duty-free shop, virtual reality landmark verification is invoked: scan the boarding pass with your mobile phone → extract the flight number using OCR → query the API to obtain the landing status; automatically add the coordinates to the trusted area library (radius expanded to 200 meters), and update the merchant feature weights, such as reducing the duty-free shop risk coefficient by 0.15.

[0216] By following these steps, the model and risk assessment process can be further refined, enabling the risk assessment process to dynamically adjust weights according to different scenarios and adapt to different situations or contexts, thus making the risk assessment results more accurate.

[0217] Figure 3 This application provides a specific flowchart illustrating a transaction security control method, as shown in the embodiments below. Figure 3 As shown, the system includes a geolocation awareness and trajectory modeling module, a dynamic security lock decision engine module, and a user interaction and exception handling module. The geolocation awareness and trajectory modeling module's process is as follows: it inputs multi-source positioning data such as GPS / base station / WiFi / Bluetooth beacon, uses a dynamic precision adjustment engine to handle traffic scene switching high-precision modes, and outputs a user trajectory profile, commonly used areas, trajectory stability coefficients, etc. The dynamic security lock decision engine module makes dynamic decisions based on the results of the geolocation awareness and trajectory modeling module. Its process includes: inputting real-time location + transaction data amount / merchant / frequency, combining multi-source positioning data and the user trajectory profile, performing adaptive threshold calculation and real-time risk assessment, and finally outputting tiered lock control commands, such as: release / verify / intercept, etc. The user interaction and exception handling module's process is as follows: the user inputs a reported itinerary and a request for verification of accidental locking, processes proactively reported unlocking, performs high-precision location verification and scans boarding passes, pushes user interaction flow app notifications, and finally sends an unlock command and notification message.

[0218] Figure 4 A decision-making flowchart for a dynamic security lock mechanism provided in this application embodiment is shown below. Figure 4 As shown, the process includes: starting; acquiring the real-time location of the user's mobile phone and the transaction location (such as the coordinates of the card swipe point), and also acquiring transaction characteristics: amount, merchant type, operation frequency, etc.; calculating the deviation between the transaction location and the real-time location; if the deviation is greater than a dynamic threshold, activating the real-time risk assessment model, i.e., the flow of the transaction security control method provided in this application embodiment, to obtain a risk score, and determining whether the score is greater than 80. If so, the transaction is intercepted + automatic locking. If the risk score is >80, a small amount is allowed + SMS verification. If the risk score is 60-80, the limit is ≤5000 yuan. If the deviation is less than the dynamic threshold, the transaction is allowed (risk value <60).

[0219] This application's implementation achieves three breakthrough benefits through a dynamic security lock strategy: On the user side, it reduces the cross-border false lock rate by over 90% (the average monthly false locks for business customers approach zero from 4.3 times), significantly reduces operational burden by 92% (the monthly manual verification frequency is only 0.25 times), and achieves 100% seamless passage in signal blind spots such as tunnels and airports; on the risk control side, it drives a 79.1% reduction in fraud false detection rate, reduces server verification requests by 83%, and meets global privacy compliance through zero-knowledge location verification; on the business side, real-world testing shows a 27% increase in high-frequency user retention rate, a 35% reduction in annual risk control and maintenance costs (saving $8.6 million annually for tens of millions of users), and a fraud loss rate reduced to 0.0031% (reaching 1 / 6 of the industry average). For example, for multinational executives, the system automatically learns their cross-border rhythm to achieve zero-intervention payment throughout the process, with the success rate jumping from 78% to 99.6%.

[0220] Figure 5 This is a schematic diagram of a transaction security control device provided in an embodiment of this application, as shown below. Figure 5 As shown, the transaction security control device 50 includes:

[0221] The first determining module 501 is used to obtain the user's current location information and determine the location deviation value based on the current location information. The location deviation value represents the degree of deviation between the current location information and the preset location.

[0222] The second determining module 502 is used to determine the user's historical trajectory profile and determine the user's behavior value based on the historical trajectory profile. The user behavior value represents the degree of deviation between the current location information and the historical trajectory profile.

[0223] The third determining module 503 is used to obtain the user's current transaction amount and determine the transaction amount value based on the current transaction amount. The transaction amount value indicates the degree of deviation between the transaction amount and the preset amount.

[0224] The fourth determination module 504 is used to obtain the transaction target party information and determine the target risk value based on the transaction target party information. The target risk value represents the number of transactions between the user and the transaction target party, and the transaction target party information represents the identity of the transaction target party.

[0225] Module 505 is used to obtain the location deviation weight, user behavior weight, transaction amount weight, and transaction target weight.

[0226] The calculation module 506 is used to calculate the sum of the products of the position deviation weight and the position deviation value, the user behavior weight and the user behavior value, the transaction amount weight and the transaction amount value, and the transaction target weight and the target risk value, to obtain the transaction risk value.

[0227] The fifth determination module 507 is used to determine the risk level based on the transaction risk value and to control the transaction based on the risk level.

[0228] In one possible embodiment, the first determining module 501 is further configured to identify the user's current scenario. If the current scenario is a public transportation scenario, the current location information is obtained through a first positioning method; if the current scenario is not a public transportation scenario, the current location information is obtained through a second positioning method, wherein the positioning accuracy of the first positioning method is higher than that of the second positioning method.

[0229] In one possible embodiment, the first determining module 501 is further configured to: obtain the user's location information in the global positioning system to obtain first location information; obtain the location information of the user's device in the wireless local area network to obtain second location information; obtain the user's location information in the Bluetooth positioning system to obtain third location information; and fuse the first location information, the second location information and the third location information to obtain current location information.

[0230] In one possible embodiment, the second determining module 502 is further configured to: obtain the user's historical location within a predetermined historical period to obtain a location time series; perform a Fourier transform on the location time series to obtain a spectrum sequence corresponding to the location time series; and train the spectrum sequence using a neural network model to obtain a historical trajectory profile.

[0231] In one possible embodiment, the acquisition module 505 is further configured to: acquire the location deviation base weight, user behavior base weight, transaction amount base weight, and transaction target base weight; determine the scenario factor coefficient based on the current location information, and determine the behavior factor coefficient based on the current location information and historical trajectory profile, wherein the scenario factor coefficient represents the risk level of the location corresponding to the current location information, and the behavior factor coefficient represents the risk level of the user's behavior; calculate the product of the location deviation base weight, the scenario factor coefficient, and the behavior factor coefficient to obtain the location deviation weight; calculate the product of the user behavior base weight, the scenario factor coefficient, and the behavior factor coefficient to obtain the user behavior weight; calculate the product of the transaction amount base weight, the scenario factor coefficient, and the behavior factor coefficient to obtain the transaction amount weight; and calculate the product of the transaction target base weight, the scenario factor coefficient, and the behavior factor coefficient to obtain the transaction target weight.

[0232] In one possible embodiment, the fifth determining module 507 is further configured to: obtain a basic threshold, a trajectory stability coefficient, and a travel frequency coefficient, wherein the trajectory stability coefficient represents the stability of the user's travel trajectory, and the travel frequency coefficient represents the frequency of the user's travel; calculate the product of the basic threshold, the trajectory stability coefficient, and the travel frequency coefficient to obtain a risk threshold; calculate the sum of the transaction risk value and the risk threshold to obtain a total transaction risk value; determine the risk level as high risk level if the total transaction risk value is greater than a first preset threshold; and determine the risk level as medium risk level if the total transaction risk value is greater than a second preset threshold and less than or equal to the first preset threshold, wherein the second preset threshold is less than the first preset threshold.

[0233] In one possible embodiment, the fifth determining module 507 is further configured to: freeze the user's transaction account when the risk level is high, obtain multiple verification information of the user, verify the verification information, and unfreeze the transaction account if the verification is successful, wherein the verification information is used to verify the user's identity; and obtain the user's physiological verification information when the risk level is medium, verify the physiological verification information, and allow the transaction if the verification is successful.

[0234] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily essential to this application.

[0235] It should be further noted that although the steps in the flowchart are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowchart may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0236] It should be understood that the above-described device embodiments are merely illustrative, and the device of this application can also be implemented in other ways. For example, the division of units / modules in the above embodiments is only a logical functional division, and there may be other division methods in actual implementation. For example, multiple units, modules, or components may be combined, or integrated into another system, or some features may be ignored or not executed.

[0237] Furthermore, unless otherwise specified, the functional units / modules in the various embodiments of this application can be integrated into one unit / module, or each unit / module can exist physically separately, or two or more units / modules can be integrated together. The integrated units / modules described above can be implemented in hardware or as software program modules.

[0238] When integrated units / modules are implemented in hardware, the hardware can be digital circuits, analog circuits, etc. The physical implementation of the hardware structure includes, but is not limited to, transistors, memristors, etc. Unless otherwise specified, the processor can be any suitable hardware processor, such as a CPU, GPU, FPGA, DSP, and ASIC, etc. Unless otherwise specified, the storage unit can be any suitable magnetic or magneto-optical storage medium, such as Resistive Random Access Memory (RRAM), Dynamic Random Access Memory (DRAM), Static Random Access Memory (SRAM), Enhanced Dynamic Random Access Memory (EDRAM), High-Bandwidth Memory (HBM), Hybrid Memory Cube (HMC), etc.

[0239] If the integrated unit / module is implemented as a software program module and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned memory includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0240] In the above embodiments, the descriptions of each embodiment have their own emphasis. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments. The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as the combination of these technical features does not contradict each other, it should be considered within the scope of this specification.

[0241] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0242] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A transaction security control method, characterized in that, include: Obtain the user's current location information, determine the location deviation value based on the current location information, and the location deviation value represents the degree of deviation between the current location information and the preset location; Determine the user's historical trajectory profile, and determine the user's behavior value based on the historical trajectory profile. The user behavior value represents the degree of deviation between the current location information and the historical trajectory profile. Obtain the user's current transaction amount, and determine the transaction amount value based on the current transaction amount. The transaction amount value represents the degree of deviation between the transaction amount and the preset amount. Obtain transaction target information, determine target risk value based on transaction target information, the target risk value represents the number of transactions between the user and the transaction target, and the transaction target information represents the identity of the transaction target; Obtain the weights for location deviation, user behavior, transaction amount, and transaction target. The transaction risk value is obtained by summing the products of the position deviation weight and the position deviation value, the user behavior weight and the user behavior value, the transaction amount weight and the transaction amount value, and the transaction target weight and the target risk value. The risk level is determined based on the transaction risk value, and transaction control is carried out based on the risk level.

2. The method according to claim 1, characterized in that, Obtain the user's current location information, including: Identify the user's current scenario; if the current scenario is a public transportation scenario, obtain the current location information through precise positioning. If the current scenario is not the public transportation scenario, the current location information is obtained through a normal positioning method, and the positioning accuracy of the precise positioning method is higher than that of the normal positioning method.

3. The method according to claim 2, characterized in that, The current location information is obtained through precise positioning, including: Obtain the user's location information from the global positioning system to obtain first location information; Obtain the location information of the user's device in the wireless local area network to obtain the second location information; Obtain the user's location information from the Bluetooth positioning system to obtain third location information; The first location information, the second location information, and the third location information are fused together to obtain the current location information.

4. The method according to claim 1, characterized in that, Determining the user's historical trajectory profile includes: Obtain the historical location of the user within a predetermined historical period to obtain a location time series; Perform a Fourier transform on the location time series to obtain the corresponding spectrum sequence; The historical trajectory profile is obtained by training the spectrum sequence using a neural network model. The neural network model is trained using multiple sets of data, each of which includes a historical spectrum sequence and a historical trajectory profile.

5. The method according to claim 1, characterized in that, Obtain the weights for location deviation, user behavior, transaction amount, and transaction target, including: Obtain the base weights for location deviation, user behavior, transaction amount, and transaction target. The scene factor coefficient is determined based on the current location information, and the behavior factor coefficient is determined based on the current location information and the historical trajectory profile. The scene factor coefficient represents the risk level of the location corresponding to the current location information, and the behavior factor coefficient represents the risk level of the user's behavior. The position deviation weight is obtained by multiplying the position deviation base weight, the scene factor coefficient, and the behavior factor coefficient. The user behavior weight is obtained by multiplying the user behavior base weight, the scenario factor coefficient, and the behavior factor coefficient. The transaction amount weight is obtained by multiplying the basic weight of the transaction amount, the scenario factor coefficient, and the behavior factor coefficient. The transaction target weight is obtained by multiplying the basic weight of the transaction target, the scenario factor coefficient, and the behavior factor coefficient.

6. The method according to claim 1, characterized in that, The risk level is determined based on the aforementioned transaction risk value, including: Obtain a basic threshold, a trajectory stability coefficient, and a travel frequency coefficient, wherein the trajectory stability coefficient represents the stability of the user's travel trajectory, and the travel frequency coefficient represents the frequency of the user's travel. The risk threshold is obtained by multiplying the basic threshold, the trajectory stability coefficient, and the travel frequency coefficient. The total transaction risk value is obtained by summing the transaction risk value and the risk threshold. If the total risk value of the transaction is greater than a first preset threshold, the risk level is determined to be a high-risk level. If the total risk value of the transaction is greater than the second preset threshold and less than or equal to the first preset threshold, the risk level is determined to be a medium risk level, where the second preset threshold is less than the first preset threshold.

7. The method according to claim 6, characterized in that, Transaction control based on the aforementioned risk level includes: If the risk level is high, the user's transaction account is frozen, multiple verification information of the user is obtained, and the verification information is verified. If the verification is successful, the transaction account is unfrozen. The verification information is used to verify the user's identity. If the risk level is medium risk, obtain the user's physiological verification information, verify the physiological verification information, and allow the transaction if the verification is successful.

8. The method according to claim 1, characterized in that, After implementing transaction control based on the risk level, the method further includes: If the transaction is locked, obtain the user's real-time scene information and transportation voucher information; The user's destination information is determined based on the real-time scene information and the transportation voucher information, and the destination information is compared with the current location information; If the destination information is the same as the location represented by the current location information, the transaction is unlocked; If the destination information differs from the location represented by the current location information, the transaction remains locked.

9. The method according to claim 8, characterized in that, The method further includes: After the transaction is unlocked, the transaction is marked as a negative sample, and the negative sample is input into the neural network model of the historical trajectory profile for training, so as to obtain a more accurate neural network model. After the transaction is locked, it is marked as a positive sample, and the target weight of the transaction is increased.

10. A transaction security control device, characterized in that, include: The first determining module is used to obtain the user's current location information and determine a location deviation value based on the current location information, wherein the location deviation value represents the degree of deviation between the current location information and a preset location; The second determining module is used to determine the user's historical trajectory profile and determine the user's behavior value based on the historical trajectory profile. The user behavior value represents the degree of deviation between the current location information and the historical trajectory profile. The third determining module is used to obtain the user's current transaction amount and determine the transaction amount value based on the current transaction amount. The transaction amount value represents the degree of deviation between the transaction amount and the preset amount. The fourth determination module is used to obtain transaction target information and determine a target risk value based on the transaction target information. The target risk value represents the number of transactions between the user and the transaction target, and the transaction target information represents the identity of the transaction target. The acquisition module is used to acquire location deviation weight, user behavior weight, transaction amount weight, and transaction target weight. The calculation module is used to calculate the sum of the products of the position deviation weight and the position deviation value, the user behavior weight and the user behavior value, the transaction amount weight and the transaction amount value, and the transaction target weight and the target risk value, to obtain the transaction risk value; The fifth determination module is used to determine the risk level based on the transaction risk value and to perform transaction control based on the risk level.

11. An electronic device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of claims 1 to 9.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1 to 9.

Images