Real-time risk control and abnormal card swiping interception method and system based on edge computing

Abstract

This application discloses a real-time risk control and abnormal card swipe interception method and system based on edge computing, relating to the field of edge computing technology and applied to the terminal side. The terminal side is deployed within a super SIM card and includes an edge intelligent agent (EIA) running in a secure and trusted execution environment (TEE), a local rule base (LRR), and an abnormal transaction interception module (ATIM). The method includes: collecting and encrypting multi-source feature data for transmission; performing local real-time risk assessment based on the local rule base (LRR) to generate a risk score; if the risk score is detected to reach a preset interception threshold, actively blocking the current transaction at the NFC transaction link layer and generating an interception log; receiving updated rules and model parameters from the cloud-based risk control platform; and receiving a transaction cancellation instruction issued by the cloud-based risk control platform when the global risk assessment determines that interception is necessary; and reporting the interception log to the operator's backend so that the operator's backend can verify and execute fund return or compensation operations.

Description

Technical Field

[0001] This application relates to the technical field of edge computing, and in particular to a method and system for real-time risk control and abnormal card swipe interception based on edge computing. Background Technology

[0002] With the deep integration of the Internet of Things (IoT) and Near Field Communication (NFC) technologies, mobile payments based on Super SIM cards have been widely used in high-frequency transaction scenarios such as public transportation, campus cards, and digital wallets. In these scenarios, transactions are typically required to be completed in a very short time, which heavily relies on the payment system's ability to detect risks in real time at the millisecond level and proactively block abnormal transactions. At the same time, to ensure the security of funds and data, the risk control decision-making process must meet high requirements for privacy protection and system isolation.

[0003] However, existing risk control solutions mainly rely on cloud-based risk detection or fixed rule interception on the SIM card. In cloud-based detection solutions, all card transactions need to be reported to the cloud in real time, and the cloud performs batch anomaly detection based on big data models. This highly centralized processing mode results in large data reporting delays, and may even be unable to perform detection in network outages or weak network environments. It cannot meet the stringent millisecond-level response requirements of NFC transactions, and the cross-network transmission of a large amount of sensitive transaction data and user identity information also faces extremely high privacy leakage risks. On the other hand, existing fixed rule interception solutions on the SIM card typically only load a set of static threshold rules for matching on the card side. These static rules are difficult to cover the increasingly complex and diverse dynamic attack scenarios, and rule updates rely on remote management and distribution, resulting in a serious delay in response and leading to high false negative and false positive rates in risk control.

[0004] Therefore, existing risk control mechanisms that rely on centralized cloud-based detection or static rules on terminals suffer from high real-time response latency, strong dependence on network and privacy data, and lagging policy adaptive updates when facing new types of attacks. They cannot achieve proactive interception of abnormal transactions in real time locally while ensuring data privacy and security.

[0005] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0006] The main purpose of this application is to provide a real-time risk control and abnormal card swipe interception method and system based on edge computing, which aims to solve the technical problems of high network latency and outdated static rules in the existing technology, which cannot achieve local real-time interception of NFC transactions while ensuring privacy.

[0007] To achieve the above objectives, this application proposes a real-time risk control and abnormal card swipe interception method based on edge computing, applied to the terminal side. The terminal side is deployed within a Super SIM card and includes an Edge Intelligent Agent (EIA) running within a Secure and Trusted Execution Environment (TEE), a local rule base (LRR), and an abnormal transaction interception module (ATIM). The method includes: The Edge Intelligent Agent (EIA) receives multi-source feature data from the mobile application when it detects an NFC transaction trigger. This data is collected and encrypted and transmitted by the EIA, which integrates NFC transaction data, GPS location data, accelerometer frequency domain feature data, and surrounding Bluetooth Low Energy device identification data. The edge intelligent agent (EIA) performs local real-time risk assessment based on the local rule base (LRR) to generate a risk score. If the abnormal transaction interception module ATIM detects that the risk score has reached the preset interception threshold, it will actively block the current transaction at the NFC transaction link layer, reject the NFC command response of the current transaction, physically cut off the transaction link at the hardware communication layer, and generate an interception log. It communicates with the cloud-based risk control platform, receives updated rules and model parameters from the cloud-based risk control platform, and reports feature summaries to the cloud-based risk control platform for global risk assessment; and receives transaction cancellation instructions issued by the cloud-based risk control platform when the global risk assessment determines that interception is necessary. The interception logs are reported to the operator's backend so that the operator's backend can verify the intercepted transactions based on the interception logs and perform fund refund or compensation operations after the verification is successful.

[0008] In one embodiment, the step of receiving multi-source feature data—which integrates NFC transaction data, GPS location data, accelerometer frequency domain feature data, and surrounding Bluetooth Low Energy device identification data—through the Edge Intelligent Agent (EIA) when the mobile application detects an NFC transaction trigger, includes: When the mobile application detects a transaction trigger signal from the NFC reader, it reads the transaction ID, transaction amount, and timestamp from the transaction register to generate NFC transaction data. Receive GPS data collected and GeoHash encoded by the sensor interface by the mobile application, extract the frequency domain characteristics of the original data of the accelerometer in the past preset period, and obtain the device identifier list obtained by scanning the surrounding Bluetooth Low Energy devices. The mobile application receives a fused feature data packet generated by serializing and fusing the NFC transaction data, GeoHash encoding, spectrum features, and device identifier list according to a predefined data structure. Receive the fused feature data packet encrypted by the mobile application using a symmetric encryption algorithm.

[0009] In one embodiment, the step of generating a risk score by performing a local real-time risk assessment based on the local rule base LRR through the edge intelligent agent EIA includes: The edge intelligent agent (EIA) running within a secure and trusted execution environment (TEE) receives and parses the multi-source feature data, reads the current version number from the LRR, and verifies whether the version number is consistent with the latest version issued by the cloud-based risk control platform; if the version is outdated, the risk assessment is suspended and an update is requested. A fast rule check is performed on the current transaction based on the static threshold rules in the LRR. The static threshold rules include a single transaction amount threshold and a card swipe frequency threshold within a unit time window. If the fast rule check matches any threshold rule, the interception decision is directly output and a risk score is generated. If the fast rule check does not match any threshold rule, the decision tree model in the LRR is invoked to perform tree-based reasoning based on the multi-source feature data and generate a first risk score.

[0010] In one embodiment, the step of generating a risk score by performing local real-time risk assessment based on the local rule base LRR through the edge intelligent agent EIA further includes: Determine whether the first risk score falls within a preset suspicious score range; If the first risk score is within the suspicious score range, then the deep neural network (DNN) model in the LRR is activated, the multi-source feature data is input into the DNN model for inference, and a second risk score is generated. The first risk score and the second risk score are weighted and calculated to generate a risk score.

[0011] In one embodiment, the steps of actively blocking the current transaction at the NFC transaction link layer, rejecting the NFC command response of the current transaction, physically severing the transaction link at the hardware communication layer, and generating an interception log if the abnormal transaction interception module ATIM detects that the risk score has reached a preset interception threshold, and generating an interception log include: The risk score is obtained through the abnormal transaction interception module ATIM, and the risk score is compared with a preset high-risk interception threshold; If the risk score is greater than or equal to the high-risk interception threshold, a blocking command is sent through the NFC transaction link layer of the Super SIM card to reject the NFC command response of the current transaction and physically cut off the transaction link at the underlying hardware communication layer. Construct a log object, which includes a transaction ID, timestamp, risk score, and triggering model identifier or rule identifier; The log object is written to a circular buffer, encrypted, and then stored in the persistent storage medium of the Super SIM card. The log object is then reported to the operator's backend as an interception log.

[0012] In one embodiment, the method further includes performing a global risk collaborative assessment with a cloud-based risk control platform, specifically including: If the risk score is within a preset review interval, the multi-source feature data is de-identified to generate a feature summary; The feature summary and risk score are reported to the cloud-based risk control platform so that the cloud-based risk control platform can conduct in-depth assessment based on global profile data and generate cloud-based risk assessment results. The global profile data includes a database of users’ historical transaction behavior, a database of device fingerprint blacklists, and regional risk heat maps. If the cloud-based risk assessment result exceeds the preset cloud-based interception threshold, a transaction cancellation instruction will be generated.

[0013] In one embodiment, the execution of the transaction reversal instruction includes: After receiving the transaction cancellation instruction via the ATIM on the terminal side, the digital signature of the transaction cancellation instruction is verified within the TEE; After the signature verification is successful, a transaction cancellation command is sent through the NFC transaction link layer of the Super SIM card to revert the status of the approved transaction to the incomplete status. Based on the ATIM, a supplementary interception log is generated and reported to the operator's backend. The supplementary interception log includes the transaction ID, the cloud risk assessment result, and the timestamp of the transaction cancellation instruction execution.

[0014] In one embodiment, the method further includes receiving updated rules and model parameters issued by a cloud-based risk control platform, specifically including: The system receives incremental update packages from the cloud-based risk control platform. These packages are generated by the cloud-based risk control platform obtaining the latest version of the full rule library and performing binary differential comparison with the current version of the full rule library to generate a package containing difference fields. The package is then encrypted and digitally signed before being sent through the operator's private network channel. The incremental update package is decrypted, the digital signature is verified, and the incremental update package is merged and updated with the locally stored rule base file.

[0015] In one embodiment, the step of verifying the intercepted transactions based on the interception logs and performing fund refund or compensation operations after successful verification includes: Based on parsing the interception logs in the operator's backend, the transaction IDs are extracted from the interception logs. Call the billing system interface to query the billing status corresponding to the transaction ID; If the bill status is "payment successful", a refund instruction will be generated according to the preset compensation strategy and sent to the billing system; Based on the billing system's response to the refund instruction, the funds are either returned to the original payment method or the account balance is recharged.

[0016] Furthermore, to achieve the above objectives, this application also proposes a real-time risk control and abnormal card swipe interception system based on edge computing, the system comprising: On the mobile application side, it is configured to collect and encrypt multi-source feature data, which integrates NFC transaction data, GPS location data, accelerometer frequency domain feature data, and surrounding Bluetooth Low Energy device identification data, and transmit it to the edge smart agent on the terminal side when an NFC transaction is detected; and to receive and display risk control decision results. On the terminal side, deployed within the Super SIM card, it includes an Edge Intelligent Agent (EIA) running within a Secure and Trusted Execution Environment (TEE), a Local Rule Base (LRR), and an Abnormal Transaction Interception Module (ATIM). Upon receiving the multi-source feature data, the EIA performs a local real-time risk assessment based on the LRR to generate a risk score. If the ATIM detects that the risk score reaches a preset interception threshold, it actively blocks the current transaction at the NFC transaction link layer, rejects the NFC command response for the current transaction, physically disconnects the transaction link at the hardware communication layer, and generates an interception log. The cloud-based risk control platform is configured to communicate with the terminal side, send updated rules and model parameters to the terminal side, and receive feature summaries reported by the terminal side for global risk assessment; if the global risk assessment determines that the transaction should be blocked, a transaction cancellation instruction is sent to the terminal side. The operator's backend is configured to receive interception logs from the terminal side, verify the intercepted transactions based on the interception logs, and perform fund refund or compensation operations after successful verification.

[0017] This application proposes a real-time risk control and abnormal card swipe interception method and system based on edge computing, applied to the terminal side. The terminal side is deployed within a Super SIM card and includes an Edge Intelligent Agent (EIA), a Local Rule Base (LRR), and an Abnormal Transaction Interception (ATIM) module running within a Secure and Trusted Execution Environment (TEE). The method includes: receiving multi-source feature data from a mobile application terminal when an NFC transaction is detected via the Edge Intelligent Agent (EIA), which collects and encrypts and transmits fused NFC transaction data, GPS location data, accelerometer frequency domain feature data, and surrounding Bluetooth Low Energy device identification data; performing local real-time risk assessment based on the Local Rule Base (LRR) to generate a risk score; and if the abnormal transaction... If the ATIM intercept module detects that the risk score has reached a preset interception threshold, it will actively block the current transaction at the NFC transaction link layer, reject the NFC command response for the current transaction, physically disconnect the transaction link at the hardware communication layer, and generate an interception log. It will also communicate with the cloud-based risk control platform, receive updated rules and model parameters from the cloud-based risk control platform, and report feature summaries to the cloud-based risk control platform for global risk assessment. Furthermore, it will receive transaction cancellation instructions issued by the cloud-based risk control platform when the global risk assessment determines that interception is necessary. Finally, it will report the interception log to the operator's backend, enabling the operator's backend to verify the intercepted transaction based on the interception log and execute fund refund or compensation operations after successful verification. This application employs a technical approach that deploys an edge intelligent agent within the TEE of the Super SIM card, combined with a local rule base, to perform real-time risk assessment and actively block transactions at the NFC link layer. This solves the problems of high network latency and static rule lag in existing pure cloud-based risk control systems, which prevent real-time interception of abnormal transactions. It achieves millisecond-level local real-time risk control interception even in offline or weak network environments. At the same time, through localized data processing and hardware isolation of the TEE, it significantly reduces the reliance on cloud-based privacy data transmission, ensuring the security and reliability of risk control decisions. Attached Figure Description

[0018] 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.

[0019] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 This is a flowchart illustrating an embodiment of the real-time risk control and abnormal card swipe interception method based on edge computing in this application. Figure 2 This is a flowchart illustrating Embodiment 2 of the real-time risk control and abnormal card swipe interception method based on edge computing in this application. Figure 3 This is a flowchart illustrating Embodiment 3 of the real-time risk control and abnormal card swipe interception method based on edge computing in this application; Figure 4 This is a flowchart illustrating Embodiment 4 of the edge computing-based real-time risk control and abnormal card swipe interception system of this application.

[0021] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0022] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0023] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0024] Due to the high network latency and outdated static rules of existing technologies, it is impossible to achieve local real-time interception of NFC transactions while ensuring privacy.

[0025] Based on this, the embodiments of this application provide a real-time risk control and abnormal card swipe interception method based on edge computing, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the real-time risk control and abnormal card swipe interception method based on edge computing in this application.

[0026] In this embodiment, the method is applied to the terminal side, which is deployed within a super SIM card and includes an Edge Intelligent Agent (EIA) running within a Secure and Trusted Execution Environment (TEE), a local rule base (LRR), and an abnormal transaction interception module (ATIM); including steps S10~S50: Step S10: When the mobile application detects an NFC transaction trigger, the edge intelligent agent EIA receives and encrypts multi-source feature data that integrates NFC transaction data, GPS location data, accelerometer frequency domain feature data, and surrounding Bluetooth Low Energy device identification data.

[0027] It should be noted that the terminal side refers to the device entity that carries the Super SIM card and runs the related risk control logic; the Super SIM card refers to the smart card chip with large-capacity storage, high-speed data processing capabilities and an independent security architecture; the Secure and Trusted Execution Environment (TEE) refers to the high-security processing area isolated inside the Super SIM card, which has the ability to prevent hardware-level tampering and software-level reverse attacks; and the Edge Intelligent Agent (EIA) refers to the software or firmware component deployed within the Secure and Trusted Execution Environment (TEE) that is responsible for executing local risk control logic and data scheduling.

[0028] In addition, the mobile application refers to the client application running on the mobile terminal's operating system, responsible for interacting with the NFC reader and collecting sensor data; NFC transaction trigger refers to the event where the mobile application receives a payment or authentication request initiated by the reader via near-field communication technology; multi-source feature data refers to a heterogeneous raw data set containing dimensions such as NFC transaction data, GPS location information, accelerometer frequency domain features, and device environment features. NFC transaction data records the basic attributes of the current transaction session, including transaction ID, transaction amount, and timestamp. GPS location data is the device's spatial coordinate information obtained through the mobile terminal's positioning module. Accelerometer frequency domain feature data is the feature vector extracted after performing frequency domain analysis such as Fast Fourier Transform on the raw motion signals collected by the mobile terminal's accelerometer over a preset time period. Surrounding Bluetooth Low Energy device identification data is a list of Bluetooth device MAC addresses or broadcast names obtained by the mobile terminal scanning its surrounding environment.

[0029] In one possible implementation, the encrypted transmission can employ the national standard SM4 symmetric encryption algorithm. The mobile application uses a session key negotiated with the Edge Intelligent Agent (EIA) to encrypt multi-source feature data packets and transmits them to the Edge Intelligent Agent (EIA) via a near-field communication interface or an internal inter-process communication channel.

[0030] Step S20: The edge intelligent agent EIA performs a local real-time risk assessment based on the local rule base LRR to generate a risk score.

[0031] It should be noted that the Local Rule Base (LRR) refers to a set of risk control strategy data, including static threshold rules and machine learning model parameters, stored in the persistent secure storage area of ​​the Super SIM card. Local real-time risk assessment refers to the process by which the Edge Intelligent Agent (EIA) uses computing power locally to perform real-time analysis and threat assessment of current transaction characteristics. Risk score refers to the numerical value or level output from the assessment process, used to quantify the potential risk level of the current transaction.

[0032] This embodiment aims to utilize the edge computing power of the Super SIM card to achieve millisecond-level offline risk control judgment in environments with no or weak network coverage, avoiding the network transmission delay of traditional cloud-based risk control, thereby enabling rapid response and initial identification of abnormal transactions without altering the user's card-swiping experience.

[0033] In one possible implementation, local real-time risk assessment can employ a multi-level serial assessment mechanism. First, a rapid check based on static threshold rules is performed. If no match is found, a decision tree model or a deep neural network model is further invoked for deep reasoning, and finally, a comprehensive risk score is output.

[0034] In addition, in this embodiment, before conducting the evaluation, the Edge Intelligent Agent (EIA) will first verify the version number of the local rule base (LRR). If it finds that the version is behind the latest version on the cloud, it will trigger a silent update process to ensure the timeliness of the evaluation basis.

[0035] Step S30: If the abnormal transaction interception module ATIM detects that the risk score has reached the preset interception threshold, it actively blocks the current transaction at the NFC transaction link layer, rejects the NFC command response of the current transaction, physically cuts off the transaction link at the hardware communication layer, and generates an interception log.

[0036] It should be noted that the Abnormal Transaction Interception Module (ATIM) refers to the functional component deployed within the Super SIM card responsible for transaction blocking and log scheduling; the preset blocking threshold refers to the critical value pre-set by the system to determine when the risk score reaches a level that necessitates immediate transaction blocking; the NFC transaction link layer refers to the underlying physical and logical channel for radio frequency communication and protocol interaction between the Super SIM card and the external NFC reader / writer; actively blocking the current transaction refers to directly cutting off the communication response at the NFC transaction link layer, preventing the transaction process from continuing. Physically cutting off the transaction link at the underlying hardware communication layer directly interrupts data interaction at the physical or logical link layer of radio frequency communication, preventing the reader / writer from receiving the confirmation signal required to complete the transaction.

[0037] This embodiment aims to directly cut off the fund transfer path of abnormal transactions at the hardware communication layer, implement physical-level real-time circuit breaking, and prevent stolen funds from actually being credited to the account.

[0038] In one possible implementation, actively blocking the current transaction can be achieved by the abnormal transaction interception module ATIM sending a blocking command to the NFC transaction link layer, refusing to respond to the application protocol data unit (APDU) commands of the external reader / writer, and simultaneously constructing a log object containing the transaction ID, timestamp, and risk score and writing it to the circular buffer.

[0039] In one specific implementation, the abnormal transaction interception module ATIM detects that the risk score of the current transaction is 85 points, which exceeds the preset interception threshold of 80 points. The abnormal transaction interception module ATIM immediately sends a blocking command through the NFC transaction link layer, refuses to respond to the gate's deduction request, and generates an interception log containing the transaction ID "TX20231024001" and the risk score "85" and stores it in the secure storage area.

[0040] Step S40: Communicate with the cloud-based risk control platform, receive updated rules and model parameters from the cloud-based risk control platform, and report feature summaries to the cloud-based risk control platform for global risk assessment; and receive transaction cancellation instructions issued by the cloud-based risk control platform when the global risk assessment determines that interception is necessary.

[0041] It should be noted that the cloud-based risk control platform refers to a backend risk control server cluster with massive data processing capabilities and a global perspective; updated rules and model parameters refer to risk control strategy data generated by the cloud based on the latest iteration and prepared for distribution to the terminal; feature summary refers to a data structure generated after anonymizing and dimensionality reduction of the original multi-source feature data, which does not contain plaintext privacy but retains risk control value; global risk assessment refers to the process by which the cloud-based risk control platform conducts in-depth correlation analysis of feature summaries in conjunction with global profile data; and transaction cancellation instruction refers to the control signaling generated by the cloud after determining that a transaction has serious risks, used to forcibly roll back the status of a released transaction.

[0042] This embodiment overcomes the limitations of local computing power and data silos in the Super SIM card by constructing an end-to-cloud collaborative risk control mechanism. It enables the cloud to perform post-event deep circuit breaking for "gray area" transactions that are difficult to determine locally, while ensuring the continuous evolution and timeliness of local risk control strategies.

[0043] In one possible implementation, receiving updated rules and model parameters from the cloud-based risk control platform can be done by receiving incremental update packets to reduce bandwidth consumption; feature summary reporting can be triggered when the risk score is in the pending review range.

[0044] In addition, after receiving a transaction revocation instruction on the terminal side, the abnormal transaction interception module ATIM will verify the digital signature of the instruction within the Secure and Trusted Execution Environment (TEE). Only after confirming its legitimacy will the state rollback be executed to prevent malicious revocation caused by forged instructions.

[0045] In one specific implementation, the edge intelligent agent (EIA) on the terminal side receives incremental update packets from the cloud-based risk control platform via the operator's private network to update the local rule base (LRR). Simultaneously, for a transaction with a score of 65, the terminal side reports a feature summary to the cloud-based risk control platform. After conducting a global risk assessment, the cloud-based risk control platform determines the transaction to be high-risk, and the terminal side then receives a transaction cancellation instruction from the cloud-based risk control platform to intercept the transaction that has already been initially approved.

[0046] Step S50: The interception log is reported to the operator's backend so that the operator's backend can verify the intercepted transactions based on the interception log and perform fund refund or compensation operations after the verification is successful.

[0047] It should be noted that the operator's back-end refers to the back-end business system of the operator responsible for business management, billing processing and customer complaint response; verification refers to the process by which the operator's back-end verifies whether the intercepted transaction has indeed occurred and whether it meets the compensation conditions based on the interception logs and relevant billing rules; fund return or compensation operation refers to the billing processing action of returning the mistakenly deducted or stolen funds to the user through the billing system after the verification is passed.

[0048] This embodiment achieves closed-loop automation of risk control event handling by opening up the link between the risk control interception and business accounting systems. This ensures that users' financial rights can be restored and compensated in a timely and accurate manner after abnormal transactions are blocked or revoked, thereby improving user experience and reducing the cost of manual customer complaints.

[0049] In one possible implementation, the interception logs can be reported to the operator's backend via an asynchronous push stream through a two-way TLS encrypted channel. When verifying, the operator's backend needs to call the billing system interface to query the bill status corresponding to the transaction ID.

[0050] In one specific implementation, the abnormal transaction interception module ATIM on the terminal side asynchronously reports the interception log containing the transaction ID "TX20231024001" to the operator's backend via an HTTPS channel. After receiving the report, the operator's backend calls the billing system to check if the bill status of the transaction ID is "successful deduction". After verifying that the compensation conditions are met, it automatically generates a refund instruction to execute the fund return operation and refund the funds to the user.

[0051] This application utilizes an edge intelligent agent (EIA) deployed within the secure and trusted execution environment of the Super SIM card to receive and perform real-time risk assessment on multi-source feature data based on a local rule base (LRR). When the score exceeds a threshold, the abnormal transaction interception module (ATIM) proactively blocks the transaction at the NFC link layer. Simultaneously, it collaborates with the cloud-based risk control platform to update rules and rescind transactions afterward. Finally, it reports interception logs to the operator's backend to drive fund return or compensation. This solution leverages the Super SIM card's TEE environment to achieve hardware-level security isolation between data transmission and risk control decisions. Combined with edge computing power, it achieves millisecond-level local real-time interception in offline or weak network environments, effectively preventing the actual deposit of stolen funds. Furthermore, it constructs a dual-layer protection system with end-to-cloud collaboration. This system overcomes the limitations of local computing power through a global cloud perspective, enabling deep circuit breaking and continuous strategy evolution for complex fraud. It also establishes a link between risk control interception and the underlying accounting system by automatically reporting interception logs to the operator's backend. This achieves a complete business security closed loop from risk identification and transaction blocking to fund compensation, effectively protecting users' property rights and significantly reducing the cost of manual customer service complaints.

[0052] Furthermore, referring to Figure 2 This application provides a flowchart of a second embodiment of a real-time risk control and abnormal card swipe interception system based on edge computing, based on the above. Figure 2 The illustrated embodiment further refines the step of "receiving multi-source feature data, which integrates NFC transaction data, GPS location data, accelerometer frequency domain feature data, and surrounding Bluetooth Low Energy device identification data, through the edge intelligent agent EIA when the mobile application detects an NFC transaction trigger," including steps A201 to A204: Step A201: When the mobile application detects a transaction trigger signal from the NFC reader, it reads the transaction ID, transaction amount, and timestamp from the transaction register to generate NFC transaction data.

[0053] It should be noted that the transaction trigger signal refers to the electrical signal or underlying communication command generated by the radio frequency field of the NFC reader when the mobile application is close to the NFC reader, which is used to start the transaction process; the transaction register is a specific storage unit inside the NFC controller chip on the mobile terminal side or in the operating system used to temporarily store the transaction parameters of the current session.

[0054] Step A202: Receive GPS data collected and GeoHash-encoded by the mobile application terminal through the sensor interface, extract frequency domain characteristics of the original data from the accelerometer over a preset time period, and obtain a list of device identifiers obtained by scanning nearby Bluetooth Low Energy devices.

[0055] It should be noted that GeoHash encoding is a geocoding algorithm that converts two-dimensional latitude and longitude coordinates into one-dimensional strings. It can represent spatial location and has spatial proximity characteristics. The raw data refers to the triaxial acceleration value sequence collected by the accelerometer at a fixed sampling rate within a preset time period. The frequency domain feature is a feature vector that reflects the frequency distribution of device motion after processing the raw acceleration data in the time domain using algorithms such as Fast Fourier Transform (FFT). The device identifier list refers to the set of device MAC addresses or unique device identifiers obtained after scanning nearby Bluetooth low-power devices.

[0056] This embodiment aims to construct multi-dimensional contextual features that reflect the user's current real physical environment and motion state, thereby effectively identifying complex fraudulent behaviors such as fake location, emulator card swiping, or unauthorized card swiping in other locations, and greatly improving the environmental perception and anti-counterfeiting capabilities of the risk control model.

[0057] In one specific implementation, after an NFC transaction is triggered, the mobile application concurrently calls the positioning API to obtain the current GPS coordinates (e.g., longitude 116.40, latitude 39.90) and encodes them as "wx4g8d" using the GeoHash algorithm. Simultaneously, it calls the sensor API to read the triaxial raw data sequence output by the accelerometer at a sampling rate of 100Hz within the past second, performs FFT on the sequence, and extracts the amplitude of the first 5 main frequency bands to form a frequency domain feature array. At the same time, it starts Bluetooth scanning for 200 milliseconds to capture the MAC addresses of 3 surrounding Bluetooth Low Energy devices and forms a device identifier list ["AA:BB:CC:00:00:01", "AA:BB:CC:00:00:02", "AA:BB:CC:00:00:03"].

[0058] Step A203: Receive the fused feature data packet generated by the mobile application terminal through serialization of the NFC transaction data, GeoHash encoding, spectrum features, and device identifier list according to a predefined data structure.

[0059] It should be noted that predefined data structures refer to unified templates or format specifications used to organize various heterogeneous data, such as specific binary structures or JSON Schema; serialization refers to the process of converting objects, variables, or data structures in memory into storable or transmittable byte streams or strings; fused feature data packets are composite data blocks containing NFC transaction data, GeoHash encoding, spectral features, and a list of device identifiers, generated after serialization and fusion operations.

[0060] This embodiment aims to eliminate format differences between multi-source heterogeneous data, reduce the parsing complexity of data transmission between processes or devices, reduce communication overhead, and improve the efficiency of loading data into the risk control model.

[0061] In one possible implementation, the predefined data structure can be defined using Protocol Buffers (Protobuf) format, mapping various feature fields to specific types of data tags, thereby achieving efficient binary serialization compression and significantly reducing the size of the fused feature data packet.

[0062] In one specific implementation, the storage format of the fused feature data packet is as follows: { "transactionId": "string", / / NFC unique transaction ID "timestamp": 1625841600, / / Unix second-level timestamp "amount": 250, / / Divided into units "geoHash": "wx4g8d", / / 8-bit GeoHash encoding "deviceFingerprint": "hexstr", / / Device fingerprint SHA-256 "accelPattern": "base64", / / Accelerometer feature summary "bluetoothList": ["mac1","mac2"] / / List of nearby BLE devices }

[0063] Step A204: Receive the fused feature data packet encrypted by the mobile application using a symmetric encryption algorithm.

[0064] It should be noted that symmetric encryption algorithms refer to cryptographic algorithms that use the same key for both encryption and decryption, such as AES (Advanced Encryption Standard) or SM4 (Chinese national cryptographic algorithm). Data transmission occurs between the NFC controller and the main CPU or secure element based on the near-field communication interface provided by the mobile application operating system or hardware level.

[0065] This embodiment aims to prevent multi-source feature data from being maliciously tampered with, eavesdropped on, or replayed on the transmission link between the mobile application operating system and the super SIM card, ensuring the confidentiality and integrity of risk control input data, while utilizing the efficiency of symmetric encryption algorithms to meet the millisecond-level latency requirements of NFC transactions.

[0066] In one possible implementation, the symmetric encryption algorithm can adopt the AES-256-GCM mode, which not only provides data encryption but also provides data integrity verification through the attached authentication tag (TAG). The mobile application and the EIA on the terminal side can perform encryption and decryption operations through a pre-shared security key or a session key derived from the device fingerprint.

[0067] In one specific implementation, the mobile application calls the system's encryption library and uses a 256-bit AES key pre-negotiated with the Super SIM card to perform AES-256-GCM encryption on the generated 150-byte converged feature data packet, generating an encrypted data block containing ciphertext and a 12-byte authentication tag. Subsequently, the mobile application sends the encrypted data block to the EIA on the terminal side via the near-field communication interface in the form of an APDU (Application Protocol Data Unit) instruction. After receiving the instruction, the EIA extracts the encrypted data block and uses the same AES key to decrypt and verify its integrity.

[0068] This application uses a mobile application to read basic transaction parameters and collect multi-dimensional environmental and behavioral characteristics in real time when an NFC transaction is triggered. These multi-source heterogeneous data are then serialized, fused, and encrypted before being transmitted to an edge intelligent agent on the terminal side. This solution constructs a holographic transaction scenario profile by concurrently collecting multi-source data such as GPS geographic location, acceleration frequency domain characteristics, and a list of nearby Bluetooth devices. This significantly improves the ability to identify fraudulent activities such as fake base station attacks, simulator environments, and location spoofing. Simultaneously, the use of serialization fusion and symmetric encryption transmission mechanisms not only ensures the confidentiality and integrity of multi-source feature data during transmission, preventing data leakage and tampering risks, but also meets the stringent millisecond-level response requirements of NFC transactions through efficient data encapsulation.

[0069] In one specific implementation, a user uses a smartphone with a built-in super SIM card to ride the subway. When the phone approaches the card reader area of ​​the turnstile, an NFC transaction trigger signal is generated. The mobile application immediately reads the transaction ID and amount from the NFC transaction register, simultaneously calls the location service to obtain the current latitude and longitude and converts it into an 8-bit GeoHash code "wx4g8d", calls the sensor API to extract the acceleration frequency domain feature summary of the past second, and scans the MAC addresses of five nearby Bluetooth devices. Subsequently, the mobile application packages this NFC transaction data, geographical location information, acceleration mode, and Bluetooth list into a LocalFeature object, encrypts it using the AES-256-GCM algorithm, and quickly transmits it to the edge intelligent agent EIA on the terminal side through the LocalSocket channel. If the abnormal transaction interception module ATIM on the terminal side ultimately determines that the transaction is high-risk and intercepts it, the mobile application will receive the risk control decision result and prompt the user through a front-end UI pop-up window "Transaction suspected of risk, intercepted", and provide an appeal portal.

[0070] Furthermore, referring to Figure 3 This application provides a flowchart of a third embodiment of a real-time risk control and abnormal card swipe interception system based on edge computing, based on the above. Figure 3 The illustrated embodiment further refines the step of "performing a local real-time risk assessment based on the local rule base LRR through the edge intelligent agent EIA to generate a risk score," including steps A301 to A304: Step A301: The edge intelligent agent (EIA) running in the secure and trusted execution environment (TEE) receives and parses the multi-source feature data, reads the current version number from the LRR, and verifies whether the version number is consistent with the latest version issued by the cloud-based risk control platform; if the version is outdated, the risk assessment is suspended and an update is requested.

[0071] It should be noted that the current version number refers to the version identifier currently held by the local rule base, used to record the update and iteration status of the rule set or model parameters; the latest version refers to the rule base version identifier maintained by the cloud-based risk control platform and pushed to the terminal side, possessing the highest timeliness and accuracy; verifying the consistency of version numbers aims to confirm whether the local risk control strategy is in the latest state. Requesting an update refers to sending an instruction to the cloud-based risk control platform to obtain the latest rule base or model parameters.

[0072] In this embodiment, after receiving multi-source feature data, EIA first performs version verification to ensure the validity and timeliness of risk control decision-making basis, prevent misjudgment or missed reporting caused by the use of lagging strategies, and establish an automated strategy synchronization mechanism.

[0073] In addition, during the version verification process, EIA will also check the integrity of the digital signature of the LRR file to ensure that the rule data stored locally has not been illegally tampered with, that is, the signature verification passes and the version number has not expired.

[0074] Step A302: Perform a fast rule check on the current transaction based on the static threshold rules in the LRR. The static threshold rules include a single transaction amount threshold and a card swipe frequency threshold within a unit time window.

[0075] It should be noted that static threshold rules refer to fixed condition judgment logic predefined in the local rule base for rapid filtering; fast rule checking refers to the process of running static threshold rules first to quickly filter obviously high-risk or low-risk transactions before performing complex model calculations; single transaction amount threshold is used to identify abnormally high-amount transactions or test small-amount transactions; card swipe frequency threshold is used to identify continuous fraudulent swipes or high-frequency abnormal operations.

[0076] This embodiment quickly identifies risky transactions with obvious characteristics through logical judgment with low computational cost, significantly reducing the computational load and average response latency on the terminal side.

[0077] In one specific implementation, EIA loads static threshold rules from LRR, which include "single transaction amount threshold = 1000 yuan" and "card swipe frequency threshold per unit time window = 5 times / minute"; EIA parses multi-source feature data, extracts the current transaction amount as 200 yuan, and queries the frequency records in the secure memory, finding that the user has accumulated 6 card swipes in the past minute; EIA determines that the card swipe frequency of this transaction triggers the "5 times / minute" threshold rule and enters the matching process.

[0078] Step A303: If the fast rule check matches any threshold rule, the interception judgment is directly output and a risk score is generated.

[0079] It should be noted that matching any threshold rule means that the characteristic parameters of the current transaction (such as amount and frequency) meet any one or a combination of conditions in the static threshold rule set; generating a risk score means calculating and outputting a quantitative value representing the level of risk based on the type of matching rule or the degree of violation.

[0080] This embodiment aims to implement a "zero-tolerance" immediate blocking strategy for obvious violations, cutting off the risk chain in the shortest possible time and reducing terminal computing resource consumption.

[0081] In one possible implementation, the generated risk score can adopt the preset highest score corresponding to this type of rule. For example, a risk score of 100 points is assigned if the single transaction amount threshold is matched, and a risk score of 95 points is assigned if the frequency threshold is matched, so as to characterize its extremely high risk attribute.

[0082] Step A304: If the fast rule check does not match any threshold rule, then the decision tree model in the LRR is invoked to perform tree-like reasoning based on the multi-source feature data to generate a first risk score.

[0083] It should be noted that the decision tree model is a machine learning model that makes decisions based on a tree structure. It filters input features layer by layer through a series of logical judgment nodes and finally outputs classification or regression results. Multi-source feature data is input into the decision tree model, and tree reasoning is performed according to the branch conditions of the internal nodes of the model (such as "whether the amount is less than X" or "whether the GPS has changed"), and the process is deduced layer by layer until the leaf node is reached. A risk score is used to quantify the initial score of the potential risk of the current transaction.

[0084] This embodiment utilizes machine learning models to conduct in-depth analysis of non-explicit risk transactions, thereby accurately identifying potential fraudulent activities in gray areas that static rules cannot cover, and improving the coverage and accuracy of the risk control system.

[0085] In one possible implementation, the decision tree model can be a lightweight CART classification tree that has undergone quantization pruning to accommodate the limited computing resources and memory space of the SuperSIM card.

[0086] In addition, in this embodiment, the input feature vector of the decision tree model not only includes NFC transaction data, but also integrates the collected GeoHash encoding, acceleration spectrum features and Bluetooth device list. Through cross-validation of multi-dimensional features, it effectively identifies environmental anomalies (such as virtual GPS) and behavioral anomalies (such as abnormal card-holding movement).

[0087] Furthermore, the step of generating a risk score by performing local real-time risk assessment based on the local rule base LRR through the edge intelligent agent EIA also includes A401~A403: Step A401: Determine whether the first risk score is within a preset suspicious score range.

[0088] It should be noted that the preset suspicious rating range refers to a pre-set range of risk scores. This range is neither a clearly defined safe passage range nor a clearly defined high-risk interception range. It represents a gray area where the transaction has a certain possibility of being abnormal and requires further analysis.

[0089] For example, the first risk score output by the EIA is 55 points. The EIA compares this score with the local preset suspicious score range [40, 70] and determines that the transaction is a suspicious transaction, which requires triggering a deep assessment process. If it is not in this range, the EIA will directly generate the final risk score and allow the transaction to proceed.

[0090] Step A402: If the first risk score is within the suspicious score range, then the deep neural network (DNN) model in the LRR is activated, and the multi-source feature data is input into the DNN model for inference to generate a second risk score.

[0091] It should be noted that the Deep Neural Network (DNN) model is a multi-layer feedforward artificial neural network model stored in a local rule base. It includes an input layer, multiple hidden layers, and an output layer, and can capture high-dimensional and complex mapping relationships between multi-source feature data through non-linear activation functions. Inference refers to the process of taking the pre-processed feature vector containing NFC transaction data, GeoHash encoding, spectral features, and a list of device identifiers, and performing matrix multiplication and activation operations on each layer of the DNN model's network nodes in sequence, finally obtaining a probability or score value at the output layer. The second risk score reflects the quantitative value of the deep potential risks of the transaction.

[0092] In this embodiment, when the first risk score is in the suspicious score range, the EIA starts the DNN model for secondary inference. The aim is to use the nonlinear fitting capability of deep neural networks to uncover hidden fraud patterns and weak feature correlations that are difficult for decision tree models to capture, thereby enabling high-precision secondary confirmation of suspicious transactions in the gray area and effectively reducing the false alarm rate and false negative rate of the risk control system.

[0093] In one possible implementation, in order to adapt to the computing power of the Super SIM card, the deep neural network (DNN) model adopts a lightweight network structure that has been pruned and quantized with 8-bit integers. The number of hidden layers can be limited to 3, and the number of neurons in each layer does not exceed 32.

[0094] Step A403: Perform a weighted calculation on the first risk score and the second risk score to generate a risk score.

[0095] It should be noted that weighted calculation refers to the process of mathematically weighting and summing risk scores from different models or rules according to a preset weight ratio.

[0096] This embodiment aims to integrate the advantages of decision tree models in logical rule interpretability and deep neural network (DNN) models in high-dimensional nonlinear feature extraction, to achieve multi-model collaborative decision-making, avoid evaluation bias caused by the limitations of a single model, and thus output more robust, comprehensive and accurate integrated risk assessment results, thereby improving the reliability of decision-making in complex risk control scenarios.

[0097] In one possible implementation, the weights for the weighted calculation are dynamically set based on the historical performance accuracy of the model. For example, the decision tree model, which performs well in the frequency fraud scenario, can be assigned a weight of 0.4, while the DNN model, which has higher accuracy in detecting location anomalies and environmental forgery, can be assigned a weight of 0.6. The calculation formula is: Risk score = First risk score × 0.4 + Second risk score × 0.6.

[0098] This application utilizes the Edge Intelligent Agent (EIA) on the terminal side to perform multi-level local real-time risk assessment within the Super SIM card. This assessment includes rule base version verification, rapid static threshold rule checking, decision tree model tree reasoning, and weighted fusion of deep neural network (DNN) models, generating a final risk score. Through a cascaded mechanism of "rule screening - lightweight model reasoning - deep model verification," this solution ensures both the timeliness and tamper-proof security of the strategy while achieving precise allocation of computing power. This avoids wasting computing resources on explicit risky transactions and effectively uncovers hidden fraud features through multi-model collaborative fusion, significantly improving the robustness, accuracy, and real-time response capability of risk control decisions in complex NFC transaction scenarios.

[0099] Furthermore, the steps of the abnormal transaction interception module ATIM detecting that the risk score reaches a preset interception threshold, actively blocking the current transaction at the NFC transaction link layer, rejecting the NFC command response of the current transaction, physically cutting off the transaction link at the hardware communication layer, and generating an interception log include A501~A504: Step A501: Obtain a risk score through the Abnormal Transaction Interception Module (ATIM) and compare the risk score with a preset high-risk interception threshold.

[0100] Step A502: If the risk score is greater than or equal to the high-risk interception threshold, a blocking command is sent through the NFC transaction link layer of the Super SIM card to reject the NFC command response of the current transaction and physically cut off the transaction link at the underlying hardware communication layer.

[0101] It should be noted that the preset high-risk interception threshold refers to a pre-set critical value used to define the transaction risk as reaching a state that must be immediately and forcibly blocked; the NFC transaction link layer of the Super SIM card refers to the underlying physical and logical channel for radio frequency communication and ISO 14443 protocol interaction between the Super SIM card and the external NFC reader / writer; the blocking command is a control signal or status code generated by ATIM and sent to the underlying communication controller to forcibly terminate the current transaction session; the NFC command response to reject the current transaction is at the NFC communication protocol level, and no longer returns a normal success status word to the Application Protocol Data Unit (APDU) commands such as SELECT or READRECORD sent by the reader / writer, but instead returns an error status word or directly interrupts the radio frequency response.

[0102] In this embodiment, when the risk score reaches the threshold, ATIM sends a blocking command through the NFC transaction link layer to refuse the response. This aims to directly cut off the transaction process from the deepest part of the hardware layer, prevent any malicious software from bypassing risk control decisions at the application layer, and ensure that physical-level fund interception can still be achieved even when an external reader has initiated a deduction request, thereby improving the system's anti-tampering and hard-blocking security capabilities.

[0103] In one possible implementation, the execution of the blocking command can be configured to actively send a DESELECT command to disconnect the link, or configured to directly pull down the level response of the radio frequency signal in the underlying firmware, so that the reader cannot obtain any returned data and thus times out.

[0104] Step A503: Construct a log object, which includes a transaction ID, timestamp, risk score, and the triggered model identifier or rule identifier.

[0105] It should be noted that building a log object refers to the process of instantiating a data structure instance in memory to encapsulate the relevant context information of this intercepted event in a structured manner.

[0106] In addition, in this embodiment, when constructing the log object, ATIM will include not only the above-mentioned basic fields, but also the hardware serial number hash value of the current Super SIM card and the LRR version number to ensure the uniqueness of the interception log subject and the traceability of the policy version.

[0107] Step A504: Write the log object into a circular buffer, encrypt it, store it in the persistent storage medium of the Super SIM card, and report the log object as an interception log to the operator's backend.

[0108] It should be noted that a circular buffer is a first-in-first-out circular data structure used to temporarily cache newly generated log objects within a limited memory space. When the buffer is full, new data will overwrite the oldest data. The persistent storage medium is a non-volatile storage space (such as EEPROM or Flash) inside the Super SIM card that has the characteristic of not losing data when power is off.

[0109] This embodiment helps prevent the loss of critical interception evidence due to system power outages or crashes, ensures the tamper-proof security and permanent traceability of log data, and provides legal and reliable evidence for operators to perform fund return or compensation operations, thus realizing a closed-loop linkage between risk control interception and business compensation.

[0110] In one possible implementation, the encryption algorithm used for persistent storage may be the SM4 block cipher algorithm as stipulated by relevant legal provisions, and the reporting of interception logs can be pushed and transmitted through the carrier's dedicated BIP (Bearer Independent Protocol) channel or HTTPS secure link.

[0111] In one specific implementation, when the user's Super SIM card receives encrypted multi-source feature data from the mobile application, the Edge Intelligent Agent (EIA) decrypts the data using a preset key within the Secure and Trusted Execution Environment (TEE), and loads a decision tree model and a DNN model of version v1.2.3 from the local rule base (LRR). The EIA first uses static rules to check whether the single transaction amount exceeds 500 yuan. If it does not exceed the limit, it further calls the decision tree and DNN models to perform comprehensive reasoning on the multi-source feature data and calculates a final risk score of 85. Since this risk score reaches the preset interception threshold of 80, the Abnormal Transaction Interception Module (ATIM) immediately sends a rejection response command at the NFC transaction link layer, actively blocking the current gate card swipe transaction, and constructs a LogEntry object containing the transaction ID "T20231024001", timestamp, risk score 85, and trigger rule identifier as an interception log, which is encrypted and written to a circular buffer for reporting.

[0112] Furthermore, referring to Figure 4 This application provides a flowchart in the fourth embodiment of the edge computing-based real-time risk control and abnormal card swipe interception system, based on the above. Figure 4 The embodiment shown further includes a global risk collaborative assessment with a cloud-based risk control platform, specifically steps A601-A603: Step A601: If the risk score is within a preset review interval, the multi-source feature data is de-identified to generate a feature summary.

[0113] It should be noted that the preset review interval refers to a pre-defined risk score range between explicit approval and explicit blocking, used to identify boundary-type transactions that require further in-depth analysis in the cloud; de-identification refers to the process of replacing or transforming the original sensitive information using cryptographic methods such as data masking, hash mapping, or truncation to eliminate personal privacy information; feature summary is a lightweight data structure generated after dimensionality reduction, feature extraction, and formatting of the de-identified multi-source feature data, which does not contain plaintext sensitive information but retains key risk control features.

[0114] In one possible implementation, the desensitization process can employ a one-way hash algorithm to perform SHA-256 hashing on the MAC addresses in the device identifier list, and perform grid-based downsizing of the GPS GeoHash encoding (e.g., truncating the 8-bit encoding to 6 bits), thereby providing a regional-level risk control basis while protecting location privacy.

[0115] Step A602: Report the feature summary and risk score to the cloud-based risk control platform so that the cloud-based risk control platform can perform in-depth evaluation based on the global profile data and generate a cloud-based risk assessment result. The global profile data includes a database of users' historical transaction behavior, a database of device fingerprint blacklists, and regional risk heat maps.

[0116] It should be noted that the global profile data is a multi-dimensional data set built by the cloud-based risk control platform based on massive historical data, used to describe the overall risk situation and entity behavior patterns; the user historical transaction behavior database is a time-series database that records the time, amount, frequency, and geographical location of all normal and abnormal transactions of users in the past; the device fingerprint blacklist database is a block list maintained in the cloud that contains known malicious device hardware fingerprints, virtual machine characteristics, or high-risk terminal identifiers; the regional risk heat map is a visualized risk map data based on geospatial information, marking the frequency and density of fraud and theft cases in each region; the in-depth assessment is the process by which the cloud-based risk control platform uses powerful computing power to cross-compare, correlate, and perform complex graph neural network inference with the received feature summaries and risk scores; the cloud-based risk assessment results are used to quantify the final value or level of the overall potential risk of the transaction.

[0117] This embodiment helps to overcome the limitations of the local limited computing power and single perspective of the Super SIM card, and utilizes the global vision and big data capabilities of the cloud to uncover hidden gang fraud and complex black market patterns across terminals, time and regions. This enables accurate secondary analysis of "gray area" transactions that are difficult to determine locally, and significantly improves the coverage depth and accuracy of the overall risk control system.

[0118] In one possible implementation, the deep assessment can employ a graph neural network (GNN) algorithm to perform graph node association queries between the device identifier in the feature summary and the device fingerprint blacklist database. At the same time, it combines the regional risk heat map to perform weighted calculations on the current fraud alarm density of the GeoHash region, and comprehensively generates a cloud-based risk assessment result.

[0119] Additionally, it should be noted that when conducting in-depth assessments, the cloud-based risk control platform will focus on verifying the deviation between the timestamp in the feature summary and the user's usual activity trajectory in the user's historical transaction behavior database. For example, if the user's historical transaction behavior database shows that the user is usually located in location A, but the GeoHash code in the feature summary points to location B, and the device fingerprint appears in the associated network of the device fingerprint blacklist database, the cloud-based risk control platform will quickly raise the cloud-based risk assessment result.

[0120] In one specific implementation, the cloud-based risk control platform receives a feature summary and risk score (65 points) reported by the terminal. It then accesses the user's historical transaction behavior database and finds that the user has never made a transaction in the "wx4g8d" area in the past month. At the same time, the cloud-based risk control platform compares the Bluetooth device hash value in the feature summary with the device fingerprint blacklist database and finds that it highly overlaps with a known fraudulent group's device. Furthermore, the regional risk heat map shows that the area is currently under high-frequency fraud warning. After comprehensive evaluation, the cloud-based risk control platform generates a cloud-based risk assessment result of "90 points" (extremely high risk).

[0121] Step A603: If the cloud risk assessment result exceeds the preset cloud interception threshold, a transaction cancellation instruction is generated.

[0122] It should be noted that the cloud interception threshold refers to the critical value set by the cloud risk control platform to determine that the overall risk assessment result has reached the point where mandatory intervention measures can be taken; the transaction cancellation instruction is a control signal generated by the cloud and sent to the terminal side and the payment core system when the cloud determines that a local transaction that has been released or is pending review has serious risks, and is used to forcibly reverse the account status and fund flow of the transaction.

[0123] This embodiment aims to build a dual insurance mechanism for edge-cloud collaboration, making up for the blind spots of purely local risk control in terms of global perspective, implementing "emergency circuit breaker" for high-risk transactions that cannot be intercepted locally, blocking the loss of funds by forcibly canceling transactions, and ensuring fund security and business closed loop under complex and ever-changing black market attacks.

[0124] In addition, the cloud-based risk control platform can generate a detailed risk tracing report while generating a transaction cancellation instruction. This report includes specific global profile data tags (such as the blacklist database number or heat map area code) that were hit during the in-depth assessment process. The report is then sent out together with the transaction cancellation instruction so that the terminal side can record the interception log for the operator's backend audit.

[0125] This application addresses the issue of terminal-side anonymizing and generating feature summaries from multi-source feature data when the risk score is in the pending review range, and then reporting these summaries. The cloud-based risk control platform then performs in-depth evaluation based on global profile data and generates a transaction cancellation instruction when the result exceeds a threshold. This solution effectively ensures the compliance and security of user privacy data during cloud transmission through the anonymized reporting mechanism. Simultaneously, leveraging the global perspective and complex correlation analysis capabilities of cloud-based big data, it overcomes the limitations of the local computing power and limited viewpoint of the Super SIM card, effectively uncovering hidden cross-regional and cross-device fraud patterns. Furthermore, by constructing a dual insurance mechanism of "local real-time interception + cloud-based post-event circuit breaker" through cloud-based forced cancellation instructions, it significantly reduces the false negative rate and the risk of financial loss in complex risk control scenarios.

[0126] Furthermore, the execution of the transaction cancellation instruction includes A701~A703: Step A701: After receiving the transaction cancellation instruction through the ATIM on the terminal side, verify the digital signature of the transaction cancellation instruction within the TEE.

[0127] It should be noted that verifying a digital signature refers to the cryptographic process of using the public key of the cloud-based risk control platform to decrypt and compare the signature data of a transaction revocation instruction in order to verify the legality of the instruction's source and the integrity of its content.

[0128] In one possible implementation, the digital signature verification can be performed using an asymmetric cryptographic verification mechanism based on the national cryptographic SM2 algorithm. ATIM extracts a pre-set cloud public key from the read-only memory and performs signature verification calculation on the hash digest and signature value of the transaction revocation instruction.

[0129] In one specific implementation, after ATIM receives the transaction revocation instruction issued by the cloud risk control platform through the cellular network channel of the mobile application, it transmits the instruction to TEE. ATIM calls the hardware cryptographic engine inside TEE and uses the preset cloud public key to verify the SM2 digital signature attached to the transaction revocation instruction. If the signature is confirmed to be valid and the content of the instruction has not been tampered with, the rollback operation is allowed.

[0130] Step A702: After the signature verification is successful, a transaction cancellation command is sent through the NFC transaction link layer of the Super SIM card to revert the status of the approved transaction to the incomplete status.

[0131] It should be noted that a "released transaction" refers to an NFC transaction that has passed local real-time risk assessment and been allowed to deduct funds or grant permissions before receiving a revocation instruction from the cloud; an "incomplete status" refers to a transaction record that was originally marked as successful or authorized being rolled back to an initial intermediate status of no deduction or authorization, so that the underlying accounting system no longer confirms the transfer of funds.

[0132] In one possible implementation, the state rollback operation can send an Application Protocol Data Unit (APDU) revocation command to the front-end payment application through the NFC transaction link layer, directly clearing the authorization status flag in the current transaction session context, and simultaneously sending a reversal notification to the payment gateway.

[0133] Step A703: Generate a supplementary interception log based on the ATIM and report it to the operator's backend. The supplementary interception log includes the transaction ID, cloud risk assessment result, and transaction cancellation instruction execution timestamp.

[0134] It should be noted that the interception supplementary log refers to the data record generated by ATIM on the terminal side after the transaction reversal instruction, which is initiated in the cloud, is completed. This log records detailed context information of the subsequent interception and rollback operation.

[0135] In one possible implementation, the interception supplementary logs can be encapsulated in JSON format and reported to the operator's backend via a two-way TLS encrypted channel in an asynchronous push manner.

[0136] In addition, in this embodiment, when the ATIM on the terminal side generates the interception supplementary log, it will simultaneously extract the deep assessment and traceability tags (such as the blacklist database number that was hit) attached when the transaction cancellation instruction was issued by the cloud risk control platform, and write them into the interception supplementary log together, so that the operator's backend can clearly distinguish whether the interception was triggered by local rules or by the cloud global profile.

[0137] Furthermore, the method also includes receiving updated rules and model parameters issued by the cloud-based risk control platform, specifically including steps A801~A802: Step A801: Receive the incremental update package sent by the cloud-based risk control platform. The incremental update package is generated by the cloud-based risk control platform obtaining the latest version of the full rule library and performing binary differential comparison with the current version of the full rule library to generate a difference field. After encryption and digital signature processing, it is sent through the operator's private network channel.

[0138] It should be noted that the latest version of the full rule base refers to the complete data set maintained by the cloud-based risk control platform, which includes all the latest static threshold rules, decision tree model parameters, and deep neural network (DNN) model weights, as well as other risk control strategies; the current version of the full rule base refers to the complete data set currently being used by the local rule base LRR within the terminal's super SIM card, which has not yet been synchronized with the latest risk control strategies; binary differential comparison is the process of comparing two versions of the rule base files bit by bit at the binary byte stream level to identify the operation of adding, deleting, or modifying parts; the difference field is the specific parameter item, threshold value, or model weight data block that has changed during the comparison process; the incremental update package refers to a lightweight data package that only contains the changed difference fields and their offset address information.

[0139] In one possible implementation, binary differential alignment can employ the BsDiff algorithm, which quickly locates the common substrings of the old and new files by constructing a suffix array, generates a difference field consisting of insertion and deletion instructions, and finally packages and compresses it into an incremental update package.

[0140] In one possible implementation, the encryption can use the national standard SM4 symmetric encryption algorithm to encrypt the incremental update packet, while the digital signature processing uses the national standard SM2 asymmetric algorithm to generate the signature value. After both are encapsulated, they are sent out through the operator's BIP (Bearer Independent Protocol) channel or a dedicated APN (Access Point Name) channel.

[0141] In one specific implementation, when the cloud-based risk control platform detects an iteration of the risk control strategy, it obtains the latest version of the full rule base (v2.0) and retrieves the current version of the full rule base (v1.0) reported by the terminal. The cloud-based risk control platform performs a binary differential comparison of the two versions of the file and finds that only the "single transaction amount threshold" has changed from 1000 to 1500, and the weight matrix of the third layer of the DNN model has changed. The cloud-based risk control platform extracts these difference fields and their byte offsets in the file, and encapsulates them to generate an incremental update package of only 20KB in size, which significantly reduces the amount of data transmission compared to the 2MB full rule base.

[0142] Step A802: Decrypt the incremental update package, verify the digital signature, and merge the incremental update package with the locally stored rule base file to update it.

[0143] It should be noted that the merge update precisely overwrites or inserts the difference fields in the verified incremental update package into the corresponding positions in the locally stored rule base file according to the offset address, thus upgrading it to the latest version.

[0144] In one possible implementation, the merge update process can adopt a "dual-zone switching" mechanism, that is, the merging and integrity verification of the difference fields are performed in the standby storage area. After the verification is passed, the primary running pointer is switched to the standby area to prevent the existing rule base from being damaged due to power failure during the update process, which would cause risk control failure.

[0145] This application generates an incremental update package by performing binary differential comparison between the latest version of the full rule base and the current version in the cloud. After encryption and digital signature processing, the package is distributed via a dedicated network channel of the operator. The terminal side decrypts and verifies the signature and merges it with the local rule base file for update. This solution significantly reduces data transmission volume and terminal write time in narrowband environments by extracting difference fields through binary differential processing. By combining encryption and digital signature processing with a dedicated network channel, a high-security transmission barrier is constructed to prevent eavesdropping, tampering, and replay attacks. At the same time, the terminal-side merging update and integrity verification ensure the accuracy and anti-rollback capability of the dynamic iteration of risk control strategies within the Super SIM card. Thus, under the constraints of low power consumption and high security, the continuous evolution and timeliness of the local risk control decision-making system are achieved.

[0146] In one possible implementation, the version verification and disaster recovery of the local rule base LRR includes: the edge intelligent agent EIA reads the version number of the local rule base LRR each time it starts and queries the latest version number from the cloud-based risk control platform; if the latest version number of the cloud-based risk control platform is higher than the version number of the local rule base LRR, the edge intelligent agent EIA initiates an incremental update request to the cloud-based risk control platform; if the edge intelligent agent EIA does not receive a version response or update data from the cloud-based risk control platform within a preset timeout period, it determines that the network is interrupted and maintains the current version of the local rule base LRR to continue providing risk control services; the local rule base LRR retains the rule base files and corresponding model files of the most recent N historical versions, where N≥2; if the current version verification fails or loading is abnormal, the edge intelligent agent EIA automatically reverts to the previous version; after the network is restored, the edge intelligent agent EIA reports the abnormal transaction records intercepted during the network interruption to the cloud-based risk control platform in batches.

[0147] Furthermore, the steps of verifying the intercepted transactions based on the interception logs and performing fund refund or compensation operations after successful verification include A901~A904: Step A901: Based on the operator's backend parsing of the interception logs, extract the transaction ID from the interception logs; Step A902: Call the billing system interface to query the billing status corresponding to the transaction ID; Step A903: If the bill status is "payment successful", a refund instruction is generated according to the preset compensation strategy and sent to the billing system. Step A904: Based on the billing system's response to the refund instruction, execute the operation of returning the funds to the original payment method or recharging the account balance.

[0148] This application extracts transaction IDs from interception logs via the operator's backend, calls the billing system interface to query the corresponding bill status, and generates a refund instruction based on a preset compensation strategy after confirming successful deduction. Finally, the billing system responds and executes either a refund to the original payment method or a recharge of the account balance. This solution achieves precise integration and linkage between risk control interception and the underlying billing system. By verifying the actual bill status, it avoids the risk of discrepancies between the bill and the actual account caused by erroneous refunds. Furthermore, relying on automated compensation strategies and multi-channel refund mechanisms, it ensures that mistakenly deducted or stolen funds can be safely and efficiently returned to users. This effectively protects users' property rights in complex risk control scenarios and constructs a complete business security closed loop from risk identification and interception to fund compensation.

[0149] This application also provides a real-time risk control and abnormal card swipe interception system based on edge computing, the system comprising: On the mobile application side, it is configured to collect and encrypt multi-source feature data, which integrates NFC transaction data, GPS location data, accelerometer frequency domain feature data, and surrounding Bluetooth Low Energy device identification data, and transmit it to the edge smart agent on the terminal side when an NFC transaction is detected; and to receive and display risk control decision results. On the terminal side, deployed within the Super SIM card, it includes an Edge Intelligent Agent (EIA) running within a Secure and Trusted Execution Environment (TEE), a Local Rule Base (LRR), and an Abnormal Transaction Interception Module (ATIM). Upon receiving the multi-source feature data, the EIA performs a local real-time risk assessment based on the LRR to generate a risk score. If the ATIM detects that the risk score reaches a preset interception threshold, it actively blocks the current transaction at the NFC transaction link layer, rejects the NFC command response for the current transaction, physically disconnects the transaction link at the hardware communication layer, and generates an interception log. The cloud-based risk control platform is configured to communicate with the terminal side, send updated rules and model parameters to the terminal side, and receive feature summaries reported by the terminal side for global risk assessment; if the global risk assessment determines that the transaction should be blocked, a transaction cancellation instruction is sent to the terminal side. The operator's backend is configured to receive interception logs from the terminal side, verify the intercepted transactions based on the interception logs, and perform fund refund or compensation operations after successful verification.

[0150] The edge computing-based real-time risk control and abnormal card swipe interception system provided in this application adopts the edge computing-based real-time risk control and abnormal card swipe interception method in the above embodiments. It can solve the technical problems of high network latency and outdated static rules in existing technologies, which prevent the local real-time interception of NFC transactions while ensuring privacy. Compared with the prior art, the beneficial effects of the edge computing-based real-time risk control and abnormal card swipe interception system provided in this application are the same as those of the edge computing-based real-time risk control and abnormal card swipe interception method provided in the above embodiments. Furthermore, other technical features of the edge computing-based real-time risk control and abnormal card swipe interception system are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0151] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the real-time risk control and abnormal card swipe interception system based on edge computing in this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0152] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A real-time risk control and abnormal card swipe interception method based on edge computing, characterized in that, Applied to the terminal side, the terminal side is deployed within a super SIM card and includes an Edge Intelligent Agent (EIA) running within a Secure and Trusted Execution Environment (TEE), a local rule base (LRR), and an abnormal transaction interception module (ATIM); the method includes: The Edge Intelligent Agent (EIA) receives multi-source feature data from the mobile application when it detects an NFC transaction trigger. This data is collected and encrypted and transmitted by the EIA, which integrates NFC transaction data, GPS location data, accelerometer frequency domain feature data, and surrounding Bluetooth Low Energy device identification data. The edge intelligent agent (EIA) performs local real-time risk assessment based on the local rule base (LRR) to generate a risk score. If the abnormal transaction interception module ATIM detects that the risk score has reached the preset interception threshold, it will actively block the current transaction at the NFC transaction link layer, reject the NFC command response of the current transaction, physically cut off the transaction link at the hardware communication layer, and generate an interception log. It communicates with the cloud-based risk control platform, receives updated rules and model parameters from the cloud-based risk control platform, and reports feature summaries to the cloud-based risk control platform for global risk assessment; and receives transaction cancellation instructions issued by the cloud-based risk control platform when the global risk assessment determines that interception is necessary. The interception logs are reported to the operator's backend so that the operator's backend can verify the intercepted transactions based on the interception logs and perform fund refund or compensation operations after the verification is successful.

2. The real-time risk control and abnormal card swipe interception method based on edge computing as described in claim 1, characterized in that, The step of receiving multi-source feature data—which integrates NFC transaction data, GPS location data, accelerometer frequency domain feature data, and surrounding Bluetooth Low Energy device identification data—through the Edge Intelligent Agent (EIA) when the mobile application detects an NFC transaction trigger, includes: When the mobile application detects a transaction trigger signal from the NFC reader, it reads the transaction ID, transaction amount, and timestamp from the transaction register to generate NFC transaction data. Receive GPS data collected and GeoHash encoded by the sensor interface by the mobile application, extract the frequency domain characteristics of the original data of the accelerometer in the past preset period, and obtain the device identifier list obtained by scanning the surrounding Bluetooth Low Energy devices. The mobile application receives a fused feature data packet generated by serializing and fusing the NFC transaction data, GeoHash encoding, spectrum features, and device identifier list according to a predefined data structure. Receive the fused feature data packet encrypted by the mobile application using a symmetric encryption algorithm.

3. The real-time risk control and abnormal card swipe interception method based on edge computing as described in claim 2, characterized in that, The step of generating a risk score by performing local real-time risk assessment based on the local rule base LRR through the edge intelligent agent EIA includes: The edge intelligent agent (EIA) running within a secure and trusted execution environment (TEE) receives and parses the multi-source feature data, reads the current version number from the LRR, and verifies whether the version number is consistent with the latest version issued by the cloud-based risk control platform; if the version is outdated, the risk assessment is suspended and an update is requested. A fast rule check is performed on the current transaction based on the static threshold rules in the LRR. The static threshold rules include a single transaction amount threshold and a card swipe frequency threshold within a unit time window. If the fast rule check matches any threshold rule, the interception decision is directly output and a risk score is generated. If the fast rule check does not match any threshold rule, the decision tree model in the LRR is invoked to perform tree-based reasoning based on the multi-source feature data and generate a first risk score.

4. The real-time risk control and abnormal card swipe interception method based on edge computing as described in claim 3, characterized in that, The step of performing local real-time risk assessment based on the local rule base LRR through the edge intelligent agent EIA to generate a risk score further includes: Determine whether the first risk score falls within a preset suspicious score range; If the first risk score is within the suspicious score range, the deep neural network (DNN) model in the LRR is activated, the multi-source feature data is input into the DNN model for inference, and a second risk score is generated. The first risk score and the second risk score are weighted and calculated to generate a risk score.

5. The real-time risk control and abnormal card swipe interception method based on edge computing as described in claim 1, characterized in that, The steps of the abnormal transaction interception module ATIM detecting that the risk score reaches a preset interception threshold, actively blocking the current transaction at the NFC transaction link layer, rejecting the NFC command response of the current transaction, physically severing the transaction link at the hardware communication layer, and generating an interception log include: The risk score is obtained through the abnormal transaction interception module ATIM, and the risk score is compared with a preset high-risk interception threshold. If the risk score is greater than or equal to the high-risk interception threshold, a blocking command is sent through the NFC transaction link layer of the Super SIM card to reject the NFC command response of the current transaction and physically cut off the transaction link at the underlying hardware communication layer. Construct a log object, which includes a transaction ID, timestamp, risk score, and triggering model identifier or rule identifier; The log object is written to a circular buffer, encrypted, and then stored in the persistent storage medium of the Super SIM card. The log object is then reported to the operator's backend as an interception log.

6. The real-time risk control and abnormal card swipe interception method based on edge computing as described in claim 1, characterized in that, The method also includes conducting a global risk collaborative assessment with a cloud-based risk control platform, specifically including: If the risk score is within a preset review interval, the multi-source feature data is de-identified to generate a feature summary; The feature summary and risk score are reported to the cloud-based risk control platform so that the cloud-based risk control platform can conduct in-depth assessment based on global profile data and generate cloud-based risk assessment results. The global profile data includes a user historical transaction behavior database, a device fingerprint blacklist database, and a regional risk heat map. If the cloud-based risk assessment result exceeds the preset cloud-based interception threshold, a transaction cancellation instruction will be generated.

7. The real-time risk control and abnormal card swipe interception method based on edge computing as described in claim 6, characterized in that, The execution of the transaction cancellation instruction includes: After receiving the transaction cancellation instruction via the ATIM on the terminal side, the digital signature of the transaction cancellation instruction is verified within the TEE. After the signature verification is successful, a transaction cancellation command is sent through the NFC transaction link layer of the Super SIM card to revert the status of the approved transaction to the incomplete status. Based on the ATIM, a supplementary interception log is generated and reported to the operator's backend. The supplementary interception log includes the transaction ID, the cloud risk assessment result, and the timestamp of the transaction cancellation instruction execution.

8. The real-time risk control and abnormal card swipe interception method based on edge computing as described in claim 1, characterized in that, The method also includes receiving updated rules and model parameters from the cloud-based risk control platform, specifically including: The system receives incremental update packages from the cloud-based risk control platform. These packages are generated by the cloud-based risk control platform obtaining the latest version of the full rule library and performing binary differential comparison with the current version of the full rule library to generate a package containing difference fields. The package is then encrypted and digitally signed before being sent through the operator's private network channel. The incremental update package is decrypted, the digital signature is verified, and the incremental update package is merged and updated with the locally stored rule base file.

9. The real-time risk control and abnormal card swipe interception method based on edge computing as described in claim 1, characterized in that, The steps of verifying the intercepted transactions based on the interception logs and performing fund return or compensation operations after successful verification include: Based on parsing the interception logs in the operator's backend, the transaction IDs are extracted from the interception logs; Call the billing system interface to query the billing status corresponding to the transaction ID; If the bill status is "payment successful", a refund instruction will be generated according to the preset compensation strategy and sent to the billing system; Based on the billing system's response to the refund instruction, the funds are either returned to the original payment method or the account balance is recharged.

10. A real-time risk control and abnormal card-swipe interception system based on edge computing, characterized in that, The system includes: On the mobile application side, it is configured to collect and encrypt multi-source feature data, which integrates NFC transaction data, GPS location data, accelerometer frequency domain feature data, and surrounding Bluetooth Low Energy device identification data, and transmit it to the edge smart agent on the terminal side when an NFC transaction is detected; and to receive and display risk control decision results. On the terminal side, deployed within the Super SIM card, it includes an Edge Intelligent Agent (EIA) running within a Secure and Trusted Execution Environment (TEE), a Local Rule Base (LRR), and an Abnormal Transaction Interception Module (ATIM). Upon receiving the multi-source feature data, the EIA performs a local real-time risk assessment based on the LRR to generate a risk score. If the ATIM detects that the risk score reaches a preset interception threshold, it actively blocks the current transaction at the NFC transaction link layer, rejects the NFC command response for the current transaction, physically disconnects the transaction link at the hardware communication layer, and generates an interception log. The cloud-based risk control platform is configured to communicate with the terminal side, send updated rules and model parameters to the terminal side, and receive feature summaries reported by the terminal side for global risk assessment; if the global risk assessment determines that the transaction should be blocked, a transaction cancellation instruction is sent to the terminal side. The operator's backend is configured to receive interception logs from the terminal side, verify the intercepted transactions based on the interception logs, and perform fund refund or compensation operations after successful verification.

Images