Transaction risk assessment method and apparatus, electronic device, and storage medium

Abstract

The application discloses a kind of transaction risk assessment method and its device, electronic equipment and storage medium, it is related to artificial intelligence technical field or other related technical fields, wherein, the method comprises: collecting the transaction behavior data and terminal behavior data of user terminal;Respectively on transaction behavior data and terminal behavior data are carried out feature extraction, obtain transaction behavior feature and terminal behavior feature;Model prompt word is constructed based on transaction behavior feature and terminal behavior feature, and model prompt word is input to the risk identification model locally deployed, and output transaction risk score and risk cause explanation text;Based on transaction risk score grading decision, identify abnormal transaction, and based on abnormal transaction and corresponding risk cause explanation text, risk event is reported to cloud end.The application solves the technical problem of low identification efficiency in the related art, which relies on end-side data collection reporting and cloud centralized risk control decision-making technical architecture for transaction risk identification.

Description

Technical Field

[0001] This invention relates to the field of artificial intelligence technology or other related technical fields. Specifically, it relates to a method, apparatus, electronic device, and storage medium for assessing transaction risk. Background Technology

[0002] With the rapid development of mobile internet and fintech, mobile payment has become a core channel for the public to conduct fund transfers, wealth management and investment, and daily payments. The fragmentation and high frequency of transaction scenarios, along with the openness of the operating environment, have made risky transactions such as account theft and fraudulent transactions increasingly covert and frequent. Against this backdrop, real-time and accurate risk assessment of mobile transactions is not only a necessary technical means to protect user funds and prevent illegal fund flows, but also a key link for financial institutions to fulfill their compliance obligations and maintain the stability of the financial system. An efficient risk control assessment mechanism can complete intent analysis the moment a transaction is initiated, minimizing interference with normal user operations while strengthening the security defenses of mobile finance.

[0003] In related technologies, the identification of financial transaction risks on mobile terminals relies on a technical architecture that combines edge data collection and reporting with centralized risk control decision-making in the cloud. Specifically, the mobile terminal uses an integrated application software development kit to capture basic information such as device identification, network environment parameters, and transaction messages in real time, which is then transmitted to the risk control server in the financial institution's data center via an encrypted channel. The cloud server, relying on a pre-set rule engine or machine learning model, performs batch feature matching and probability calculation on the massive amounts of user data collected, and finally issues decision instructions for approval, interception, or enhanced verification to the client for execution.

[0004] However, the aforementioned existing technical solutions have gradually revealed several technical bottlenecks in actual deployment. First, data transmission consumes a large amount of bandwidth and poses significant privacy compliance risks. Second, assessment efficiency is significantly constrained by the network environment. This architecture relies heavily on a stable bidirectional communication link. In weak network, no network, or high-latency scenarios, the round-trip latency between data upload and command issuance increases significantly, leading to delayed risk control decisions or timeout failures, and failing to effectively address the real-time interception needs in complex mobile scenarios.

[0005] There is currently no effective solution to the above problems. Summary of the Invention

[0006] This invention provides a method, apparatus, electronic device, and storage medium for assessing transaction risks, in order to at least solve the technical problem of low efficiency in identifying transaction risks in related technologies that rely on a technical architecture of on-device data collection and reporting and cloud-based centralized risk control decision-making.

[0007] According to one aspect of the present invention, a method for assessing transaction risk is provided, comprising: collecting transaction behavior data and terminal behavior data of a user terminal; extracting features from the transaction behavior data and the terminal behavior data respectively to obtain transaction behavior features and terminal behavior features; constructing model prompt words based on the transaction behavior features and the terminal behavior features, and inputting the model prompt words into a risk identification model to output a transaction risk score and a risk cause explanation text, wherein the risk identification model is a pre-trained large language model deployed locally on the user terminal; performing hierarchical decision-making based on the transaction risk score to identify abnormal transactions, and reporting risk events to the cloud based on the abnormal transactions and the corresponding risk cause explanation text.

[0008] Furthermore, the steps for collecting terminal behavior data of the user terminal include: collecting the posture data of the user terminal in three-dimensional space through the posture acquisition sensor built into the user terminal; identifying touch events on the user terminal through the underlying touch interface of the operating system, and recording touch data based on the touch events.

[0009] Further, the steps of extracting features from the transaction behavior data and the terminal behavior data to obtain transaction behavior features and terminal behavior features include: extracting a preset risk field based on the transaction behavior data to obtain the transaction behavior features; extracting a transaction time interval based on the transaction behavior features, and extracting target terminal behavior data within the transaction time interval from the terminal behavior data; extracting a preset terminal behavior risk field from the target terminal behavior data; calculating terminal risk behavior parameters based on the terminal behavior risk field to obtain terminal behavior features, wherein the risk behavior parameters include at least one of the following: average acceleration, maximum angular velocity change rate, touch pressure standard deviation, median click interval, and trajectory curvature features.

[0010] Further, the step of making a graded decision based on the transaction risk score includes: comparing the transaction risk score with a preset risk score threshold to obtain a comparison result, wherein the risk score threshold includes a first score threshold and a second score threshold, and the first score threshold is less than the second score threshold; allowing the transaction if the comparison result indicates that the transaction risk score is less than the first score threshold; triggering local dynamic verification on the user terminal if the comparison result indicates that the transaction risk score is greater than or equal to the first score threshold and less than or equal to the second score threshold; and blocking the transaction if the comparison result indicates that the transaction risk score is greater than the second score threshold.

[0011] Furthermore, the steps of identifying abnormal transactions and reporting risk events to the cloud based on the abnormal transactions and the corresponding risk cause explanation text include: in the case of transaction blocking, identifying the blocked transaction as the abnormal transaction; obtaining the transaction identifier, the transaction risk score, the timestamp, and the anomaly type label based on the abnormal transaction; generating risk event data based on the transaction identifier, the transaction risk score, the timestamp, the anomaly type label, and the risk cause explanation text and uploading it to the cloud.

[0012] Furthermore, the risk identification model includes a base model and a low-rank adapter. After reporting the risk event to the cloud based on the abnormal transaction and the corresponding risk cause explanation text, it also includes: real-time monitoring of the user terminal's operating status; when the user terminal's operating status is idle, extracting historical transaction data from the user terminal's local database, wherein the historical transaction data includes historical transaction behavior data and historical terminal behavior data; constructing training samples based on the historical transaction data, and performing gradient updates on the model parameters of the low-rank adapter based on the training samples.

[0013] Further, the step of inputting the model prompts into the risk identification model and outputting a transaction risk score and a risk cause explanation text includes: inputting the model prompts into the risk identification model local to the user terminal, performing semantic encoding through the base model of the risk identification model to obtain input features, and inputting them into each attention layer of the base model; adjusting the representation weights of the input features in each attention layer of the base model through the low-rank adapter to obtain adjusted feature representations; passing the adjusted feature representations to the decoder of the base model, whereby the decoder learns the semantic context based on the adjusted feature representations, generates the transaction risk score and the risk cause explanation text, and outputs them through the output layer.

[0014] According to another aspect of the present invention, a transaction risk assessment device is also provided, comprising: a collection unit for collecting transaction behavior data and terminal behavior data of a user terminal; an extraction unit for extracting features from the transaction behavior data and the terminal behavior data respectively to obtain transaction behavior features and terminal behavior features; a construction unit for constructing model prompt words based on the transaction behavior features and the terminal behavior features, inputting the model prompt words into a risk identification model, and outputting a transaction risk score and risk cause explanation text, wherein the risk identification model is a pre-trained large language model deployed locally on the user terminal; and an identification unit for making a graded decision based on the transaction risk score, identifying abnormal transactions, and reporting risk events to the cloud based on the abnormal transactions and the corresponding risk cause explanation text.

[0015] Furthermore, the acquisition unit includes: a first acquisition module, used to acquire the attitude data of the user terminal in three-dimensional space through the attitude acquisition sensor built into the user terminal; and a first recording module, used to identify touch events on the user terminal through the operating system's underlying touch interface, and record touch data based on the touch events.

[0016] Further, the extraction unit includes: a first extraction module, used to extract a preset risk field based on the transaction behavior data to obtain the transaction behavior features; a second extraction module, used to extract a transaction time interval based on the transaction behavior features, and extract target terminal behavior data within the transaction time interval from the terminal behavior data; a third extraction module, used to extract a preset terminal behavior risk field from the target terminal behavior data; and a first calculation module, used to calculate terminal risk behavior parameters based on the terminal behavior risk field to obtain terminal behavior features, wherein the risk behavior parameters include at least one of the following: average acceleration, maximum angular velocity change rate, touch pressure standard deviation, median click interval, and trajectory curvature features.

[0017] Further, the identification unit includes: a first comparison module, configured to compare the transaction risk score with a preset risk score threshold to obtain a comparison result, wherein the risk score threshold includes a first score threshold and a second score threshold, and the first score threshold is less than the second score threshold; a first release module, configured to release the transaction when the comparison result indicates that the transaction risk score is less than the first score threshold; a first trigger module, configured to trigger the local dynamic verification of the user terminal when the comparison result indicates that the transaction risk score is greater than or equal to the first score threshold and less than or equal to the second score threshold; and a first blocking module, configured to block the transaction when the comparison result indicates that the transaction risk score is greater than the second score threshold.

[0018] Furthermore, the identification unit further includes: a first identification module, used to identify the blocked transaction as the abnormal transaction in the event of transaction blocking; a first acquisition module, used to acquire a transaction identifier, a transaction risk score, a timestamp, and an anomaly type label based on the abnormal transaction; and a first generation module, used to generate risk event data based on the transaction identifier, the transaction risk score, the timestamp, the anomaly type label, and the risk cause explanation text, and upload it to the cloud.

[0019] Furthermore, the risk identification model includes a base model and a low-rank adapter, and the transaction risk assessment device further includes: a first monitoring module for real-time monitoring of the operating status of the user terminal; a first extraction module for extracting historical transaction data from the local database of the user terminal when the operating status of the user terminal is idle, wherein the historical transaction data includes historical transaction behavior data and historical terminal behavior data; and a first update module for constructing training samples based on the historical transaction data and performing gradient updates on the model parameters of the low-rank adapter based on the training samples.

[0020] Further, the construction unit includes: a first encoding module, used to input the model prompt words into the risk identification model local to the user terminal, perform semantic encoding through the base model of the risk identification model to obtain input features, and input them into each attention layer of the base model; a first adjustment module, used to adjust the representation weights of the input features in each attention layer of the base model through the low-rank adapter to obtain the adjusted feature representation; and a first generation module, used to pass the adjusted feature representation to the decoder of the base model, whereby the decoder learns the semantic context based on the adjusted feature representation, generates the transaction risk score and the risk cause explanation text, and outputs them through the output layer.

[0021] According to another aspect of the present invention, a computer-readable storage medium is also provided, the computer-readable storage medium including a stored computer program, wherein, when the computer program is executed, it controls the device where the computer-readable storage medium is located to perform any of the above-described methods for assessing transaction risks.

[0022] According to another aspect of the present invention, an electronic device is also provided, including one or more processors and a memory, the memory being used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement any of the above-described methods for assessing transaction risk.

[0023] According to another aspect of the present invention, a computer program product is also provided, the computer program product comprising a computer program, wherein the computer program, when executed by a processor, implements any of the above-described methods for assessing transaction risks.

[0024] In this application, the following steps are performed: collecting transaction behavior data and terminal behavior data from user terminals; extracting features from the transaction behavior data and terminal behavior data to obtain transaction behavior features and terminal behavior features; constructing model prompt words based on the transaction behavior features and terminal behavior features; inputting the model prompt words into a risk identification model; and outputting a transaction risk score and risk cause explanation text. The risk identification model is a pre-trained large language model deployed locally on the user terminal. It makes hierarchical decisions based on the transaction risk score, identifies abnormal transactions, and reports risk events to the cloud based on abnormal transactions and corresponding risk cause explanation text.

[0025] In this application, feature extraction is performed on the collected transaction behavior data and terminal behavior data, which are then converted into model prompts in natural language form. This allows unstructured sensor data and structured transaction data to be uniformly adapted to the input semantic space of the machine model. The model prompts are then input into a risk identification model deployed locally on the user terminal, eliminating real-time dependence on cloud servers. The model performs forward inference locally, simultaneously outputting a quantitative transaction risk score and a qualitative explanation of the risk causes. This improves the efficiency of risk transaction identification and ensures the accuracy and real-time performance of risk transaction identification in complex environments. Furthermore, this solves the technical problem of low identification efficiency in related technologies that rely on a technical architecture of terminal data collection and reporting and centralized risk control decision-making in the cloud. Attached Figure Description

[0026] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this application, illustrate exemplary embodiments of the invention and, together with their description, serve to explain the invention and do not constitute an undue limitation thereof. In the drawings:

[0027] Figure 1 A hardware structure block diagram of a computer terminal (or mobile device) for implementing a method for assessing transaction risk is shown.

[0028] Figure 2 This is a flowchart of an optional transaction risk assessment method according to an embodiment of the present invention;

[0029] Figure 3 This is an optional system architecture diagram for assessing transaction risk according to an embodiment of the present invention;

[0030] Figure 4 This is a schematic diagram of an optional transaction risk assessment process according to an embodiment of the present invention;

[0031] Figure 5 This is a schematic diagram of an optional transaction risk assessment device according to an embodiment of the present invention;

[0032] Figure 6This is a hardware structure block diagram of an electronic device (or mobile device) for an optional method of assessing transaction risk according to an embodiment of the present invention. Detailed Implementation

[0033] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0034] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0035] It should be noted that the transaction risk assessment method and apparatus in this application can be used in the field of artificial intelligence technology for transaction risk identification based on a large edge model, or in any field other than artificial intelligence technology for transaction risk identification based on a large edge model. This application does not limit the application field of the transaction risk assessment method and apparatus.

[0036] It should be noted that the information collected in this application (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for display, data used for analysis, etc.) are 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 this data all comply with relevant laws, regulations, and standards, necessary confidentiality measures have been taken, and they do not violate public order and good morals. Corresponding access points are provided for users to choose to authorize or refuse. For example, interfaces are set up between this system and relevant users or organizations, providing users with corresponding access points to choose to agree to or refuse automated decision-making results; if the user chooses to refuse, the process proceeds to the expert decision-making stage.

[0037] The following embodiments of the present invention can be applied to various transaction risk assessment systems / applications / devices. The present invention directly encapsulates and deploys a pre-trained risk identification model locally on the user terminal, running it as an independent inference engine. This eliminates real-time dependence on cloud servers, reduces the reliance of risk transaction identification on network and other environmental conditions, improves identification efficiency, and ensures accurate identification and real-time interception under heavy load. Simultaneously, the extracted features are converted into model prompt words, enabling unstructured sensor data and structured transaction data to be uniformly adapted to the input semantic space of a large language model, improving the accuracy of the output results.

[0038] The present invention will now be described in detail with reference to various embodiments.

[0039] Example 1

[0040] According to an embodiment of the present invention, an embodiment of a method for assessing transaction risk is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0041] The method embodiment provided in Embodiment 1 of this application can be executed on a mobile terminal, computer terminal, or similar computing device. Figure 1 A hardware block diagram of a computer terminal (or mobile device) for implementing a method for assessing trading risk is shown. Figure 1 As shown, the computer terminal 10 (or mobile device) may include one or more processors 102 (shown as 102a, 102b, ..., 102n in the figure) 102 (processor 102 may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.), a memory 104 for storing data, and a transmission device 106 for communication functions. In addition, it may also include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of a BUS bus), a network interface, a power supply, and / or a camera. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, computer terminal 10 may also include... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0042] It should be noted that the aforementioned one or more processors 102 and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuits may be a single, independent processing module, or may be integrated, in whole or in part, into any other element within the computer terminal 10 (or mobile device). As involved in the embodiments of this application, the data processing circuits serve as a processor control mechanism (e.g., selection of a variable resistor termination path connected to an interface).

[0043] The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the transaction risk assessment method in this embodiment. The processor 102 executes various functional applications and data processing by running the software programs and modules stored in the memory 104, thereby realizing the aforementioned transaction risk assessment method. The memory 104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the computer terminal 10 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0044] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of the computer terminal 10. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module, used for wireless communication with the Internet.

[0045] The display may be, for example, a touchscreen liquid crystal display (LCD) that allows the user to interact with the user interface of the computer terminal 10 (or mobile device).

[0046] Under the aforementioned operating environment, this application provides the following: Figure 2 The method for assessing transaction risk shown is implemented by a transaction risk assessment system.

[0047] Figure 2 This is a flowchart of an optional transaction risk assessment method according to an embodiment of the present invention, such as... Figure 2 As shown, the method includes the following steps:

[0048] Step S201: Collect transaction behavior data and terminal behavior data from user terminals.

[0049] In step S201 above, transaction behavior data and terminal behavior data from the user terminal are first collected as the basis for transaction risk assessment. The user terminal refers to a mobile computing device equipped with a financial application, possessing an independent processor, memory, sensor array, and local data storage unit. Transaction behavior data refers to the set of explicit business parameters generated by the user during financial transactions, which may include structured business elements such as transaction amount, payee account identifier, transaction timestamp, transaction type, and the origin of funds. Terminal behavior data refers to the set of implicit interaction and physical sensing signals generated by the user during mobile device operation, which may include unstructured temporal features such as device posture sequences, touch interaction characteristics, and input behavior sequences. Data collection is achieved through a secure data monitoring module pre-installed on the user terminal. Utilizing the system's underlying interface, multi-dimensional data is synchronously captured at a preset sampling period and immediately written to the local encrypted storage area, ensuring data isolation and anti-tampering processing before transmission.

[0050] Through the above steps, a multi-dimensional, high-fidelity raw data foundation is constructed. Transaction behavior data is used to anchor the fund transfer intent and business scenario attributes of the current operation, while terminal behavior data is used to characterize the user's real physical operation habits and biological behavioral characteristics. Collecting both synchronously within the same time window aims to break the data fragmentation of traditional risk control, which relies solely on business messages or single device fingerprints, providing a complete and real-time input source for subsequent feature extraction and model suggestion word construction.

[0051] In one optional embodiment, the step of collecting terminal behavior data of a user terminal includes: collecting the user terminal's posture data in three-dimensional space through a posture acquisition sensor built into the user terminal; identifying touch events on the user terminal through the operating system's underlying touch interface, and recording touch data based on the touch events.

[0052] Specifically, terminal behavior data includes at least: user terminal posture data and touch data. When collecting terminal behavior data, the user terminal's three-dimensional posture data is first acquired through its built-in sensors. These sensors are inertial measurement modules integrated into the mobile device's motherboard, specifically accelerometers and gyroscopes. The three-dimensional posture data represents the real-time spatial state parameters generated by the terminal device in the X, Y, and Z coordinate systems, encompassing the device's tilt angle, rotational angular velocity, instantaneous displacement trajectory, and whether it is stationary or in motion. Because different users exhibit highly personalized and stable grip postures, operating tilt angles, and placement environments, real-time capture of three-dimensional posture data can establish a dynamic baseline for the device's physical state. When unexpected changes occur in the device's posture, this provides crucial physical-layer evidence for subsequent assessments of potential risks such as the device slipping out of the user's control.

[0053] Simultaneously, touch events on the terminal device are collected through the operating system's underlying touch interface. This interface, a system-level input event listening channel provided by the mobile operating system kernel, directly reads the raw input signals reported by the screen driver layer, bypassing data filtering and format conversion by the application layer framework. Touch events refer to all interactive actions triggered by the user on the touchscreen, encompassing discrete event sequences such as pressing, moving, lifting, long pressing, and swiping. Touch data includes temporal and spatial characteristic parameters derived from these interactive action triggers, specifically including time interval sequences between adjacent touch events, screen contact pressure distribution, coordinate point sets of finger swipe trajectories, and their curvature changes. By collecting touch data, the user's micro-interaction behavior patterns can be quantified, helping to identify hidden operations such as automated script simulation, abnormal proxy operations, or non-dominant hand switching.

[0054] Step S202: Extract features from the transaction behavior data and the terminal behavior data respectively to obtain transaction behavior features and terminal behavior features.

[0055] In step S202 above, using preset mathematical transformation algorithms, statistical rules, or lightweight machine learning modules, environmental noise and redundant information are removed from transaction behavior data and terminal behavior data. Key indicators with strong discriminative significance and low redundancy are extracted to obtain transaction behavior features and terminal behavior features, respectively. Transaction behavior features are characteristics that represent the intention of fund flow, business scenario attributes, and macro risk signals, and can be numerical indicators or categorical labels, etc. Terminal behavior features are temporal or spatial quantitative results that characterize users' physical grip habits, interaction rhythm, and biological operation patterns, and can be statistical distribution parameters or pattern identification vectors, etc.

[0056] Through the above step S202, the discrete original business messages are reduced and compressed into structured indicators with clear risk control dimensions. Irrelevant fields are eliminated to highlight core business risk signals such as abnormal amounts, sudden changes in frequency, and transactions during unusual periods, providing clear business context anchors for the subsequent construction of prompt words.

[0057] In one optional embodiment, the steps of extracting features from transaction behavior data and terminal behavior data to obtain transaction behavior features and terminal behavior features respectively include: extracting a preset risk field based on the transaction behavior data to obtain transaction behavior features; extracting a transaction time interval based on the transaction behavior features, and extracting target terminal behavior data within the transaction time interval from the terminal behavior data; extracting a preset terminal behavior risk field from the target terminal behavior data; calculating terminal risk behavior parameters based on the terminal behavior risk field to obtain terminal behavior features, wherein the risk behavior parameters include at least one of the following: average acceleration, maximum angular velocity change rate, touch pressure standard deviation, median click interval, and trajectory curvature features.

[0058] Furthermore, the feature extraction steps include: First, extracting preset risk fields based on transaction behavior data to quickly filter redundant business messages, focus on highly sensitive fund flow signals, and generate clearly structured, low-dimensional transaction behavior features, providing clear business anchors for subsequent spatiotemporal alignment. Second, extracting transaction time intervals based on transaction behavior features and capturing target terminal behavior data to establish a cross-modal data time synchronization mechanism. Because biological behavior features are highly time-sensitive, they can only truly reflect the physical state of the operating entity at the moment of the transaction when terminal operation data and transaction instructions are within the same time window. This effectively avoids behavioral context pollution caused by data misalignment or transmission delays, ensuring that the features relied upon for subsequent inference have strict causal relationships. Third, extracting preset terminal behavior risk fields from the target terminal behavior data for further noise reduction and focusing, eliminating idle sampling, background refreshes, or irrelevant interface switching records during non-operational phases within the transaction time interval, retaining pure interaction fragments. Finally, calculating terminal risk behavior parameters based on the terminal behavior risk fields, transforming discrete, high-frequency raw sensor waveforms into statistically significant stable parameters. By calculating at least one or more of the following features: average acceleration, maximum angular velocity change rate, standard deviation of touch pressure, median click interval, and trajectory curvature, users' physical grip habits, distribution of operating force, input rhythm patterns, and gesture fluency can be quantitatively expressed, thereby forming a terminal behavior feature vector that can be directly parsed by a large language model.

[0059] By using the transaction time interval as a spatiotemporal alignment link through the above steps, the time mismatch problem caused by the difference in collection frequency or asynchronous reporting between transaction messages and sensor data is solved, which significantly improves the contextual consistency and causal correspondence of multimodal feature fusion. At the same time, by clearly defining the calculation logic of terminal risk behavior parameters such as average acceleration, maximum angular velocity change rate, touch pressure standard deviation, median click interval, and trajectory curvature features, the abstract biological interaction behavior is transformed into objective and quantifiable risk control indicators, which greatly reduces the computational complexity and noise interference of edge feature engineering.

[0060] Step S203: Construct model prompt words based on transaction behavior characteristics and terminal behavior characteristics, input the model prompt words into the risk identification model, and output transaction risk score and risk cause explanation text.

[0061] In step S203 above, model prompts are constructed based on transaction behavior features and terminal behavior features, completing the seamless conversion of heterogeneous risk control data into the semantic space of a large language model. Transaction behavior features provide the macro-level business context of fund flows, while terminal behavior features depict the micro-level physical interaction habits of the operating entity. By merging the two into a coherent natural language sequence through a preset template, the inherent contextual understanding and logical reasoning capabilities of the large language model can be activated, enabling it to simultaneously perceive business intent and behavioral reality, laying a multimodal alignment foundation for subsequent risk probability assessment.

[0062] The prompt words are then input into the risk identification model, a pre-trained large language model deployed locally on the user's terminal, triggering the forward computation process of the localized inference engine on the device. Upon receiving the prompt words, the model uses the attention mechanism of the base model and the personalized weight modulation of the low-rank adapter to analyze the correlation and deviation between features layer by layer. This utilizes on-device computing power to achieve real-time judgment, avoiding cloud round-trip latency, ensuring the continuity and immediacy of risk control decisions even in weak network or offline environments.

[0063] The locally deployed risk identification model outputs a transaction risk score and a risk cause explanation text, generating a bimodal risk control result that combines quantitative judgment and qualitative attribution. The transaction risk score reflects the matching degree between the current operation and the user's historical profile and the probability of potential risks in a continuous numerical form; the risk cause explanation text clearly points out the key basis for triggering the high-risk judgment in natural language.

[0064] Through the above steps, on the one hand, by using a locally deployed large language model to replace the traditional cloud-based centralized discrimination architecture, data transmission blockage and server queuing delays are eliminated, greatly improving the risk control response speed and significantly enhancing the timeliness of transaction interception in complex network environments; on the other hand, by transforming multi-dimensional behavioral features into semantic contexts that the model can understand through prompt word engineering, and combining them with personalized user profiles accumulated by low-rank adapters, the model output not only has high-precision risk probability quantification capabilities, but also provides intuitive and transparent risk attribution explanations.

[0065] In one optional embodiment, the risk identification model includes a base model and a low-rank adapter. After reporting risk events to the cloud based on abnormal transactions and corresponding risk cause explanations, the model further includes: real-time monitoring of the user terminal's operating status; when the user terminal is in an idle state, extracting historical transaction data from the user terminal's local database, wherein the historical transaction data includes historical transaction behavior data and historical terminal behavior data; constructing training samples based on the historical transaction data, and updating the model parameters of the low-rank adapter using gradients based on the training samples.

[0066] Furthermore, the risk identification model of this application is deployed locally on the user terminal, including a base model and a low-rank adapter. The base model is a large language model that has been pre-trained in the cloud for financial risk control, quantized with low precision, and then packaged and delivered to the user terminal. Its parameters remain frozen throughout the entire lifecycle of training on the terminal and it does not participate in gradient calculation or weight modification. The low-rank adapter is a combination of trainable low-rank matrices injected in parallel into the linear projection paths of each attention layer of the base model. It contains only a very small proportion of the parameters of the original model and is specifically designed to capture the user's personalized operating habits and task-specific features.

[0067] Specifically, the system monitors the user terminal's operating status in real time, dynamically sensing the device's current computing load, power consumption level, and network connectivity. This provides precise status judgment criteria for triggering subsequent model training tasks, ensuring that high-load computing only occurs when device resources are sufficient, avoiding the occupation of foreground business threads or excessive battery consumption. When the user terminal is in an idle state, historical transaction data is extracted from the user terminal's local database to accurately match training trigger conditions and data preparation stages. Once the user terminal meets the idle state judgment logic, historical records are securely retrieved from the local encrypted database to provide learning data for model fine-tuning.

[0068] Subsequently, training samples are constructed based on historical transaction data. Unstructured or semi-structured historical logs are transformed into sequence formats that conform to the input specifications of large language models. Through prompt word arrangement, timestamp alignment, and noise filtering, standard training pairs containing user historical profile descriptions and actual transaction contexts are generated, enabling the model to be fine-tuned with targeted supervision on the training samples.

[0069] Finally, the model parameters of the low-rank adapter are updated by gradient based on the training samples to achieve incremental learning and personalized evolution of the model. By fixing the base model parameters, the general financial risk control knowledge is not forgotten. Only the low-rank matrix parameters of the low-rank adapter are calculated and updated using backpropagation, so that the model can absorb the latest accumulated user operating habits and continuously reduce the loss function value between the predicted probability and the actual behavior, thereby achieving adaptive calibration.

[0070] In one optional embodiment, the steps of inputting model prompts into a risk identification model and outputting a transaction risk score and risk cause explanation text include: inputting model prompts into a risk identification model local to the user terminal; performing semantic encoding through a base model of the risk identification model to obtain input features; inputting these features into various attention layers of the base model; adjusting the representation weights of the input features in various attention layers of the base model through a low-rank adapter to obtain adjusted feature representations; and passing the adjusted feature representations to the decoder of the base model, whereby the decoder learns the semantic context based on the adjusted feature representations and generates a transaction risk score and risk cause explanation text, which are then output through an output layer.

[0071] Furthermore, the trained risk identification model can output a transaction risk score and an explanation of the risk causes. First, model prompts are obtained, encompassing both explicit transaction element features and implicit biological behavioral features of the user's transactions. Then, the model prompts are input into the risk identification model on the user's local terminal. The base model within the risk identification model first performs semantic encoding, mapping each sub-word unit in the prompts to a high-dimensional vector through a word embedding layer, and preserving sequence order information by combining positional encoding, thus obtaining the input features. Subsequently, the input features are fed into various attention layers of the base model. In each attention layer, a self-attention mechanism is used to calculate the attention scores between elements in the input features, initially extracting global dependencies. Next, feature adjustment is performed. In each attention layer of the base model, parallel low-rank adapters receive intermediate features from the attention layers. These low-rank adapters perform a linear transformation on the input features using their internal trainable low-rank matrices, adjusting the representation weights of the input features in each attention layer of the base model. This process utilizes the low-rank parameters updated during the idle training phase to inject users' personalized operating habits into the general features, resulting in an adjusted feature representation. The adjusted feature representation retains the general risk control understanding capability of the base model while incorporating personalized bias corrections for that specific user.

[0072] Finally, decoding and output operations are performed. The adjusted feature representation is passed to the decoder of the base model. Based on the adjusted feature representation, the decoder learns the semantic context by processing layer by layer through a multi-head attention mechanism and a feedforward neural network. The decoder ultimately generates two outputs: one is a transaction risk score output by the regression head, used to quantify the risk probability of the current transaction; the other is a risk cause explanation text output by the language generation head, used to describe the basis for judgment in natural language. Subsequently, the output layer standardizes the decoder output and outputs it to the upper-layer business logic.

[0073] The above steps, through standardized processing of semantic encoding of the base model and feature interaction of the attention layer, ensure the effective parsing and global association capture of complex heterogeneous prompt words in high-dimensional space. At the same time, by using the low-rank adapter to accurately control the representation weights, the seamless coupling of general large model capabilities and personalized fine-tuning parameters on the edge is achieved, and the deep integration of user-specific behavior patterns is completed with extremely low computing power consumption.

[0074] Step S204: Make a graded decision based on the transaction risk score, identify abnormal transactions, and report the risk event to the cloud based on the abnormal transaction and the corresponding risk cause explanation text.

[0075] In step S204 above, after obtaining the transaction risk score output by the risk identification model, the system compares it with the multi-level thresholds preset in the local security area to make a graded decision. For transactions determined to be high-risk, the system marks them as abnormal transactions. The system extracts the key identification information of the transaction from local memory, including the transaction serial number, timestamp, transaction amount, and risk cause explanation text, and constructs a structured risk event data packet. This data packet does not contain raw biometric data, but only the aforementioned key identifiers and explanatory text to ensure the principle of data minimization. Subsequently, the system calls the end-side encryption module to encrypt the risk event data packet, generating an encrypted risk event payload, and sends the encrypted payload to the cloud through the background service using the existing network connection.

[0076] After receiving a reported risk event, the cloud server decrypts and parses the data packet. The cloud uses the risk cause explanation text as high-value labeled data, combined with the user's historical behavioral data, to optimize the risk assessment model and update the rule engine. Simultaneously, the cloud synchronizes this anomaly marker to the user's account risk control profile for more stringent monitoring of subsequent transactions.

[0077] In one optional embodiment, the step of making a graded decision based on a transaction risk score includes: comparing the transaction risk score with a preset risk score threshold to obtain a comparison result, wherein the risk score threshold includes a first score threshold and a second score threshold, and the first score threshold is less than the second score threshold; allowing the transaction if the comparison result indicates that the transaction risk score is less than the first score threshold; triggering local dynamic verification on the user terminal if the comparison result indicates that the transaction risk score is greater than or equal to the first score threshold and less than or equal to the second score threshold; and blocking the transaction if the comparison result indicates that the transaction risk score is greater than the second score threshold.

[0078] Furthermore, during the tiered decision-making process, the system reads a preset first and second scoring threshold from a locally encrypted configuration file. The first scoring threshold is lower than the second scoring threshold, and each corresponds to a different risk level. Subsequently, the module receives the transaction risk score output from the risk identification model. The system then performs a logical comparison of the transaction risk score with both the first and second scoring thresholds.

[0079] If the transaction risk score is less than the first score threshold, the system determines the transaction to be low-risk, allows the transaction to proceed, the application front-end interface directly updates the transaction status to "processing", and silently executes the fund transfer instruction without any additional user interaction until the transaction is completed.

[0080] If the transaction risk score is greater than or equal to the first scoring threshold and less than or equal to the second scoring threshold, the system determines the transaction to be of medium risk and requires verification. The application's front-end interface pauses the fund transfer and displays a local dynamic verification window. This window requires the user to perform biometric identification or answer preset security questions. If the verification is successful, the block is lifted and the transaction is allowed; if the verification fails, it is considered an identity mismatch and the process is directly initiated.

[0081] If the transaction risk score exceeds the second threshold, the system determines the transaction to be high-risk, blocks the transaction, and immediately displays a transaction failure message on the application's front-end interface, blocking the current fund transfer instruction. Simultaneously, the system records this blocking event and triggers the subsequent reporting process.

[0082] By using a first and a second scoring threshold, risks are divided into three levels: low, medium, and high, corresponding to three strategies: allow, verify, and block, respectively. This avoids the user experience degradation or security vulnerabilities caused by a one-size-fits-all approach to risk control, achieving an optimal balance between security and user experience.

[0083] In one optional embodiment, the steps of identifying abnormal transactions and reporting risk events to the cloud based on the abnormal transactions and the corresponding risk cause explanation text include: in the case of transaction blocking, identifying the blocked transactions as abnormal transactions; obtaining transaction identifiers, transaction risk scores, timestamps, and anomaly type tags based on the abnormal transactions; generating risk event data based on the transaction identifiers, transaction risk scores, timestamps, anomaly type tags, and risk cause explanation text, and uploading it to the cloud.

[0084] In the event of a transaction blockade, the blocked transaction is identified as an abnormal transaction. The system sets a flag in the transaction's memory context or local temporary storage area, indicating its status as blocked - high risk, thus logically distinguishing it from ordinary transactions or transactions that only trigger verification. This establishes a logical connection between the blocking action and the anomaly classification. Simultaneously, key information is extracted from the context of the flagged abnormal transaction, including the transaction identifier, the abnormal transaction risk score, timestamp, and anomaly type label. A structured data object is constructed and encapsulated to obtain risk event data, which is then asynchronously sent to the cloud-based risk control server via an encrypted channel. The upload process is executed in a background thread. If the network is unavailable, the system temporarily stores the data in a local encrypted queue and retryes the upload once the network is restored, ensuring no data loss.

[0085] Through the above steps, transaction behavior data and terminal behavior data of user terminals are collected, and feature extraction is performed on the transaction behavior data and terminal behavior data to obtain transaction behavior features and terminal behavior features. Model prompt words are constructed based on the transaction behavior features and terminal behavior features, and the model prompt words are input into the risk identification model to output transaction risk scores and risk cause explanation text. The risk identification model is a pre-trained large language model deployed locally on the user terminal. It makes hierarchical decisions based on the transaction risk scores, identifies abnormal transactions, and reports risk events to the cloud based on abnormal transactions and corresponding risk cause explanation text.

[0086] In this embodiment, after feature extraction of the collected transaction behavior data and terminal behavior data, they are converted into model prompts in natural language form. This allows unstructured sensor data and structured transaction data to be uniformly adapted to the input semantic space of the machine model. The model prompts are then input into a risk identification model deployed locally on the user terminal, eliminating real-time dependence on cloud servers. The model performs forward inference locally, simultaneously outputting a quantitative transaction risk score and a qualitative explanation of the risk causes. This improves the efficiency of risk transaction identification and ensures the accuracy and real-time performance of risk transaction identification in complex environments. Furthermore, this solves the technical problem of low identification efficiency in related technologies that rely on a technical architecture of terminal data collection and reporting and centralized risk control decision-making in the cloud.

[0087] The following describes in detail another optional implementation method.

[0088] Figure 3 This is an optional transaction risk assessment system architecture diagram according to an embodiment of the present invention, such as... Figure 3 As shown, the transaction risk assessment system includes: a risk decision-making subsystem deployed locally on the user terminal. This subsystem performs data collection, feature engineering, prompt word construction, risk identification based on the risk identification model, and risk decision-making, and feeds the risk decision results back to the financial application in real time to achieve local risk control. Simultaneously, centralized basic model training is performed in the cloud to build a base model, and the model is compressed and distributed. During the risk identification process, the model parameters are updated in real time based on incremental data. The idle time training module can update the parameters of the low-rank adapter locally when the user terminal is idle, and transmit the real-time data to the cloud in encryption. The base model is then updated through federated aggregation via a federated aggregation server.

[0089] Figure 4 This is a schematic diagram of an optional transaction risk assessment process according to an embodiment of the present invention, such as... Figure 4 As shown, the risk assessment process for transactions includes:

[0090] Step 1: The user initiates a transaction, triggering the risk identification process;

[0091] Step 2: Real-time data acquisition and feature extraction. Real-time data includes transaction behavior data and terminal behavior data.

[0092] Step 3: Conduct a preliminary check based on the rules to screen out obvious risk events. If it is a normal transaction, the transaction will be allowed to proceed. If it is a suspicious transaction, proceed to step 4.

[0093] Step 4: Trigger edge-side inference;

[0094] Step 5: Constructing prompts;

[0095] Step Six: Risk Identification Model Reasoning;

[0096] Step 7: Output the risk score and interpretability text;

[0097] Step 8: Risk assessment. If the transaction is low-risk, the transaction is allowed; if the transaction is high-risk, the transaction is blocked and the risk is reported.

[0098] This invention encapsulates and deploys a pre-trained risk identification model directly on the user terminal, running it as an independent inference engine. This eliminates the real-time dependence on cloud servers, reduces the reliance of risk transaction identification on network and other environmental conditions, improves identification efficiency, and ensures accurate identification and real-time interception under heavy load. Simultaneously, the extracted features are converted into model prompts, enabling unstructured sensor data and structured transaction data to be uniformly adapted to the input semantic space of a large language model, thus improving the accuracy of the output results.

[0099] The following is a detailed description with reference to another embodiment.

[0100] Example 2

[0101] The transaction risk assessment device provided in this embodiment includes multiple implementation units, each of which corresponds to a specific implementation step in Embodiment 1 above. The specific implementation method and beneficial effects can be referred to the aforementioned method embodiment, and will not be repeated here.

[0102] Figure 5 This is a schematic diagram of an optional transaction risk assessment device according to an embodiment of the present invention, such as... Figure 5 As shown, the transaction risk assessment device may include: a data acquisition unit 51, an extraction unit 52, a construction unit 53, and an identification unit 54, wherein,

[0103] The data collection unit 51 is used to collect transaction behavior data and terminal behavior data of the user terminal;

[0104] Extraction unit 52 is used to extract features from transaction behavior data and terminal behavior data respectively to obtain transaction behavior features and terminal behavior features;

[0105] The construction unit 53 is used to construct model prompt words based on transaction behavior characteristics and terminal behavior characteristics, and input the model prompt words into the risk identification model to output transaction risk score and risk cause explanation text. The risk identification model is a pre-trained large language model deployed locally on the user terminal.

[0106] The identification unit 54 is used to make graded decisions based on transaction risk scores, identify abnormal transactions, and report risk events to the cloud based on abnormal transactions and corresponding risk cause explanation texts.

[0107] The aforementioned transaction risk assessment device collects transaction behavior data and terminal behavior data from the user terminal through the acquisition unit 51; extracts features from the transaction behavior data and terminal behavior data through the extraction unit 52 to obtain transaction behavior features and terminal behavior features; constructs model prompt words based on the transaction behavior features and terminal behavior features through the construction unit 53, inputs the model prompt words into the risk identification model, and outputs a transaction risk score and risk cause explanation text. The risk identification model is a pre-trained large language model deployed locally on the user terminal; and the identification unit 54 makes a graded decision based on the transaction risk score, identifies abnormal transactions, and reports risk events to the cloud based on abnormal transactions and corresponding risk cause explanation text.

[0108] In this embodiment, after feature extraction of the collected transaction behavior data and terminal behavior data, they are converted into model prompts in natural language form. This allows unstructured sensor data and structured transaction data to be uniformly adapted to the input semantic space of the machine model. The model prompts are then input into a risk identification model deployed locally on the user terminal, eliminating real-time dependence on cloud servers. The model performs forward inference locally, simultaneously outputting a quantitative transaction risk score and a qualitative explanation of the risk causes. This improves the efficiency of risk transaction identification and ensures the accuracy and real-time performance of risk transaction identification in complex environments. Furthermore, this solves the technical problem of low identification efficiency in related technologies that rely on a technical architecture of terminal data collection and reporting and centralized risk control decision-making in the cloud.

[0109] Furthermore, the acquisition unit includes: a first acquisition module, used to acquire the attitude data of the user terminal in three-dimensional space through the attitude acquisition sensor built into the user terminal; and a first recording module, used to identify touch events on the user terminal through the underlying touch interface of the operating system, and record touch data based on the touch events.

[0110] Further, the extraction unit includes: a first extraction module, used to extract preset risk fields based on transaction behavior data to obtain transaction behavior features; a second extraction module, used to extract transaction time intervals based on transaction behavior features, and extract target terminal behavior data within the transaction time intervals from terminal behavior data; a third extraction module, used to extract preset terminal behavior risk fields from target terminal behavior data; and a first calculation module, used to calculate terminal risk behavior parameters based on terminal behavior risk fields to obtain terminal behavior features, wherein the risk behavior parameters include at least one of the following: average acceleration, maximum angular velocity change rate, touch pressure standard deviation, median click interval, and trajectory curvature features.

[0111] Further, the identification unit includes: a first comparison module, used to compare the transaction risk score with a preset risk score threshold to obtain a comparison result, wherein the risk score threshold includes a first score threshold and a second score threshold, and the first score threshold is less than the second score threshold; a first release module, used to release the transaction when the comparison result indicates that the transaction risk score is less than the first score threshold; a first trigger module, used to trigger local dynamic verification on the user terminal when the comparison result indicates that the transaction risk score is greater than or equal to the first score threshold and less than or equal to the second score threshold; and a first blocking module, used to block the transaction when the comparison result indicates that the transaction risk score is greater than the second score threshold.

[0112] Furthermore, the identification unit also includes: a first identification module, used to identify the blocked transaction as an abnormal transaction in the event of transaction blocking; a first acquisition module, used to acquire the transaction identifier, transaction risk score, timestamp and abnormal type label based on the abnormal transaction; and a first generation module, used to generate risk event data based on the transaction identifier, transaction risk score, timestamp, abnormal type label and risk cause explanation text and upload it to the cloud.

[0113] Furthermore, the risk identification model includes a base model and a low-rank adapter, and the transaction risk assessment device further includes: a first monitoring module for real-time monitoring of the user terminal's operating status; a first extraction module for extracting historical transaction data from the user terminal's local database when the user terminal is in an idle state, wherein the historical transaction data includes historical transaction behavior data and historical terminal behavior data; and a first update module for constructing training samples based on the historical transaction data and performing gradient updates on the low-rank adapter's model parameters based on the training samples.

[0114] Furthermore, the construction unit includes: a first encoding module, used to input model prompts into the risk identification model on the user terminal, perform semantic encoding through the base model of the risk identification model to obtain input features, and input them into each attention layer of the base model; a first adjustment module, used to adjust the representation weights of the input features in each attention layer of the base model through a low-rank adapter to obtain the adjusted feature representation; and a first generation module, used to pass the adjusted feature representation to the decoder of the base model, whereby the decoder learns the semantic context based on the adjusted feature representation, generates a transaction risk score and risk cause explanation text, and outputs it through the output layer.

[0115] It should be noted that the acquisition unit 51, extraction unit 52, construction unit 53, and identification unit 54 mentioned above correspond to steps S201 to S204 in Embodiment 1. The instances and application scenarios implemented by the above units and corresponding steps are the same, but are not limited to the content disclosed in Embodiment 1. It should be noted that the above modules or units can be hardware or software components stored in memory (e.g., memory 104) and processed by one or more processors (e.g., processors 102a, 102b, ..., 102n). The above modules or units can also be part of a device and run in the computer terminal 10 provided in Embodiment 1.

[0116] The invention will now be described in conjunction with another alternative embodiment.

[0117] Example 3

[0118] The present invention can also provide an electronic device. Figure 6 This is a hardware structure block diagram of an electronic device (or mobile device) according to an optional method for assessing transaction risk according to an embodiment of the present invention, such as... Figure 6 As shown, the electronic device may include: one or more ( Figure 6 (Only one is shown) Processor 602, memory 604, memory controller, and peripheral interface, wherein the peripheral interface is connected to the radio frequency module, audio module and display.

[0119] The memory can be used to store software programs and modules, such as the program instructions / modules corresponding to the methods and apparatus in the embodiments of this application. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory, thereby implementing the above-described methods. The memory may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory may further include memory remotely located relative to the processor, and these remote memories can be connected to the terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0120] The processor can access information and applications stored in the memory via a transmission device to perform the following steps: collecting transaction behavior data and terminal behavior data from the user terminal; extracting features from the transaction behavior data and terminal behavior data to obtain transaction behavior features and terminal behavior features; constructing model prompt words based on the transaction behavior features and terminal behavior features, inputting the model prompt words into the risk identification model, and outputting a transaction risk score and risk cause explanation text. The risk identification model is a pre-trained large language model deployed locally on the user terminal; making graded decisions based on the transaction risk score, identifying abnormal transactions, and reporting risk events to the cloud based on the abnormal transactions and the corresponding risk cause explanation text.

[0121] The processor can access information and applications stored in memory via a transmission device to perform the following steps: acquire the user terminal's attitude data in three-dimensional space through the attitude acquisition sensor built into the user terminal; identify touch events on the user terminal through the operating system's underlying touch interface, and record touch data based on the touch events.

[0122] The processor can access information and applications stored in the memory via a transmission device to perform the following steps: extracting preset risk fields based on transaction behavior data to obtain transaction behavior characteristics; extracting transaction time intervals based on transaction behavior characteristics, and extracting target terminal behavior data within the transaction time intervals from terminal behavior data; extracting preset terminal behavior risk fields from the target terminal behavior data; calculating terminal risk behavior parameters based on the terminal behavior risk fields to obtain terminal behavior characteristics, wherein the risk behavior parameters include at least one of the following: average acceleration, maximum angular velocity change rate, touch pressure standard deviation, median click interval, and trajectory curvature characteristics.

[0123] The processor can access information and applications stored in the memory via a transmission device to perform the following steps: comparing the transaction risk score with a preset risk score threshold to obtain a comparison result, wherein the risk score threshold includes a first score threshold and a second score threshold, and the first score threshold is less than the second score threshold; allowing the transaction if the comparison result indicates that the transaction risk score is less than the first score threshold; triggering local dynamic verification on the user terminal if the comparison result indicates that the transaction risk score is greater than or equal to the first score threshold and less than or equal to the second score threshold; and blocking the transaction if the comparison result indicates that the transaction risk score is greater than the second score threshold.

[0124] The processor can access information and applications stored in the memory via the transmission device to perform the following steps: in the event of a transaction blockage, identify the blocked transaction as an abnormal transaction; obtain the transaction identifier, transaction risk score, timestamp, and anomaly type label based on the abnormal transaction; generate risk event data based on the transaction identifier, transaction risk score, timestamp, anomaly type label, and risk cause explanation text, and upload it to the cloud.

[0125] The processor can access information and applications stored in the memory via a transmission device to perform the following steps: The risk identification model includes a base model and a low-rank adapter. After reporting risk events to the cloud based on abnormal transactions and corresponding risk cause explanation texts, it also includes: real-time monitoring of the user terminal's operating status; when the user terminal is in an idle state, extracting historical transaction data from the user terminal's local database, where the historical transaction data includes historical transaction behavior data and historical terminal behavior data; constructing training samples based on the historical transaction data, and updating the model parameters of the low-rank adapter using gradients based on the training samples.

[0126] The processor can access information and applications stored in memory via a transmission device to perform the following steps: inputting model prompts into the risk identification model on the user terminal; semantically encoding the input features through the base model of the risk identification model to obtain input features; inputting these features into each attention layer of the base model; adjusting the representation weights of the input features in each attention layer of the base model through a low-rank adapter to obtain adjusted feature representations; passing the adjusted feature representations to the decoder of the base model, whereby the decoder learns the semantic context based on the adjusted feature representations, generates a transaction risk score and risk cause explanation text, and outputs it through the output layer.

[0127] This invention provides a scheme for assessing transaction risk. After extracting features from collected transaction behavior data and terminal behavior data, these are converted into model prompts in natural language. This allows unstructured sensor data and structured transaction data to be uniformly adapted to the input semantic space of the machine model. The model prompts are then input into a risk identification model deployed locally on the user's terminal, eliminating real-time dependence on cloud servers. The model performs forward inference locally, simultaneously outputting a quantitative transaction risk score and a qualitative explanation of the risk's causes. This improves the efficiency of risk transaction identification and ensures the accuracy and real-time performance of risk transaction identification in complex environments. Furthermore, this solves the problem of low identification efficiency in related technologies that rely on a technical architecture of terminal data collection and reporting and centralized cloud-based risk control decision-making for transaction risk identification.

[0128] Those skilled in the art will understand that Figure 6The structure shown is for illustrative purposes only. Electronic devices can also be smartphones, tablets, handheld computers, mobile internet devices (MIDs), PADs, and other terminal devices. Figure 6 This does not limit the structure of the aforementioned electronic device. For example, electronic devices may also include components that are more... Figure 6 The more or fewer components shown (such as network interfaces, display devices, etc.), or having the same Figure 6 The different configurations shown.

[0129] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing the hardware related to the terminal device. The program can be stored in a computer-readable storage medium, which may include: flash drive, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0130] The invention will now be described in conjunction with another alternative embodiment.

[0131] Example 4

[0132] This invention also provides a computer-readable storage medium. Optionally, in this invention, the computer-readable storage medium can be used to store the program code executed by the transaction risk assessment method provided in Embodiment 1.

[0133] Optionally, in this embodiment of the invention, the storage medium may be located in any computer terminal in a group of computer terminals in a computer network, or in any mobile terminal in a group of mobile terminals.

[0134] This invention also provides a computer program product, which, when executed on a data processing device, is suitable for performing the steps of a transaction risk assessment method: collecting transaction behavior data and terminal behavior data from a user terminal; extracting features from the transaction behavior data and terminal behavior data to obtain transaction behavior features and terminal behavior features; constructing model prompt words based on the transaction behavior features and terminal behavior features, inputting the model prompt words into a risk identification model, and outputting a transaction risk score and risk cause explanation text, wherein the risk identification model is a pre-trained large language model deployed locally on the user terminal; making hierarchical decisions based on the transaction risk score, identifying abnormal transactions, and reporting risk events to the cloud based on the abnormal transactions and the corresponding risk cause explanation text.

[0135] The sequence numbers of the above embodiments of the present invention are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0136] In the above embodiments of the present invention, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0137] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For instance, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0138] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0139] Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0140] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, 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 storage medium 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 described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0141] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A method for assessing transaction risk, characterized in that, include: Collect transaction behavior data and terminal behavior data from user terminals; Feature extraction is performed on the transaction behavior data and the terminal behavior data respectively to obtain transaction behavior features and terminal behavior features; Model prompt words are constructed based on the transaction behavior characteristics and the terminal behavior characteristics, and the model prompt words are input into the risk identification model to output a transaction risk score and risk cause explanation text. The risk identification model is a pre-trained large language model deployed locally on the user terminal. Based on the transaction risk score, a graded decision is made to identify abnormal transactions, and risk events are reported to the cloud based on the abnormal transactions and the corresponding risk cause explanation text.

2. The method according to claim 1, characterized in that, The steps for collecting user terminal behavior data include: The user terminal's attitude data in three-dimensional space is acquired through the attitude acquisition sensor built into the user terminal; The system identifies touch events on the user terminal through the underlying touch interface of the operating system and records touch data based on the touch events.

3. The method according to claim 1, characterized in that, The steps of extracting features from the transaction behavior data and the terminal behavior data to obtain transaction behavior features and terminal behavior features respectively include: Based on the transaction behavior data, preset risk fields are extracted to obtain the transaction behavior characteristics; Based on the transaction behavior characteristics, the transaction time interval is extracted, and the target terminal behavior data within the transaction time interval is extracted from the terminal behavior data. Extract preset terminal behavior risk fields from the target terminal behavior data; Based on the terminal behavior risk field, terminal risk behavior parameters are calculated to obtain terminal behavior characteristics. The risk behavior parameters include at least one of the following: average acceleration, maximum angular velocity change rate, touch pressure standard deviation, median click interval, and trajectory curvature characteristics.

4. The method according to claim 1, characterized in that, The steps for making tiered decisions based on the transaction risk score include: The transaction risk score is compared with a preset risk score threshold to obtain a comparison result. The risk score threshold includes a first score threshold and a second score threshold, and the first score threshold is less than the second score threshold. If the comparison result indicates that the transaction risk score is less than the first score threshold, the transaction is approved. If the comparison result indicates that the transaction risk score is greater than or equal to the first score threshold and less than or equal to the second score threshold, the local dynamic verification of the user terminal is triggered. If the comparison result indicates that the transaction risk score is greater than the second score threshold, the transaction is blocked.

5. The method according to claim 4, characterized in that, The steps of identifying abnormal transactions and reporting risk events to the cloud based on the abnormal transactions and the corresponding risk cause explanation text include: In the event of a transaction blockade, the blocked transaction will be identified as the abnormal transaction. Based on the abnormal transaction, obtain the transaction identifier, transaction risk score, timestamp, and abnormality type label of the abnormal transaction; Risk event data is generated based on the transaction identifier, the transaction risk score, the timestamp, the anomaly type label, and the risk cause explanation text, and then uploaded to the cloud.

6. The method according to claim 1, characterized in that, The risk identification model includes a base model and a low-rank adapter. After reporting the risk event to the cloud based on the abnormal transaction and the corresponding risk cause explanation text, it also includes: Real-time monitoring of the operating status of the user terminal; When the user terminal is in an idle state, historical transaction data is extracted from the local database of the user terminal, wherein the historical transaction data includes historical transaction behavior data and historical terminal behavior data. Training samples are constructed based on the historical transaction data, and the model parameters of the low-rank adapter are updated using gradients based on the training samples.

7. The method according to claim 6, characterized in that, The steps of inputting the model prompts into the risk identification model and outputting a transaction risk score and an explanation of the causes of risk include: The model prompt words are input into the risk identification model local to the user terminal, and semantically encoded through the base model of the risk identification model to obtain input features, which are then input into each attention layer of the base model. The low-rank adapter is used to adjust the representation weights of the input features in each attention layer of the base model to obtain the adjusted feature representation. The adjusted feature representation is passed to the decoder of the base model, which learns the semantic context based on the adjusted feature representation, generates the transaction risk score and the risk cause explanation text, and outputs them through the output layer.

8. A device for assessing transaction risk, characterized in that, include: The data collection unit is used to collect transaction behavior data and terminal behavior data from user terminals. An extraction unit is used to extract features from the transaction behavior data and the terminal behavior data respectively to obtain transaction behavior features and terminal behavior features; The construction unit is used to construct model prompt words based on the transaction behavior characteristics and the terminal behavior characteristics, input the model prompt words into the risk identification model, and output a transaction risk score and risk cause explanation text, wherein the risk identification model is a pre-trained large language model deployed locally on the user terminal; The identification unit is used to make a graded decision based on the transaction risk score, identify abnormal transactions, and report risk events to the cloud based on the abnormal transactions and the corresponding risk cause explanation text.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored computer program, wherein, when the computer program is executed, it controls the device on which the computer-readable storage medium is located to perform the transaction risk assessment method according to any one of claims 1 to 7.

10. An electronic device, characterized in that, It includes one or more processors and a memory, the memory being used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to implement the transaction risk assessment method according to any one of claims 1 to 7.

11. A computer program product, characterized in that, The computer program product includes a computer program, wherein the computer program, when executed by a processor, implements the transaction risk assessment method according to any one of claims 1 to 7.

Images