A method and system for front-end real-time clustering identification and interception of payment operation violations

Abstract

The application discloses a kind of front end real-time clustering identification and interception of payment operation illegal operation and system, it is related to payment operation risk control and front end intelligent monitoring technical field.Method includes: in the real-time collection of operation personnel's operating behavior data in the front end of payment operation system, construct sliding window operation sequence;Adopt lightweight bidirectional LSTM encoder to extract sequence level feature vector and single operation feature vector, fusion generates comprehensive behavior feature vector;Using DBSCAN clustering as the first layer detection carries out clustering analysis, and noise point is judged as suspected abnormal operation, using isolated forest model as the second layer detection carries out secondary confirmation, whether it is abnormal operation according to abnormal score determination;Comprehensive risk score is calculated, and according to risk score before operation request is sent to rear end, executes pre-interception management and control.The application moves illegal operation prevention and control from "after the event audit" to "before the event intercepts", realizes the closed loop of real-time detection and immediate interception.

Description

Technical Field

[0001] This invention belongs to the field of payment operation risk control and front-end intelligent monitoring technology, specifically involving a method and system for front-end real-time clustering identification and interception of payment operation violations. Background Technology

[0002] In the current payment operation system, the risk control monitoring of the operational behavior of operators mainly adopts the following two technical solutions.

[0003] One approach is operation compliance monitoring based on backend log auditing: Existing payment operation systems typically record operation logs of operational personnel in the business backend, including information such as operation type, operation time, operation object, and operation result. Then, they detect violations by periodically scanning the logs in batches. This method relies on a pre-set compliance rule library (such as "daily refund amount not exceeding 100,000 yuan" and "batch settlement is prohibited outside of working hours") to compare each operation log entry. Once a violation is detected, an alert is generated. This type of method detects abnormal operation behavior by performing multi-dimensional statistical analysis of backend operation logs combined with a pre-set compliance rule library. However, this method is essentially a post-event auditing mechanism, only able to detect and alert after the violation has been completed.

[0004] The shortcomings of this method are: (1) It is a post-event audit mechanism, which can only be discovered after the violation has been completed and recorded in the log, and cannot be intercepted before the operation actually takes effect. For irreversible or difficult-to-roll-back violations (such as large-amount fund transfers, batch merchant rate adjustments), it is impossible to recover the losses after the fact; (2) It only relies on the preset static rule library, and the rule updates are seriously lagging behind the evolution of new violation methods. Operators can avoid rule detection by splitting large-amount operations into multiple small-amount operations, or by performing compliant but abnormal operations during normal hours outside of working hours; (3) It cannot analyze the sequence pattern and context semantics of operation behavior. A single operation log may seem compliant, but the temporal combination of multiple operations may show obvious violation intentions (such as a rapid operation sequence of first increasing the merchant settlement ratio, then triggering batch settlement, and finally restoring the original ratio); (4) The log analysis results rely on manual review and confirmation. In the case of massive operation scenarios, the alarm processing efficiency is low and it is easy to miss real violations.

[0005] Second, there's the role-based access control (RBAC) approach: Some payment operation systems employ this model, configuring different operation permissions for different roles (such as operations specialists, operations supervisors, and risk control auditors), and controlling access at the operation entry point through permission verification. This method intercepts operation requests that are outside the current role's permission scope at the system front-end or gateway layer, preventing unauthorized operations. While this approach controls operational operations by constructing a multi-level role-permission system, it relies solely on a static role-permission mapping relationship and cannot identify unauthorized operations performed by legitimate operational personnel within their authorized scope (such as malicious refunds within legitimate permissions or exploiting permission loopholes for personal gain).

[0006] The shortcomings of this method are: (1) Based on static role-permission mapping, it cannot identify illegal operations within the scope of legal permissions. When an operator has legal permission for a certain operation, all such operations will be allowed, even if the frequency, amount or context of the operation is obviously abnormal; (2) The granularity of permissions is too coarse, and control is only based on roles, and the permission boundaries cannot be dynamically adjusted according to the specific scenario and context of the operation. For example, the same operator should have different operation limits when dealing with high-risk merchants and low-risk merchants, but the RBAC model cannot achieve such fine-grained differentiation; (3) It lacks the ability to model operational behavior patterns and cannot learn from historical behavior data to identify abnormal operation patterns that deviate from the normal behavior distribution; (4) Permission changes require manual approval and management, the response speed is slow, and it cannot adapt to the permission requirements brought about by changes in business scenarios in real time.

[0007] In summary, there is currently no payment operation violation prevention and control solution that can simultaneously achieve real-time violation detection before operation execution, identify abnormal operations within legal permissions, capture multi-step operation sequence combination violation patterns, and adaptively follow the evolution of operation personnel behavior patterns. Summary of the Invention

[0008] To address the shortcomings of the existing technologies, the present invention aims to provide a method for intelligent identification and pre-emptive interception of payment operation violations based on a lightweight front-end behavior clustering model, specifically solving the following five technical problems: (1) Solve the problem that illegal operations can only be audited after the fact and cannot be intercepted in advance: Move the risk control checkpoint from backend log auditing to before the frontend operation request is sent, complete the detection and interception before the illegal operation actually takes effect, and avoid irreversible financial losses; (2) Solve the problem that static rule base cannot identify new violation methods and split avoidance strategies: Automatically discover unknown violation patterns that deviate from the normal behavior distribution through unsupervised behavior clustering model, get rid of the dependence on the preset rule base; (3) Solve the problem of missing contextual semantics in single operation analysis and inability to identify violations of multi-step operation timing combination: capture the timing association and contextual semantics between operations through a sliding window sequence encoder to identify compound sequence violation patterns such as "increase rate → trigger settlement → restore rate"; (4) To solve the problem that access control methods such as RBAC cannot identify "illegal operations within the scope of legal permissions": In addition to access control, risk detection is carried out based on behavioral baselines to upgrade the risk control dimension from "whether the operation is authorized" to "whether the authorized operation is reasonable"; (5) Solve the problem of static model performance degradation due to the evolution of operator behavior patterns: The adaptive evolution of the model is achieved through online incremental clustering and behavior baseline drift detection, so as to detect systemic changes in operation patterns in a timely manner.

[0009] In a first aspect, this invention proposes a method for real-time front-end clustering identification and interception of payment operation violations, the method comprising the following steps: Step S1: Deploy behavior collection probes at the front end of the payment operation system to collect operation behavior data of operators in real time, preprocess the operation behavior data, and generate structured operation behavior records; Step S2: For each operator, maintain a fixed-length sliding window, organize the operations within the window into an operation sequence in chronological order, encode the operation sequence using a lightweight bidirectional LSTM encoder, extract the sequence-level feature vector, and simultaneously extract the single operation feature vector of the current single operation. Step S3: The sequence-level feature vector and the single-operation feature vector are concatenated and fused to generate a comprehensive behavior feature vector. DBSCAN clustering is used as the first layer of detection to perform cluster analysis on the comprehensive behavior feature vector. Noise points that do not fall into any behavior cluster are identified as suspected abnormal operations. The isolated forest model is used as the second layer of detection to confirm the suspected abnormal operations. The abnormality score is used to determine whether the operation is abnormal. Step S4: Calculate the comprehensive risk score for the target operation that was determined to be an abnormal or suspicious operation in step S3; Step S5: Deploy an interception proxy at the request sending layer of the payment operation system front-end to intercept operation requests and execute corresponding pre-control measures based on the comprehensive risk score. The pre-control measures include: when the comprehensive risk score is higher than a first threshold, forcibly intercepting the operation request and generating an approval work order to push to the approval chain; when the comprehensive risk score is higher than a second threshold but not higher than the first threshold, triggering enhanced verification; when the comprehensive risk score is not higher than the second threshold, allowing the operation request.

[0010] Preferably, in step S2: the length N of the sliding window is 20; the bidirectional LSTM encoder is formed by stacking 2 layers of bidirectional LSTM, the hidden state dimension h of each layer is 64, and the total number of parameters is controlled within 50KB; each operation generates a 48-dimensional input vector after preprocessing, including 8-dimensional operation type code, 6-dimensional operation object type code, 1-dimensional normalized amount value, 1-dimensional logarithmic value of operation interval, 1-dimensional normalized value of cumulative operation times on the current day, 1-dimensional normalized value of page stay duration, 3-dimensional time period type code, and 27-dimensional operation parameter feature vector; the hidden state sequence output by the bidirectional LSTM encoder is weighted and summed through an attention pooling mechanism to obtain a 128-dimensional sequence-level feature vector , where is the attention weight of the i-th time step, is the bidirectional LSTM hidden state vector of the i-th time step, and Σ represents summing all N time steps in the sliding window; the single operation feature vector is 32 dimensions, including the operation amount magnitude feature, the operation object risk level feature, and the operation parameter deviation degree feature.

[0011] Preferably, in step S3: the 128-dimensional sequence-level feature vector s and the 32-dimensional single operation feature vector are concatenated, and the dimension is reduced to 64 dimensions through a fully connected layer to obtain a comprehensive behavior feature vector , where ReLU is the rectified linear unit activation function, is the weight matrix of the fully connected layer, is the bias vector of the fully connected layer, represents concatenating the sequence-level feature vector s and the single operation feature vector by dimension; the neighborhood radius ε of the DBSCAN clustering is 2.5, and the minimum number of samples in the cluster MinPts is 8; the number of decision trees T of the isolated forest model is 100, the maximum sample sampling number ψ of each tree is 256, and the maximum tree depth is limited to ; the calculation formula of the anomaly score is , where E[h(f)] is the average path length of the sample f in T trees, and c(ψ) is the normalization constant of the average path length corresponding to the sample number ψ; when AnomalyScore(f)>0.65, it is confirmed as an abnormal operation, when 0.50<AnomalyScore(f)≤0.65, it is marked as a suspicious operation, and when AnomalyScore(f)≤0.50, it is determined as a normal behavior.

[0012] Preferably, in step S4, the calculation formula of the comprehensive risk score is: The weights are configured as W1=0.35, W2=0.25, W3=0.20, and W4=0.20, and the RiskScore ranges from [0,1]; where R... behavior For behavioral deviation risk score, R object Risk classification for the operation object, R temporal For operational timing risk scoring, R intent Risk assessment based on operational intent.

[0013] More preferably, the behavioral deviation risk is divided into: , where d Mahalanobis Let d be the Mahalanobis distance from the operational feature to the nearest cluster center of the behavior. max The 99th quantile of the Mahalanobis distance in historical data; the risk of the operation object is divided into: The merchant risk levels of high, medium, and low are mapped to 1.0, 0.5, and 0.2 respectively, with the amount as the weighting factor. The operation timing risk distribution R temporal The risk score R of the operation intent is calculated based on the anomaly degree of operation frequency, weighted operation during non-working hours, and penalty for short-cycle high-frequency operations. intent Based on the sequence-level feature vector s, the risk probability value of the operation intention is obtained by predicting it through a 2-layer MLP.

[0014] Preferably, in step S5: the first threshold is 0.85; when RiskScore ≥ 0.85, it is determined to be a high-risk operation, triggering forced interception; the second threshold is 0.65; when 0.65 ≤ RiskScore < 0.85, it is determined to be a medium-risk operation, triggering enhanced verification; when 0.45 ≤ RiskScore < 0.65, it is determined to be a low-risk suspicious operation, silently allowed, and enhanced logs are recorded; when RiskScore < 0.45, it is determined to be a normal operation, and normal access is granted; the interception proxy uses global FetchAPI and XMLHttpRequest.pr The `ototype.send` method is rewritten using monkey patching. All outbound operation requests are first checked for risk assessment by the interception proxy. The interception proxy maintains a whitelist of controlled API paths and only performs risk assessment on operation-type interfaces that fall into the whitelist. Query requests and static resource requests are allowed directly. Intercepted requests are temporarily stored in a request suspension buffer. The buffer is a bounded queue with timeout and priority. Each suspension record includes a request identifier, request body snapshot, capture timestamp, assessment status, handling result, and waiting lock. The buffer is set with a suspension timeout. If the assessment is not completed within the timeout period, it is downgraded to allow and asynchronously supplemented with assessment.

[0015] Preferably, in step S3: model quantization technology is used to quantize the DBSCAN and Isolation Forest model parameters from float32 to int8, compressing the total model size to less than 120KB; WebAssembly is used to encapsulate the model inference logic, and clustering inference is performed in the front-end browser, with a single inference latency of less than 3ms; model parameters are updated periodically by the server, and the front-end hot reloads without refreshing the page; inference is performed in an independent Web Worker, and the main thread sends features and receives results via postMessage.

[0016] More preferably, the WebAssembly module is compiled into a binary module by Emscripten, and the JavaScript side interacts with it through the exported linear memory and import / export functions; the model weights are stored in the pre-allocated segment of the WebAssembly linear memory as weight matrices quantized with int8; the JavaScript side writes the 64-dimensional comprehensive behavioral feature vector f into the agreed input offset address as a Float32Array and calls the exported function to trigger inference; inference is executed in an independent WebWorker, and the main thread sends features and receives results through postMessage, with zero blocking of the user interface during the inference process; when the model parameters are updated, the server sends an incremental weight binary stream, and the JavaScript writes it into the corresponding segment of linear memory and refreshes the cluster center cache through the parameter update interface, without needing to rebuild the WebAssembly instance or refresh the page.

[0017] Preferably, the method further includes step S6: collecting follow-up feedback information for each operation risk assessment, including the approval result of the intercepted operation, the follow-up audit conclusion of the operation after enhanced verification, the post-audit conclusion of the normal release operation, and the appeal of the operator regarding the misjudgment result; the DBSCAN clustering model performs incremental clustering updates every 4 hours using the behavioral data of the most recent 7 days; monitors the displacement speed of the center point of each behavioral cluster, and triggers a drift alarm when the displacement distance of the center point of a cluster exceeds twice the standard deviation of the historical average displacement in 3 consecutive update cycles; the isolated forest model is fully retrained once a week using the latest behavioral data, and the model parameters are hot-updated from the server to the front end; maintains a misjudgment sample library, and automatically triggers model parameter tuning when the misjudgment rate exceeds 5%; and automatically creates a personalized behavioral baseline sub-model for specific operators who repeatedly make misjudgments.

[0018] Further preferably, in step S6: a misjudgment sample library is maintained, with the inclusion criteria being operations that have been rejected or intercepted during approval or deemed compliant by post-audit but have been flagged. Each record includes the original feature vector, model label, real label, and feedback timestamp. The misjudgment sample library has a capacity limit and an aging mechanism, with samples older than 90 days having their weight reduced by 50%. When the misjudgment rate exceeds a 5% threshold, a model parameter tuning process is automatically triggered. Based on the recent inflection point of the k-distance graph, the ε parameter of DBSCAN is re-estimated, and the isolated forest anomaly score threshold is adjusted. The misjudgment sample library is used as a validation set to evaluate the tuned false positive rate. After confirming a decrease, a hot update is sent to the front end via the server. For specific operational personnel who repeatedly misjudge, a personalized behavioral baseline sub-model is automatically created.

[0019] Preferably, the operation behavior data in step S1 includes: basic operation information, including operation type, operation timestamp, operation source terminal identifier, and operator identity identifier; operation object information, including the target merchant identifier, merchant risk level, amount involved in the operation, and business scope affected by the operation; operation parameter information, including the specific parameter values ​​of the operation input; operation context information, including the current page path, previous operation sequence, page dwell time, operation interval time, and cumulative number of similar operations on the same day; and operation environment information, including login IP geolocation, device fingerprint information, and login time period attributes.

[0020] Preferably, in step S5: the approval chain automatically selects the approval level based on the operation type and risk level; high-risk operations default to Level 2 approval, including the direct supervisor and risk control manager; when the amount involved exceeds 500,000 yuan or the operation target is a high-risk merchant, it is upgraded to Level 3 approval, with an additional compliance manager added; medium-risk operations default to Level 1 approval, which is the direct supervisor; when the same operator has triggered medium-risk operations 3 or more times in the past 24 hours, it is upgraded to Level 2 approval; the approval chain is linked to the real-time online status of the approver, and when the main approver is offline, it is automatically deferred to the backup approver.

[0021] Secondly, embodiments of the present invention provide a system for front-end real-time clustering identification and interception of payment operation violations, comprising: The front-end behavior collection and preprocessing module is deployed at the front end of the payment operation system. It is used to collect the operation behavior data of the operation personnel in real time and preprocess it to generate structured operation behavior records. The operation sequence encoding and feature extraction module is used to maintain a fixed-length sliding window for each operator, organize the operations within the window into an operation sequence in chronological order, and use a lightweight bidirectional LSTM encoder to encode the operation sequence and extract sequence-level feature vectors and single-operation feature vectors. The lightweight behavior clustering and anomaly detection module is used to concatenate and fuse the sequence-level feature vector and the single operation feature vector to generate a comprehensive behavior feature vector. DBSCAN clustering is used as the first layer of detection for cluster analysis. Noise points that do not fall into any behavior cluster are judged as suspected abnormal operations. The isolated forest model is used as the second layer of detection for secondary confirmation. The anomaly score is used to determine whether it is an abnormal operation. The context-aware risk scoring module is used to calculate a comprehensive risk score for target operations that are determined to be abnormal or suspicious operations. The pre-interception and operation control module is deployed at the request sending layer of the front end of the payment operation system. It is used to intercept operation requests and execute corresponding pre-control measures based on the comprehensive risk score.

[0022] Preferably, it also includes: an online behavior baseline update module, used to update the behavior clustering model and behavior baseline online based on operation feedback data.

[0023] Thirdly, embodiments of the present invention provide an electronic device, including: one or more processors; and a storage device for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement the method described in any implementation of the first aspect.

[0024] Fourthly, embodiments of the present invention provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method as described in any of the implementations of the first aspect.

[0025] Fifthly, embodiments of the present invention provide a computer program product, wherein the computer program product includes a non-transitory computer-readable storage medium storing a computer program operable to cause a computer to perform some or all of the steps described in the first aspect of the present invention. The computer program product may be a software installation package.

[0026] Compared with the prior art, the beneficial effects of the present invention are as follows: (1) Paradigm shift from post-event auditing to pre-event interception: By collaborating with the front-end interception proxy layer and the real-time behavior clustering model, the prevention and control of violations is moved forward to before the operation is executed. Experimental data shows that the pre-event interception rate of violations reaches 95%, which is a fundamental shift in risk control paradigm compared with the traditional post-event auditing method (interception rate of 0% - all are discovered after the fact). The financial losses caused by violations are reduced by about 98%.

[0027] (2) Automatic discovery of unknown violation patterns: The unsupervised behavior clustering model (DBSCAN + isolated forest dual-layer detection) can automatically discover unknown violation patterns that deviate from the normal behavior distribution without the need for pre-defined violation rules. Compared with traditional rule engine methods that can only detect known violation patterns, the recall rate for detecting unknown violation patterns is improved by about 32%. The dual-layer detection strategy effectively reduces the risk of misjudgment by a single model, and the overall false positive rate is controlled at 3.2%.

[0028] (3) Operation Sequence Context Awareness: By capturing the temporal combination patterns between multi-step operations through a sliding window and a bidirectional LSTM sequence encoder, it can identify compound sequence violation patterns that cannot be detected by traditional single operation analysis (such as rapid operation sequences such as "increase rate → trigger settlement → restore rate"). The accuracy of compound sequence violation detection is improved by about 28% compared with traditional methods, and the accuracy of operation intent prediction reaches 87%.

[0029] (4) Identification of violations within legal permissions: By integrating four-dimensional context-aware scoring of behavioral deviation risk, operation object risk, operation timing risk, and operation intent risk, this method overcomes the limitations of traditional RBAC methods that are only based on access control, and effectively detects abnormal operation behaviors within the scope of legal permissions. The violation detection coverage rate within permissions reaches 89%, which is a qualitative leap compared to the traditional RBAC method (violation detection coverage rate within permissions is 0%).

[0030] (5) Adaptive evolution of behavioral baseline: Through online DBSCAN clustering and behavioral baseline drift detection mechanism with incremental updates every 4 hours, the behavioral baseline can adaptively follow the evolution of normal behavioral patterns of operators, with a behavioral baseline update delay of <24 hours. The personalized behavioral baseline sub-model mechanism effectively eliminates interference from individual differences, and the false alarm rate is reduced by 45% compared with the global single model.

[0031] (6) Lightweight front-end deployment: Through model quantization (float32→int8) and WebAssembly encapsulation, the total size of the behavior clustering model is only 120KB, the single inference latency is <3ms, and the end-to-end evaluation pipeline (sequence encoding + cluster detection + risk scoring) is completed within 50ms (42ms in actual testing), which has no impact on the operation experience of operators, while avoiding network latency and privacy risks in the return of operation data to the server. Attached Figure Description

[0032] The accompanying drawings are included to provide a further understanding of the embodiments and are incorporated in and constitute a part of this specification. The drawings illustrate embodiments and, together with the description, serve to explain the principles of the invention. Other embodiments and many anticipated advantages of the embodiments will be readily recognized as they become better understood through reference to the following detailed description. Elements in the drawings are not necessarily to scale. The same reference numerals refer to corresponding similar parts.

[0033] Figure 1 This is a flowchart illustrating a method for real-time clustering identification and interception of payment operation violations as an embodiment of the present invention. Figure 2 This is a flowchart illustrating the overall process of the method of the present invention. Figure 3 This is a schematic diagram of the internal structure of the lightweight behavior clustering and anomaly detection module in this invention; Figure 4 This is a flowchart of the pre-interception and operation control module in this invention; Figure 5 This is an overall architecture diagram of a system for real-time clustering identification and interception of payment operation violations, as an embodiment of the present invention. Detailed Implementation

[0034] The present invention will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and not intended to limit it. Furthermore, it should be noted that, for ease of description, only the parts relevant to the invention are shown in the accompanying drawings.

[0035] It should be noted that, unless otherwise specified, the embodiments and features described in the present invention can be combined with each other. The present invention will now be described in detail with reference to the accompanying drawings and embodiments.

[0036] This invention discloses a method and system for intelligent identification and pre-emptive interception of payment operation violations based on a lightweight behavior clustering model at the front end. Specifically, it relates to a method and system that deploys a lightweight behavior clustering model at the front end of the payment operation system to perform real-time clustering analysis and violation detection on the operation behavior of operators, and to pre-intercept the violation before it is actually executed.

[0037] Table 1 below systematically summarizes the core defects of existing technologies, the corresponding improvement methods of this invention, and the quantitative technical effects: Table 1 In a first aspect, embodiments of the present invention disclose a method for real-time front-end clustering identification and interception of payment operation violations, such as... Figure 1 As shown, the method includes the following steps: Step S1: Deploy behavior collection probes at the front end of the payment operation system to collect operation behavior data of operation personnel in real time, preprocess the operation behavior data, and generate structured operation behavior records; Step S2: For each operator, maintain a fixed-length sliding window, organize the operations within the window into an operation sequence in chronological order, use a lightweight bidirectional LSTM encoder to encode the operation sequence, extract the sequence-level feature vector, and simultaneously extract the single operation feature vector of the current single operation. Step S3: Concatenate and fuse the sequence-level feature vector with the single-operation feature vector to generate a comprehensive behavior feature vector. Use DBSCAN clustering as the first layer of detection to perform cluster analysis on the comprehensive behavior feature vector. Noise points that do not fall into any behavior cluster are identified as suspected abnormal operations. Use the isolated forest model as the second layer of detection to confirm the suspected abnormal operations. Determine whether the operation is abnormal based on the abnormality score. Step S4: Calculate the comprehensive risk score for the target operation that was determined to be an abnormal or suspicious operation in step S3; Step S5: Deploy an interception proxy at the request sending layer of the payment operation system front-end to intercept operation requests and execute corresponding pre-control measures based on the comprehensive risk score. The pre-control measures include: when the comprehensive risk score is higher than the first threshold, forcibly intercept the operation request and generate an approval work order to push to the approval chain; when the comprehensive risk score is higher than the second threshold but not higher than the first threshold, trigger enhanced verification; when the comprehensive risk score is not higher than the second threshold, allow the operation request.

[0038] The following is combined with Figure 2 The overall flowchart shown below provides a detailed explanation of each step of the method of the present invention.

[0039] Step S1: Real-time collection and preprocessing of front-end operation behavior Deploy behavior collection probes on the front-end interface of the payment operation system to collect operational behavior data of operators in real time.

[0040] In one specific implementation, operational behavior data includes the following five categories: (1) Basic Operation Information: This includes operation type (such as refund, rate adjustment, merchant review, fund transfer, etc.), operation timestamp, operation source terminal identifier, and operator identity identifier. The operation type can be predefined according to the business function modules of the payment operation system, and may include, but is not limited to: refund operation, rate adjustment operation, merchant review operation, fund transfer operation, permission change operation, batch settlement operation, etc.

[0041] (2) Operation target information: including the target merchant's identifier, merchant risk level, amount involved in the operation, and scope of business affected by the operation. The merchant risk level can be determined based on a comprehensive assessment of the merchant's historical transaction behavior, complaint records, compliance status, etc., and is usually divided into three levels: high risk, medium risk, and low risk.

[0042] (3) Operation parameter information: including the specific parameter values ​​of the operation input, such as the refund amount, the rate adjustment range, the permission change type, etc.

[0043] (4) Operation context information: including the current page path, the previous operation sequence, the page dwell time, the operation interval time, and the cumulative number of similar operations on the day.

[0044] (5) Operating environment information: including login IP geographical location, device fingerprint information, login time period attributes (working hours / non-working hours / holidays).

[0045] The collected data undergoes preprocessing, specifically including: Fill missing fields with default values ​​or mark them as missing. For example, if an operation does not record the merchant identifier of the operation object, it can be marked as "unknown merchant"; One-hot encoding is performed on the operation type and the type of the operation object to convert categorical data into numerical vectors. Numerical parameters (amount, proportion, etc.) are normalized to quantiles and mapped to the [0,1] interval; Calculate the time interval between the operation timestamp and the previous operation of the same type to generate operation frequency characteristics.

[0046] Step S2: Operation Sequence Encoding and Feature Extraction (a) Construction of sliding window operation sequence: For each operator, maintain a fixed-length sliding window and organize its most recent N=20 operations into an operation sequence in chronological order. Each time a new operation is added, the window slides forward one step, removing the oldest operation record. The choice of a sliding window length N=20 is based on statistical analysis of payment operation behavior. The sequence patterns of most illegal operations can be revealed within 20 steps, and this length can control computational overhead while ensuring detection accuracy. Those skilled in the art will understand that the window length can also be adjusted to other values ​​according to the actual business scenario, such as N=15 or N=25, all of which are within the protection scope of this invention.

[0047] (b) Operation Sequence Encoder: A lightweight bidirectional LSTM (Bi-LSTM) structure is used to encode the operation sequence. LSTM (Long Short-Term Memory) is a special type of recurrent neural network that can effectively capture long-range dependencies in sequence data. By modeling from both the forward and reverse directions of the sequence simultaneously, bidirectional LSTM can capture contextual information more comprehensively.

[0048] The specific parameter configurations are as follows: Number of LSTM layers: Two stacked bidirectional LSTM layers, with a hidden state dimension h=64 in each layer. The stacked structure allows the model to capture behavioral patterns at different time scales. The first layer captures local temporal features, and the second layer captures higher-level semantic features based on these features.

[0049] Input representation: Each operation After preprocessing, a The input vector is dimensional, and its structure is shown in Table 2.

[0050] Table 2 Attention Pooling Layer: An attention pooling mechanism is applied to the 2N-dimensional (bidirectionally concatenated) hidden state sequence output by the Bi-LSTM. The core idea of ​​the attention mechanism is to allow the model to automatically learn the importance weights of each time step in the sequence, thereby focusing on the most critical operation steps for the current detection task. Specifically, the attention weights for each time step are calculated. Then, the sequence-level feature vectors are obtained by weighted summation. ,in, Let be the attention weights at the i-th time step. Let Σ be the bidirectional LSTM hidden state vector at the i-th time step, and let Σ represent the summation over all N time steps within the sliding window.

[0051] The encoder's total parameter size is kept below 50KB, making it suitable for deployment in front-end browser environments. To achieve this parameter size control, this invention employs model compression techniques such as parameter sharing and low-rank decomposition.

[0052] (c) Single Operation Feature Extraction: Simultaneously extract an independent feature vector for the current single operation, including features such as the magnitude of the operation amount, the risk level of the operation target, and the deviation of the operation parameters (the degree of deviation from the average parameter value of similar historical operations), to generate a single operation feature vector. .

[0053] Step S3: Lightweight Behavioral Clustering and Anomaly Detection like Figure 3As shown, this step employs a two-layer anomaly detection strategy that combines DBSCAN with isolated forest.

[0054] (a) Construction of behavioral feature space: combining the sequence-level feature vector s (128 dimensions) with the single-operation feature vector (32-dimensional) concatenation, followed by a fully connected layer to reduce the dimensionality to 64-dimensional, yields the comprehensive behavioral feature vector. Where ReLU is the modified linear unit activation function. Here is the weight matrix of the fully connected layer. This is the bias vector of the fully connected layer. This indicates that the sequence-level feature vector s is compared with the single-operation feature vector. Concatenated dimensionally. This fully connected layer has approximately 8KB of parameters. The ReLU activation function (Rectified Linear Unit) is defined as follows: Its calculation is simple and can effectively alleviate the gradient vanishing problem.

[0055] (b) DBSCAN online clustering (first-level detection): DBSCAN (Density-Based Spatial Clustering of Applications with Noise) is a classic density clustering algorithm. Its core idea is that in the feature space, sample points belonging to the same cluster are close to each other (density connected), while noise points are located in low-density areas.

[0056] Online DBSCAN clustering was performed on the comprehensive behavioral feature vector f of all operations personnel. The clustering parameters were set as follows: neighborhood radius ε = 2.5 (determined based on inflection point analysis of the k-distance graph of historical data), and minimum number of samples within a cluster MinPts = 8. The method for selecting the ε parameter was as follows: calculate the distance (k = MinPts) from each sample to its k-th nearest neighbor for historical behavioral data, plot the k-distance graph, and select the distance value at the inflection point of the curve as ε. The choice of MinPts = 8 was based on statistical analysis of the size of the operations personnel group; a behavioral cluster is considered statistically significant only when it contains at least 8 samples.

[0057] The clustering results are divided into three categories: Core cluster in-point: A normal operation belonging to a certain behavior cluster, whose feature vector is within the range of ε from the center of its cluster; Boundary points: located at the edge of behavioral clusters, possibly representing operations during the transition period of behavioral patterns. Their feature vectors are close to ε from the center of their respective clusters, but still within the range. Noise point: does not belong to any behavior cluster and is judged as a suspected abnormal operation.

[0058] Noise point determination rule: If the distance from the comprehensive behavior feature vector f of a certain operation to its MinPts-th nearest neighbor is greater than ε, it is determined as a DBSCAN noise point, and enters the second-layer detection for confirmation.

[0059] The clustering model is incrementally updated every 4 hours, and adopts a sliding window mode to perform clustering using only the behavior data of the latest 7 days, so as to ensure the adaptability of the model to the evolution of behavior patterns. The specific method of incremental update is: after new behavior data is accumulated, DBSCAN clustering is re-executed with all the behavior data of the latest 7 days, instead of performing incremental modification on the original clustering results, so as to ensure the global consistency of the clustering results.

[0060] (c) Isolation Forest confirmation detection (second-layer detection): For the noise points output by DBSCAN, the Isolation Forest model is used for secondary confirmation to avoid misjudgment of boundary behaviors by DBSCAN.

[0061] Isolation Forest is an anomaly detection algorithm based on ensemble learning. Its core idea is: anomaly points are more likely to be isolated in the feature space (that is, they can be isolated with fewer random partitions), so the average path length of anomaly points in the Isolation Forest is shorter. Compared with other anomaly detection algorithms, Isolation Forest has the advantages of linear time complexity, being applicable to high-dimensional data, and no need to calculate distance or density.

[0062] Isolation Forest parameter configuration: Number of decision trees T=100: Each decision tree randomly selects features and split points during training, and 100 trees can achieve a good balance between detection accuracy and computational efficiency; Maximum sample sampling number ψ=256 for each tree: 256 samples are randomly sampled from the training set to construct each decision tree, and this value controls the computational overhead while ensuring the diversity of tree structures; Maximum tree depth is limited to : Limit the growth depth of the tree to avoid overfitting.

[0063] Anomaly score calculation: , where E[h(f)] is the average path length of sample f in T trees, and c(ψ) is the average path length normalization constant corresponding to the sample number ψ.

[0064] Determination rule: When AnomalyScore(f)>0.65, it is confirmed as an abnormal operation, and the risk scoring process is triggered; When 0.50<AnomalyScore(f) ≤0.65, it is marked as "suspicious operation" and enters the observation queue; When AnomalyScore(f) ≤ 0.50, it is considered normal behavior and the operation is released.

[0065] (d) Lightweight deployment optimization: Model quantization was used to quantize the parameters of DBSCAN and Isolation Forest models from float32 to int8. The specific method of model quantization is as follows: for each weight matrix in the model, its numerical range is calculated, the floating-point numbers are linearly mapped to the integer range of -128 to 127, and the quantization scaling factor is recorded. After quantization, the total model size is compressed to less than 120KB.

[0066] WebAssembly (Wasm) is used to encapsulate the model inference logic, enabling clustering inference to be performed in the front-end browser with native performance, achieving a single inference latency of <3ms. WebAssembly is a low-level assembly-like language that can run at near-native speed in the browser and offers more stable performance compared to JavaScript.

[0067] Model parameters are updated periodically via server-side updates, and front-end hot reloading eliminates the need to refresh the page.

[0068] (e) Wasm-JS Interface Protocol and Calling Conventions: The model is compiled into a WebAssembly binary module using Emscripten. Emscripten is an LLVM to JavaScript compiler that can compile C / C++ code into WebAssembly.

[0069] On the JavaScript side, interaction with the exported linear memory (WebAssembly.Memory) is achieved through import / export functions, with the specific protocol as follows: Memory layout: Model weights are stored in a pre-allocated segment of Wasm linear memory as int8 quantized weight matrices; On the JavaScript side, the 64-dimensional comprehensive behavioral feature vector f is written as a Float32Array to the agreed input offset address input_ptr, and the exported function infer(input_ptr, len) is called to trigger an inference.

[0070] Data interaction: JavaScript and Wasm only exchange numerical data using TypedArray (Float32Array / Int8Array), avoiding the overhead of JSON serialization and structured cloning. The data transfer overhead for a single inference is <0.1ms. The inference output (exception labels and AnomalyScore) is read back by JavaScript via out_ptr.

[0071] Threading Model: Inference is performed in a separate Web Worker. The main thread sends features and receives results via postMessage, ensuring zero blocking of the user interface during the inference process. Web Workers are APIs defined in the HTML5 standard for executing JavaScript in background threads, preventing long-running tasks from blocking the main thread's UI rendering and interactive responses.

[0072] Hot reloading: When model parameters are updated, the server sends incremental weights (int8 binary stream), and JavaScript writes them to the corresponding segment of linear memory and refreshes the cluster center cache via the update_params(ptr, len) interface, without having to rebuild the Wasm instance or refresh the page.

[0073] Step S4: Context-Aware Risk Scoring For operations identified as abnormal or suspicious in step S3, a comprehensive risk score is performed. For example... Figure 2 As shown, this step is performed after cluster detection and before pre-interception.

[0074] (a) Extraction of multidimensional risk factors: Behavior deviation risk score R_behavior: Calculated based on the AnomalyScore (isolated forest anomaly score) and the Mahalanobis distance d_Mahalanobis from the operational feature to the nearest behavior cluster center. Mahalanobis distance is a distance metric that considers the correlation between features. Compared to Euclidean distance, Mahalanobis distance more accurately measures the degree of deviation between a sample and the distribution. The calculation formula is: Where d_max is the 99th quantile of Mahalanobis distance in historical data. The weights of 0.6 and 0.4 are determined based on statistical analysis of the predictive power of the two types of indicators. The isolated forest anomaly score is more sensitive to point anomalies, while Mahalanobis distance is more sensitive to distribution shifts; the two are complementary.

[0075] Risk score R_object for the operation object: calculated based on the attributes of the operation object. Merchant risk levels (high / medium / low) are mapped to 1.0 / 0.5 / 0.2 respectively, with the amount of money as the weighting factor. The correlation of historical violations by the target merchant is calculated based on a comprehensive assessment of factors such as whether the merchant has been involved in any violations in the past and the number of violations.

[0076] Operational timing risk score R_temporal: Calculated based on operation sequence characteristics, including operation frequency anomaly (current operation frequency / historical average frequency), non-working period operation weighting (non-working period × 1.5, holidays × 1.8), and short-cycle high-frequency operation penalty (add 0.3 if the number of similar operations in the last 10 minutes is > 5).

[0077] Operational intent risk score R_intent: Based on the sequence-level features s output by the sequence encoder, the risk probability value of the operational intent is predicted through a 2-layer MLP (32-dimensional hidden layer, 1-dimensional output layer, sigmoid activation). MLP (Multilayer Perceptron) is a feedforward neural network that can learn complex mapping relationships between features through multiple nonlinear transformations.

[0078] (b) Calculation of comprehensive risk score: The weights are configured as follows: W1=0.35, W2=0.25, W3=0.20, and W4=0.20. This weight configuration is based on statistical analysis of historical violation samples and is determined through weight learning methods such as logistic regression. Behavioral deviation risk has the strongest predictive ability for violations and is therefore assigned the highest weight; the risk of the operation target is next; time-series risk and intention risk are used as auxiliary discriminant factors. The weights can be dynamically adjusted through online learning. The RiskScore ranges from [0,1], with a higher value indicating a higher risk.

[0079] (c) Risk level classification and response strategy mapping: RiskScore≥0.85: Determined as "high-risk operation", triggering mandatory interception, operation is suspended and pushed to the superior for approval; 0.65≤RiskScore<0.85: Determined as "medium risk operation", triggering enhanced verification (requiring secondary identity authentication or SMS verification code confirmation). After verification, the operation is allowed but marked as a watchful operation. 0.45≤RiskScore<0.65: Determined as "low-risk suspicious operation", allowed silently but recorded in enhanced logs, and included in subsequent audit focus; RiskScore < 0.45: Determined as "normal operation", and released normally.

[0080] The above four thresholds are set based on statistical analysis of risk score distribution and historical violation labels. The optimal classification thresholds are determined through ROC curve analysis, which ensures both detection recall and control of false positive rate.

[0081] Step S5: Pre-emptive interception and operation control like Figure 4 As shown, this step achieves pre-control of operation requests through a front-end interception proxy layer.

[0082] (a) Front-end interception proxy layer: Deploy an interception proxy at the request sending layer of the front end of the operation system. All operation requests must undergo risk assessment and check by the interception proxy before being sent to the backend API.

[0083] The specific mechanism is as follows: After the interceptor proxy intercepts the operation request, it temporarily suspends the request (places it in the front-end request queue buffer) and triggers the real-time evaluation pipeline in steps S2-S4. The evaluation pipeline completes all calculations (sequence encoding + cluster detection + risk scoring) within 50ms and returns the decision-making information. If the decision to handle the situation is "forced interception", the interception agent will directly block the request from being sent, and the front-end interface will pop up an interception prompt box, displaying a summary of the risk reasons and an appeal / approval entry point; If the decision is to "enhance verification", the interceptor will pop up a secondary verification interface. After successful verification, the verification token will be attached to the request header and then sent to the backend. If the decision is "normal release", the intercepting agent will immediately release the request without the operators' knowledge.

[0084] (a-1) Specific implementation of front-end interception proxy: At the application entry point, the global `fetch` and `XMLHttpRequest.prototype.send` methods are rewritten using monkey patching, ensuring that all outbound requests undergo risk assessment checks by the intercepting proxy first. Monkey patching is a technique that dynamically modifies object behavior at runtime; in this invention, it is used to inject risk control interception logic without modifying the original business logic.

[0085] For some low-level requests that cannot be overridden at the application layer, the fetch event of the Service Worker is used as a fallback interception layer. The Service Worker is an independent thread running in the background of the browser that can intercept and process network requests and continue to run even if the page is closed.

[0086] The interception proxy maintains a "whitelist of controlled API paths," and only performs risk assessments on operation-type interfaces (such as refunds, rate adjustments, and fund transfers) that fall into the whitelist. Query-type and static resource requests are allowed directly to avoid unnecessary performance overhead.

[0087] (a-2) Data structure and management mechanism of operation suspension buffer: Intercepted requests are temporarily stored in a "request suspension buffer," whose data structure is a bounded queue (circular buffer + hash index) with timeout and priority. The circular buffer is a fixed-size circular queue that can efficiently implement FIFO (first-in, first-out) data management; the hash index is used to quickly find a specific suspended record by requestId.

[0088] Each pending record includes: requestId (unique identifier of the request), request body snapshot (for subsequent replay), capture timestamp, evaluation status (PENDING / SCORING / DECIDED), disposal result, and waiting lock.

[0089] The buffer is set to suspend timeout (default 80ms, greater than the 50ms limit of the evaluation pipeline); if the evaluation is not completed within the timeout period, it will be downgraded to "allow and asynchronously supplement the evaluation" to avoid blocking business continuity. The buffer capacity limit (default 1024 entries) is used in conjunction with LRU eviction to prevent memory overflow.

[0090] (b) Operation suspension and approval process: Intercepted operation requests generate approval work orders, which include operation details, risk scores, risk factor analysis, operation sequence context, and other information, and are pushed to the preset approval chain.

[0091] The approval process automatically selects the approval level based on the operation type and risk level: high-risk operations require at least two levels of approval (direct supervisor + risk control manager), while medium-risk operations require only one level of approval (direct supervisor).

[0092] Once approved, the operation request is automatically resent to the backend for execution; if rejected, the operation is canceled and the violation is recorded.

[0093] (b-1) Rules for automatically generating approval work orders: When the handling decision is "forced interception", the interception agent triggers the work order generator to automatically fill in the following fields: operation request summary (type / object / amount / time), RiskScore and values ​​of each risk factor, operation sequence context snapshot, hit cluster labels and risk rules, and system suggested approval level; the work order is written to the work order queue as a structured object and pushed to the corresponding approver's terminal via the message bus (WebSocket / message queue).

[0094] (b-2) Dynamic selection logic of the approval chain: The approval level is dynamically selected based on a three-dimensional decision matrix of "risk level × operation amount × risk level of the operation target," rather than a fixed level. Specifically: High-risk operations are approved at Level 2 by default (direct supervisor + risk control manager), but when the amount involved is greater than 500,000 yuan or the target of the operation is a high-risk merchant, it is upgraded to Level 3 (adding a compliance manager). Medium-risk operations are approved at Level 1 (direct supervisor) by default, but will be upgraded to Level 2 if the same operations staff has triggered ≥3 medium-risk operations within the past 24 hours. The approval process is linked to the real-time online status of the approver. If the primary approver is offline, the approval will automatically be delegated to the backup approver to ensure the processing SLA (Service Level Agreement).

[0095] (c) Emergency Operation Whitelist Mechanism: For pre-defined emergency operation types (such as system failure emergency response), provided that the identity verification of the operation personnel is verified, the operation can be executed first and audited afterwards, so as to avoid the impact of the interception mechanism on the efficiency of emergency response.

[0096] Step S6: Online Update and Feedback Optimization of Behavioral Baselines (a) Collection of operational feedback: Collect follow-up feedback information for each operation risk assessment, including: the approval result of the blocked operation (approval / rejection); the follow-up audit conclusion of the operation after enhanced verification (compliance / violation); the post-audit conclusion of the operation that is released normally (whether there is any omission); and the subjective feedback of the operations personnel on the assessment results (appeals for misjudgment).

[0097] (b) Adaptive update of behavioral baseline: For the DBSCAN clustering model, incremental clustering updates are performed every 4 hours using the behavioral data from the most recent 7 days. Newly emerging normal behavioral patterns automatically form new behavioral clusters, and the behavioral baseline adaptively drifts as the work patterns of operations personnel change.

[0098] Drift detection mechanism: Monitor the displacement speed of the center point of each behavior cluster. When the displacement distance of the center point of a cluster exceeds twice the standard deviation of the historical average displacement within 3 consecutive update cycles, a drift alarm is triggered, indicating that there may be a systemic change in the operation mode (such as business process adjustment, new function launch, etc.).

[0099] For the isolated forest model, it is fully retrained once a week using the latest behavioral data, and the model parameters are hot-updated by sending them from the server to the front end.

[0100] (c) Misclassification rate control and model optimization: Maintain a misjudgment sample library. The entry conditions are "rejected and intercepted after approval" or "subsequent audit determined to be compliant but was previously marked". Each record includes the original feature vector, model label, real label and feedback timestamp. The sample library has a capacity limit (default 5000 records) and an aging mechanism (samples older than 90 days have their weights reduced by 50%) to prevent old samples from interfering with optimization.

[0101] When the false positive rate (number of false positive operations / total number of labeled operations) exceeds the 5% threshold, the model parameter tuning process is automatically triggered: the ε parameter of DBSCAN is re-estimated based on the recent inflection point of the k-distance graph, the outlier score threshold of the isolated forest is adjusted, and the false positive rate after tuning is evaluated using the false positive sample library as the validation set. After confirming the decrease, the front-end is hot-updated by the server.

[0102] For specific operational personnel who repeatedly make misjudgments, a personalized behavioral baseline sub-model is automatically created for them to reduce misjudgments caused by individual behavioral differences. The method for creating the personalized sub-model is as follows: using the operational personnel's historical behavioral data (containing at least 50 operations) as the training set, DBSCAN clustering is performed independently to form a behavioral cluster unique to that operational personnel; subsequent operations of that operational personnel are first compared with their personalized sub-model, and only when the personalized sub-model cannot make a judgment will it fall back to the global model.

[0103] The technical solution of the present invention will be further illustrated below through several specific application examples.

[0104] Example 1: Pre-emptive interception of malicious bulk refund operations Scenario Description: An operations specialist (role: refund reviewer, with approval authority for single refunds up to 50,000 yuan) performs a series of refund operations during working hours.

[0105] Behavior Acquisition and Sequence Encoding: 14:01 — Initiated a refund of 2,800 yuan to Merchant A (Operation interval: 35 minutes since the last operation, normal); 14:03 — Initiated a refund of 3,200 yuan to Merchant B (operation interval: 2 minutes, relatively fast); 14:04 — Initiated a refund of 4,500 yuan to merchant C (operation interval: 1 minute); 14:05 — Initiated a refund of 4,800 yuan to merchant D (operation interval: 1 minute); 14:06 - Initiated a refund of 4,900 yuan to merchant E (operation interval: 1 minute, close to the single transaction limit). 14:07 - Initiated a refund of 4,950 yuan to merchant F (operation interval: 1 minute, close to the single transaction limit).

[0106] The sequence characteristics captured by the sliding window sequence encoder (Bi-LSTM) are as follows: there are 6 refund operations in the past 10 minutes, the operation interval drops sharply from 35 minutes to 1 minute, and the amount of each transaction gradually approaches the 50,000 yuan limit (2800→3200→4500→4800→4900→4950). The operation targets are all different merchants (dispersed refunds), showing a clear "split avoidance + rapid continuous issuance" pattern.

[0107] Behavioral clustering detection results: DBSCAN Layer 1: The Mahalanobis distance d_Mahalanobis from the comprehensive behavioral feature vector f to the nearest behavioral cluster center is 4.8 (the average distance for normal operating clusters is 1.2). If it exceeds ε=2.5, it is judged as a noise point. The second layer of the isolated forest shows that AnomalyScore(f) = 0.78 > 0.65, indicating an abnormal operation.

[0108] Risk score calculation: R_behavior=0.6×0.78+0.4×min(4.8 / 5.0, 1.0)=0.468+0.384=0.852; R_object = Merchant risk level mapping (all low risk 0.2) + w_amount × amount normalization (0.8 × 4950 / 50000 = 0.079) + historical violation correlation of the operation object (0.14) = 0.20 + 0.079 + 0.14 = 0.419 ≈ 0.42; R_temporal = Frequency anomaly (6 times / 10 minutes ÷ historical average 2 times / 10 minutes = 3.0) × 0.5 + Normal working hours (×1.0) + Short-cycle high frequency penalty (>5 times, +0.3) = 1.5 + 0.3 = 1.8, normalized to 0.72; R_intent=0.91 (The sequence encoder's predicted operational intent is highly suspicious). RiskScore=0.35×0.852+0.25×0.42+0.20×0.72+0.20×0.91=0.298+0.105+0.144+0.182=0.729.

[0109] Interception and Handling: RiskScore = 0.729, falling into the medium-risk range [0.65, 0.85), triggering enhanced verification. A two-factor authentication interface pops up on the front end, requiring the operations specialist to confirm via SMS verification code. After successful verification, the operation is allowed but marked as a monitored operation. The system simultaneously generates an audit report and pushes it to the direct supervisor, noting that "this operation sequence exhibits a split-and-avoidance pattern, with the amounts of the 6 refunds gradually approaching the limit and the intervals between operations being abnormally close." Subsequent supervisor review, based on the characteristics of this sequence, confirmed it as a violation and initiated an investigation process.

[0110] Example 2: Identification of transactions involving the transfer of benefits within the scope of legal authority Scenario Description: A senior operations manager (role: operations manager, with the authority to adjust merchant rates, range of 0.1%-3%) performs a rate adjustment operation on a long-term partner merchant.

[0111] Behavior Acquisition and Sequence Encoding: 10:15 — The settlement fee rate for merchant G will be reduced from 0.6% to 0.35% (a decrease of 42%). 10:18 - A large transaction (amounting to 850,000 yuan) was triggered for merchant G. 10:22 — Restore merchant G's settlement fee rate to 0.6%.

[0112] The operation sequence encoder captured the key timing pattern: "rate reduction → trigger settlement → rate restoration," with the three steps completed within 7 minutes, forming a complete profit-sharing operation loop. The entire operation was within the legitimate authority of the operations manager, which would have been allowed by traditional RBAC methods.

[0113] Behavioral clustering detection results: DBSCAN Layer 1: The distance from the comprehensive behavioral feature vector of this operation sequence to the center of the nearest behavioral cluster is 3.1 > ε = 2.5, and it is determined to be a noise point; The second layer of the isolated forest shows that AnomalyScore(f) = 0.72 > 0.65, indicating an abnormal operation.

[0114] Risk score calculation: R_behavior = 0.6 × 0.72 + 0.4 × min(3.1 / 5.0, 1.0) = 0.432 + 0.248 = 0.680; R_object = Merchant G's risk level is "medium" (mapping 0.5) × 0.3 + Amount involved is 850,000 yuan (normalized 0.85) × 0.8 × 0.7 = 0.15 + 0.476 = 0.626; R_temporal = Normal frequency (×1.0) + Working period (×1.0) + Short cycle operation association (3 steps / 7 minutes, +0.2) = 1.2, normalized to 0.45; R_intent=0.88 (The “reduction rate → settlement → recovery” pattern is highly valued by the sequence encoder). RiskScore=0.35×0.680+0.25×0.626+0.20×0.45+0.20×0.88=0.238+0.157+0.090+0.176=0.661.

[0115] Interception and Handling: RiskScore = 0.661, falling into the medium-risk range [0.65, 0.85), triggering enhanced verification. The system pops up a secondary verification interface requiring confirmation, and simultaneously notes the risk reason in the operation details: "Detected a short-cycle operation sequence of rate adjustment → large-amount settlement → rate restoration, highly similar to historical benefit transfer patterns." After the operation verification is passed, it is allowed but marked as a watchful operation, and the audit report is simultaneously pushed to the risk control manager. Subsequent investigation confirmed that the operation was indeed a benefit transfer behavior, demonstrating the invention's ability to identify "violations within legal authority."

[0116] Example 3: Accurate release of operations during normal peak business hours Scenario description: During the "Double Eleven" promotion, an operations specialist processed a large number of merchant refund requests, with a significantly higher processing frequency than usual.

[0117] Behavior Acquisition and Sequence Encoding: A total of 120 refunds were processed that day (compared to an average of 15 per day), with 32 refunds processed in the last hour. The median refund amount per transaction was 1,200 yuan, and the maximum was 3,800 yuan, indicating a normal distribution. The average interval between operations is about 2 minutes (usually about 12 minutes). All refund operations have corresponding refund application tickets, and the affected merchants are evenly distributed.

[0118] Behavioral clustering detection results: DBSCAN Layer 1: Although the operation frequency is significantly higher than usual, the system has absorbed the changes in the operation frequency of all operations personnel during the "Double Eleven" promotion through incremental clustering updates 3 days before the promotion, forming a new behavior cluster of "high-frequency operations during the promotion". The operation feature vector is located in the new cluster and is judged as normal operation. The operation is allowed to proceed directly without needing to enter the second layer of the isolated forest for detection.

[0119] Behavioral baseline drift detection: The system detected that the cluster center displacement velocity in the "Refund Operation Frequency" dimension exceeded twice the standard deviation of the historical average for two consecutive days, triggering a drift alarm. The operations team confirmed that this was a normal pattern change caused by the "Double Eleven" business peak, marked the drift as "Known Business Cause," and the system automatically adjusted the detection sensitivity for this dimension.

[0120] Final result: During the promotional period, the daily refund processing volume increased by 8 times, but the system's false alarm rate was only 2.1%, effectively avoiding unnecessary blocking of normal high-frequency operations and ensuring operational efficiency during the promotional period.

[0121] Example 4: Correction of False Positives Regarding Personalized Behavioral Patterns of New Employees Scenario Description: A newly hired operations specialist (role: refund auditor, 3rd day on the job) was initially flagged as suspicious by the model because he was not yet familiar with the business and his operating rhythm differed significantly from the overall behavioral baseline.

[0122] Behavior Acquisition and Sequence Encoding: Operations staff: Specialist X, 3 days on the job, has completed job authorization training, and has the authority to process refunds up to 50,000 yuan per transaction; Operational characteristics: Single refund amount is 200-800 yuan (within the authorized range and the distribution is normal), but the operation interval fluctuates greatly (5 minutes to 40 minutes), and the operation order is different from that of veteran employees (fill in the refund remarks first and then select the merchant, instead of selecting the merchant first and then filling in the remarks). The feature vectors of the first 6 operations (days 1-3 after joining the company) extracted by the sliding window sequence encoder are far from the center of the global "mature refund operation" behavior cluster.

[0123] Behavioral clustering detection results (initial): DBSCAN Layer 1: The Mahalanobis distance d_Mahalanobis=3.4>ε=2.5 from the comprehensive behavioral feature vector f of specialist X to the nearest behavioral cluster center is determined to be a noise point; The second layer of the isolated forest: AnomalyScore(f) = 0.61, falling into the interval (0.50, 0.65], is marked as "suspicious operation"; Risk score: RiskScore=0.58, falling into the low-risk suspicious range [0.45, 0.65), so it is allowed to proceed silently, but an enhanced log is recorded and it will be included in the key focus of subsequent audits.

[0124] Step S6 Feedback optimization process: In the following three days, the 12 operations marked as "suspicious" by Specialist X were audited by the direct supervisor and the conclusion was "compliant" (no violations). The system added these 12 operations to the misjudgment sample library. Because the misjudgment rate of Specialist X's marking operations reached 12 / 12=100%, exceeding the 5% misjudgment rate threshold, the model optimization process was automatically triggered, and a personalized behavioral baseline sub-model was created for him. The personalized sub-model establishes a separate DBSCAN sub-cluster for specialist X, absorbing his operation order of "note first, then select merchant" and the fluctuating operation interval as the normal behavior pattern. Starting from day 10, the new operational feature vector of Commissioner X stably falls into its personalized sub-cluster, is no longer judged as a noise point, and no longer triggers suspicious marking.

[0125] Final result: Specialist X's false positive rate dropped from 100% initially (all flagged suspicious operations were subsequently compliant) to 0%, while the global model's false positive rate decreased by 45% due to the elimination of this individual difference interference. This example illustrates that the online feedback and personalized baseline mechanism in step S6 can adaptively eliminate misjudgments caused by individual behavioral differences without sacrificing global detection capabilities.

[0126] To verify the effectiveness and advancement of the technical solution of this invention, we conducted offline replay experiments and ablation experiments on the operation and management system of a large payment platform.

[0127] The experimental dataset was collected from the operation and management system of a large payment platform, covering the operational behavior data of 320 operators over a period of 6 months (January 2025 to June 2025). It involves 5 core operational operations, including refund processing, merchant review, fee adjustment, fund transfer, and permission change, with a total of approximately 8 million original operation logs.

[0128] After being anonymized, the dataset was divided into the following chronological order: the first four months' data served as the training set for training behavioral baselines; the middle month's data served as the validation set for model validation and parameter tuning; and the last month's data (approximately 1.33 million operations, including 1,560 violation samples confirmed by the risk control team) served as the test set for evaluation.

[0129] The test adopted an offline replay method: each operation was replayed one by one to the system of this invention and two comparison systems according to the time of occurrence, and the interception / judgment results were recorded and compared with the violation tags marked by humans.

[0130] The parameters of the comparison model are explained below: Traditional rule engine / log auditing method: Set 18 static compliance rules, such as triggering alarms when the refund amount exceeds 50,000 yuan, triggering alarms when the operation is outside the working hours, and triggering alarms when the same operation is more than 50 times in a single day. Only perform batch scanning of backend operation logs after the fact. Traditional RBAC method: Configure 5 role levels and 126 fine-grained permission points for operators, perform permission verification at the operation entry point, and allow all operations within the legal permissions.

[0131] The calculation methods for each evaluation indicator are as follows: Violation detection recall rate = (Number of actual violations detected / Total number of violations) × 100%; Pre-emptive interception rate = (Number of illegal operations successfully intercepted before execution / Total number of illegal operations) × 100%; Accuracy of compound sequence violation detection = (Number of correctly detected compound sequence violation operations / Total number of operations marked as compound sequence violation) × 100%; Violation detection coverage rate within authorized permissions = (Number of violations detected within authorized permissions / Total number of violations within authorized permissions) × 100%; False alarm rate = (Number of normal operations incorrectly identified as violations / Total number of operations marked as abnormal) × 100%; Average detection latency = the average time taken from initiating an operation to completing a risk assessment.

[0132] Table 3 below shows the offline replay evaluation results of the method of the present invention and two comparative systems on the above test set (the test set contains 1,560 violation samples and approximately 1.33 million normal operations): Table 3 To verify the necessity of each core technical means of the present invention, ablation experiments were conducted on the same test set above, with each single technical means being removed sequentially to form a control variant. The results are shown in Table 4 below: Table 4 Based on the above ablation experiment results, the following conclusions can be drawn: (1) Necessity of two-layer detection: After removing the second layer confirmation of the isolated forest, the overall false alarm rate increased from 3.2% to 7.8% (about 2.4 times), while the recall rate remained basically the same (94.5% vs 93.2%). This proves that the secondary confirmation of the boundary noise points of DBSCAN by the isolated forest can effectively suppress false alarms without sacrificing the recall rate.

[0133] (2) Necessity of Sequence Encoding: After removing Bi-LSTM sequence encoding and using only single-point behavioral features, the accuracy of composite sequence violation detection plummeted from 83.0% to 52.0% (a decrease of 31 percentage points), and the coverage of violation detection within permissions decreased from 89.0% to 61.0% (a decrease of 28 percentage points). This proves that sequence temporal modeling is the core means of identifying composite violation patterns, and single-point features cannot capture the temporal combination relationship of multi-step operations.

[0134] (3) Real-time advantages of lightweight front-end deployment: After switching to server-side deployment, the average detection latency increased from 42ms to 235ms (approximately 5.6 times) because features need to be uploaded to the server for inference before the results are returned, and it is significantly affected by network jitter. Front-end Wasm deployment places inference in a Web Worker that is isolated from the main thread, eliminating network round-trip latency and ensuring that the interception agent completes processing within a 50ms window.

[0135] (4) Necessity of Adaptive Evolution: After removing online incremental updates and adopting a static model, the recall rate decreased from 93.1% at the beginning of the month to 71.0% at the end of the month (a decrease of 22.1 percentage points) due to the evolution of operational behavior patterns in the later stages of the test set (such as peak sales periods), while the false positive rate increased from 3.1% to 11.0% (an increase of approximately 3.5 times). This demonstrates that online incremental clustering combined with drift detection is indispensable for maintaining long-term detection performance.

[0136] Further reference Figure 5 As an implementation of the methods shown in the above figures, this invention provides an embodiment of a system for front-end real-time clustering identification and interception of payment operation violations. This system embodiment is similar to... Figure 1 and Figure 2 Corresponding to the method embodiments shown, the system can be specifically applied to various electronic devices.

[0137] Secondly, embodiments of the present invention also disclose a system for real-time front-end clustering identification and interception of payment operation violations, such as... Figure 5 As shown, it includes: In one specific embodiment, the front-end behavior acquisition and preprocessing module 1 is deployed at the front end of the payment operation system to collect and preprocess the operation behavior data of the operators in real time and generate structured operation behavior records; the operation sequence encoding and feature extraction module 2 is used to maintain a fixed-length sliding window for each operator, organize the operations in the window into an operation sequence in chronological order, encode the operation sequence using a lightweight bidirectional LSTM encoder, and extract the sequence-level feature vector and the single operation feature vector. The lightweight behavior clustering and anomaly detection module 3 is used to concatenate and fuse sequence-level feature vectors and single-operation feature vectors to generate a comprehensive behavior feature vector. It uses DBSCAN clustering as the first layer of detection for cluster analysis, and identifies noise points that do not fall into any behavior cluster as suspected abnormal operations. It uses the isolated forest model as the second layer of detection for secondary confirmation, and determines whether it is an abnormal operation based on the anomaly score. The context-aware risk scoring module 4 is used to calculate a comprehensive risk score for target operations that are identified as abnormal or suspicious operations. The pre-interception and operation control module 5 is deployed at the request sending layer of the payment operation system front end to intercept operation requests and execute corresponding pre-control measures based on the comprehensive risk score.

[0138] In a preferred embodiment, it further includes: a behavior baseline online update module 6, used to update the behavior clustering model and behavior baseline online based on operation feedback data.

[0139] The input / output data types of each module and the data interface protocols between modules are as follows: The input to the front-end behavior collection and preprocessing module 1 is the raw operation event flow (including DOM events, API request events, page navigation events, etc.) of the operators on the front end of the payment operation system. The output is a structured and encoded record of operation behavior. The data format is JSON structure, which is transmitted to downstream modules through the front-end memory message pipeline.

[0140] The input to the operation sequence encoding and feature extraction module 2 is a structured operation behavior record stream, and the output is a 128-dimensional sequence-level feature vector. and 32-dimensional single-operation feature vector The module contains two layers of Bi-LSTM encoders and attention pooling layers, and the modules are efficiently transmitted using TypedArray (Float32Array).

[0141] The input to the lightweight behavior clustering and anomaly detection module 3 is a 64-dimensional comprehensive behavior feature vector. The output is the detection result label (normal / suspicious / abnormal) and the AnomalyScore of the isolated forest. The module is encapsulated as a WebAssembly binary module and interacts with the upper-level module through the Wasm-JS Bridge.

[0142] The input to the context-aware risk scoring module 4 is the detection result of abnormal / suspicious operations and the operation context information. The output is a comprehensive risk score of RiskScore∈[0,1] and a risk factor analysis report. The interface between modules uses structured scoring objects for transmission.

[0143] The inputs to the pre-interception and operation control module 5 are operation requests and risk assessment results, and the outputs are handling decisions (interception / enhanced verification / release) and corresponding UI interactions (interception prompts, secondary verification interfaces). Request-level control is achieved through a front-end request interception proxy (based on Fetch API / XHR Monkey Patching).

[0144] The input to the behavioral baseline online update module 6 is operation feedback data and approval result data, and the output is the updated model parameters. The parameters are periodically distributed by the server (HTTP long polling / WebSocket push), and the front end achieves seamless parameter replacement through the hot reloading interface of the Wasm module.

[0145] The functions and methods of the above modules correspond to each other, and will not be repeated here.

[0146] This invention provides a method and system for intelligent identification and pre-emptive interception of payment operation violations based on a lightweight front-end behavioral clustering model. This method and system can be widely applied to risk control management in various payment operation systems. Through lightweight front-end deployment and real-time behavioral clustering analysis, this invention enables intelligent identification and pre-emptive interception of violations before they are actually executed, effectively reducing the risks of financial loss and compliance in payment operations. The method and system of this invention can be deployed and integrated on the basis of existing payment operation systems, exhibiting good compatibility and scalability, and possessing industrial practical value.

[0147] The above description is merely a preferred embodiment of the present invention and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of the invention is not limited to the specific combination of the above-described technical features, but also includes other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the inventive concept. For example, technical solutions formed by substituting the above-described features with (but not limited to) technical features with similar functions disclosed in this invention.

Claims

1. A method for real-time front-end clustering identification and interception of payment operation violations, characterized in that, The method includes the following steps: Step S1: Deploy behavior collection probes at the front end of the payment operation system to collect operation behavior data of operators in real time, preprocess the operation behavior data, and generate structured operation behavior records; Step S2: For each operator, maintain a fixed-length sliding window, organize the operations within the window into an operation sequence in chronological order, encode the operation sequence using a lightweight bidirectional LSTM encoder, extract the sequence-level feature vector, and simultaneously extract the single operation feature vector of the current single operation. Step S3: The sequence-level feature vector and the single-operation feature vector are concatenated and fused to generate a comprehensive behavior feature vector. DBSCAN clustering is used as the first layer of detection to perform cluster analysis on the comprehensive behavior feature vector. Noise points that do not fall into any behavior cluster are identified as suspected abnormal operations. The isolated forest model is used as the second layer of detection to confirm the suspected abnormal operations. The abnormality score is used to determine whether the operation is abnormal. Step S4: Calculate the comprehensive risk score for the target operation that was determined to be an abnormal or suspicious operation in step S3; Step S5: Deploy an interception proxy at the request sending layer of the payment operation system front end to intercept operation requests and execute corresponding pre-control measures based on the comprehensive risk score; The pre-control measures include: when the comprehensive risk score is higher than a first threshold, forcibly intercepting the operation request and generating an approval work order to push to the approval chain; when the comprehensive risk score is higher than a second threshold but not higher than the first threshold, triggering enhanced verification; when the comprehensive risk score is not higher than the second threshold, allowing the operation request.

2. The method according to claim 1, characterized in that, In step S2: the length of the sliding window N=20; the bidirectional LSTM encoder is a stack of two bidirectional LSTM layers, with each layer having a hidden state dimension h=64, and the total number of parameters controlled within 50KB; each operation generates a 48-dimensional input vector after preprocessing, including an 8-dimensional operation type encoding, a 6-dimensional operation object type encoding, a 1-dimensional normalized amount value, a 1-dimensional logarithmic value of the operation interval time, a 1-dimensional normalized value of the cumulative number of operations per day, a 1-dimensional normalized value of the page dwell time, a 3-dimensional time period type encoding, and a 27-dimensional operation parameter feature vector; the hidden state sequence output by the bidirectional LSTM encoder is weighted and summed using an attention pooling mechanism to obtain a 128-dimensional sequence-level feature vector. ,in, Let be the attention weights at the i-th time step. Let Σ be the bidirectional LSTM hidden state vector at the i-th time step, where Σ represents the summation over all N time steps within the sliding window; the single operation feature vector is 32-dimensional.

3. The method according to claim 1, characterized in that, In the step S3: the 128-dimensional sequence-level feature vector s and the 32-dimensional single operation feature vector are concatenated, and dimensionally reduced to 64 dimensions through one fully connected layer, to obtain a comprehensive behavior feature vector , where ReLU is the rectified linear unit activation function, is the weight matrix of the fully connected layer, is the bias vector of the fully connected layer, represents concatenating the sequence-level feature vector s and the single operation feature vector by dimension; the neighborhood radius ε of the DBSCAN clustering is 2.5, and the minimum number of samples in a cluster MinPts is 8; for the isolation forest model, the number of decision trees T is 100, the maximum number of sampled samples per tree ψ is 256, and the maximum tree depth limit is ; the calculation formula for the anomaly score is , where E[h(f)] is the average path length of the sample f in the T trees, and c(ψ) is the normalization constant of the average path length corresponding to the number of samples ψ; when AnomalyScore(f) > 0.65, it is determined as an abnormal operation, when 0.50 < AnomalyScore(f) ≤ 0.65, it is marked as a suspicious operation, and when AnomalyScore(f) ≤ 0.50, it is determined as a normal behavior.

4. The method according to claim 1, characterized in that, In step S4, the formula for calculating the comprehensive risk score is: The weights are configured as W1=0.35, W2=0.25, W3=0.20, and W4=0.20, with the RiskScore ranging from [0,1]. R... behavior For behavioral deviation risk score, R object Risk classification for the operation object, R temporal For operational timing risk scoring, R intent Risk assessment based on operational intent.

5. The method according to claim 4, characterized in that, The risk of behavioral deviation is categorized as follows: , where d Mahalanobis Let d be the Mahalanobis distance from the operational feature to the nearest cluster center of the behavior. max The 99th quantile of the Mahalanobis distance in historical data; the risk of the operation object is divided into: The merchant risk levels of high, medium, and low are mapped to 1.0, 0.5, and 0.2 respectively, with the amount as the weighting factor. ; The operation timing risk segment R temporal The risk score R of the operation intent is calculated based on the anomaly degree of operation frequency, weighted operation during non-working hours, and penalty for short-cycle high-frequency operations. intent Based on the sequence-level feature vector s, the risk probability value of the operation intention is obtained by predicting it through a 2-layer MLP.

6. The method according to claim 1, characterized in that, In step S5: the first threshold is 0.

85. When RiskScore ≥ 0.85, it is determined to be a high-risk operation, triggering forced interception; the second threshold is 0.

65. When 0.65 ≤ RiskScore < 0.85, it is determined to be a medium-risk operation, triggering enhanced verification; when 0.45 ≤ RiskScore < 0.65, it is determined to be a low-risk suspicious operation, silently allowed and recorded in the enhanced log; when RiskScore < 0.45, it is determined to be a normal operation, and allowed normally. The interception proxy is implemented by monkey-patching the global Fetch API and XMLHttpRequest.prototype.send. The intercepted requests are temporarily stored in the request suspension buffer, which is set with a suspension timeout. If the evaluation is not completed after the timeout, it is downgraded to allow and asynchronously supplemented for evaluation.

7. The method according to claim 1, characterized in that, In step S3: model quantization technology is used to quantize the DBSCAN and Isolation Forest model parameters from float32 to int8, compressing the total model size to less than 120KB; WebAssembly is used to encapsulate the model inference logic, and clustering inference is performed in the front-end browser with a single inference latency of less than 3ms; model parameters are updated periodically by the server, and the front-end hot reload does not require page refresh; inference is performed in an independent Web Worker, and the main thread sends features and receives results through postMessage.

8. The method according to claim 1, characterized in that, It also includes step S6: collecting follow-up feedback information for each operation risk assessment, wherein the DBSCAN clustering model performs incremental clustering updates every 4 hours using the behavioral data of the most recent 7 days; monitoring the displacement speed of the center point of each behavioral cluster, and triggering a drift alarm when the displacement distance of the center point of a cluster exceeds twice the standard deviation of the historical average displacement within 3 consecutive update cycles; maintaining a misjudgment sample library, and automatically triggering model parameter tuning when the misjudgment rate exceeds 5%; and automatically creating personalized behavioral baseline sub-models for specific operators who repeatedly make misjudgments.

9. A system for real-time front-end clustering identification and interception of payment operation violations, characterized in that, include: The front-end behavior collection and preprocessing module is deployed at the front end of the payment operation system. It is used to collect the operation behavior data of the operation personnel in real time and preprocess it to generate structured operation behavior records. The operation sequence encoding and feature extraction module is used to maintain a fixed-length sliding window for each operator, organize the operations within the window into an operation sequence in chronological order, and use a lightweight bidirectional LSTM encoder to encode the operation sequence and extract sequence-level feature vectors and single-operation feature vectors. The lightweight behavior clustering and anomaly detection module is used to concatenate and fuse the sequence-level feature vector and the single operation feature vector to generate a comprehensive behavior feature vector. DBSCAN clustering is used as the first layer of detection for cluster analysis. Noise points that do not fall into any behavior cluster are judged as suspected abnormal operations. The isolated forest model is used as the second layer of detection for secondary confirmation. The anomaly score is used to determine whether it is an abnormal operation. The context-aware risk scoring module is used to calculate a comprehensive risk score for target operations that are determined to be abnormal or suspicious operations. The pre-interception and operation control module is deployed at the request sending layer of the front end of the payment operation system. It is used to intercept operation requests and execute corresponding pre-control measures based on the comprehensive risk score.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 1 to 8.

Images