A bank transaction operation paradigm mining method, system and storage medium

Abstract

The application discloses a bank transaction operation paradigm mining method and system and a storage medium, relates to the technical field of computer processing, and comprises the following steps: S01, collecting bank transaction log stream data in real time to form a data set A with a time stamp, extracting data in the data set A and performing preprocessing to obtain a transaction sequence data set A', wherein the transaction sequence data set A' at least comprises desensitization processing and feature coding based on transaction elements; S02, inputting the transaction sequence data set A' into a preset model to extract a data subset B under a corresponding label scene, and performing hierarchical processing on a plurality of data subsets B based on a preset condition to obtain transaction operation subsequences under a plurality of scene groupings. The application effectively solves the technical problems of high-frequency scene rule redundancy and low-frequency key scene rule loss in traditional frequent item mining.

Description

Technical Field

[0001] This invention relates to the field of computer processing technology, and in particular to a method, system, and storage medium for mining bank transaction operation paradigms. Background Technology

[0002] As the digital transformation of the banking industry continues to deepen, bank counters and online transaction systems generate massive amounts of operation logs every day. The wide variety of transaction types (up to thousands), frequent changes in business processes, and operational differences under different transaction scenarios (such as amount, account type, transaction location, customer level, etc.) make how to automatically, efficiently, and accurately discover standard operating paradigms an important research direction in the field of fintech.

[0003] Currently, the standardization of bank transaction operation processes mainly relies on the following two technical approaches:

[0004] Manual analysis and rule configuration: Business experts manually analyze the operational steps for different transaction types based on transaction manuals and experience, and configure them as static process templates. While this method is intuitive, it has significant drawbacks: First, it is inefficient. Faced with thousands of transaction types and frequent business changes, manual analysis is time-consuming and labor-intensive, and it is difficult to cover all sub-scenarios (such as large-scale cross-regional transactions and special processes for VIP customers). Second, it is highly subjective and easily overlooks non-high-frequency but critical risk control steps, resulting in insufficient generalization ability of rules across different scenarios.

[0005] Traditional frequent itemset mining: Some techniques use association rule mining algorithms such as FP-Growth and Apriori to automatically extract frequently occurring combinations of operation steps from operation logs.

[0006] Traditional frequent itemset mining focuses solely on globally frequent operation sequences, failing to differentiate between the varying processes corresponding to different transaction elements (such as amount, account type, and transaction location). For instance, the operational steps for small personal transfers differ significantly from those for large corporate remittances, but frequent itemset mining conflates the two, causing generated rules to fail in specific scenarios. Furthermore, this approach uses a fixed minimum support threshold. High-frequency scenarios (such as ordinary query transactions) tend to generate numerous redundant rules, while low-frequency but important scenarios (such as large cross-border remittances and risk control authorization transactions) are ignored due to insufficient support, thus overlooking crucial risk control steps. Summary of the Invention

[0007] To address the aforementioned technical problems, the present invention provides a method for mining bank transaction operation paradigms, comprising the following steps:

[0008] S01. Real-time collection of bank transaction log stream data to form a timestamped dataset A, extracting data from dataset A and preprocessing it to obtain a transaction sequence dataset A', wherein the transaction sequence dataset A' includes at least de-identification processing and feature encoding based on transaction elements;

[0009] S02. Input the transaction sequence dataset A' into a preset model to extract the data subset B under the corresponding label scenario. Based on multiple data subsets B, perform hierarchical processing according to preset conditions to obtain transaction operation subsequences under multiple scenario groups.

[0010] S03. For each scenario group, perform frequent item clustering based on dynamic support to mine frequent operation paradigms under each scenario group in order to obtain frequent operation paradigms under different scenario groups.

[0011] S04. Perform pattern fusion on the frequent operation paradigms under the different scenario groups to identify and merge the common steps in multiple frequent operation paradigms, and mark the differentiated steps in different paradigms to generate a bank transaction operation paradigm library with IF-THEN rule structure.

[0012] S05. Based on the joint incremental learning mechanism, the bank transaction operation paradigm library is updated in real time using incremental transaction data. The updated rules are cached in a distributed cache system and a simulator is created. Then, at least two timestamped versions of the front-end system and the back-end update system are created, and steps S01-S04 are executed respectively. If the number of scenarios in the bank transaction operation paradigm library obtained by the back-end update system is greater than the number of scenarios in the bank transaction operation paradigm library obtained by the front-end system, then the back-end update system is allowed to be deployed locally and the simulator and its cached data are deleted.

[0013] Preferably, the data preprocessing in S01 is based on the SHA-256 algorithm to desensitize sensitive identifiers in the transaction logs;

[0014] The transaction elements include at least the transaction amount, account type, business processing channel, transaction location, and customer type;

[0015] The feature encoding includes at least binning and discretizing continuous transaction elements, and using one-hot encoding or label encoding for categorical transaction elements.

[0016] The layering process in S02 includes:

[0017] The first layer uses major business categories as the primary grouping dimension;

[0018] The second layer, within the main group, uses the transaction scenario as the subgroup dimension;

[0019] The third layer involves using the operational behavior context as a secondary grouping dimension within the subgroup, and dynamically aggregating and generating secondary groups according to a preset similarity threshold.

[0020] The processing of the transaction sequence dataset A' by the preset model is based on constructing feature vectors from the transaction elements, using the PCA algorithm to reduce the dimensionality of the feature vectors, and then generating a unique identifier for the scene label based on the dimensionality-reduced feature vectors.

[0021] Preferably, the dynamic support in step S03 performs frequent item clustering, including the following steps:

[0022] S31. Based on the timestamp length of dataset A, and then based on the obtained window length, collect the sliding window statistics on the frequency of transactions for each scenario group within the time window;

[0023] S32. Calculate the support baseline value of the scenario grouping based on the frequency of the transactions;

[0024] S33. A nonlinear mapping function based on a logarithmic function is adopted to dynamically adjust the minimum support threshold in combination with the length distribution of the operation sequence within the scene group, and the upper and lower bounds of the minimum support threshold are limited so that the minimum support threshold corresponding to the high-frequency scene group is increased to filter redundant rules, and the minimum support threshold corresponding to the low-frequency scene group is decreased to retain key paradigms.

[0025] Preferably, the frequent item clustering in step S03 is performed by using the K-means++ algorithm to cluster transaction operation sequences within the same scenario group, wherein the number of clusters K is determined by combining the elbow method with the silhouette coefficient.

[0026] Within each cluster, the FP-Growth algorithm is used to mine frequent operation sequences, which serve as the operation paradigm corresponding to that cluster. After clustering is completed, the DBI index is used to verify and correct the clustering results, and the number and division of clusters are dynamically adjusted accordingly.

[0027] Preferably, step S04, which involves pattern fusion of frequent operation paradigms under different scenario groups, includes the following steps:

[0028] S41. Input multiple operation paradigms under the same scenario group into the longest common subsequence algorithm to extract the common steps;

[0029] S42. Use the common steps as the main process of this scenario grouping;

[0030] S43. Mark the operation sequence fragments other than the common steps in each operation paradigm as the differentiated steps, and associate triggering conditions with each differentiated step;

[0031] The generation of the bank transaction operation paradigm library with the IF-THEN rule structure includes:

[0032] The condition part of the rule includes the unique identifier of the scene label and the triggering conditions of the differentiation step;

[0033] The action part of the rule includes the operation sequence of the differentiated steps or the jump pointer of the common steps;

[0034] The bank transaction operation paradigm library is organized as a hierarchical rule tree, with the root node being a unique identifier for the scenario label, the intermediate nodes being common steps, and the leaf nodes being differentiated steps.

[0035] Preferably, the joint incremental learning mechanism in step S05 includes the following steps:

[0036] S51. The Mini-Batch K-means algorithm is used to perform incremental clustering updates on the unique identifiers of the scene labels of newly added transaction sequences;

[0037] S52. Use the incremental FP-Growth algorithm to perform incremental mining of frequent itemsets for each group after clustering;

[0038] S53. When the amount of newly added transaction data reaches the preset update threshold, the reconstruction of the IF-THEN rule structure is triggered, including the re-extraction of common steps and the addition, deletion and modification of differentiated steps.

[0039] S54. After the update is completed, an incremental snapshot of the rule changes is recorded using a transaction log mechanism to support the rollback and version tracking of the rule base.

[0040] Preferably, in step S05, the updated rules are cached in a distributed caching system and a simulator is created. Then, at least two timestamped versions of the front-end system and the back-end update system are created, and steps S01-S04 are executed respectively. If the number of scenarios in the bank transaction operation paradigm library obtained by the back-end update system is greater than the number of scenarios in the bank transaction operation paradigm library obtained by the front-end system, then the back-end update system can be deployed locally and the simulator and its cached data can be deleted. This includes the following steps:

[0041] S551. In response to the joint incremental learning mechanism, the bank transaction operation paradigm library is updated in real time, the updated rules are cached in a distributed caching system, and a simulator is created based on container isolation technology; the simulator is used to simulate the transaction request traffic and rule matching behavior in the production environment, and the simulator is configured with a test transaction sample set and a request generator.

[0042] S552. Based on the rule base snapshot and timestamp version control mechanism, create at least two system instances, including a front-end system instance and a back-end update system instance; wherein, the front-end system instance loads the rule base snapshot corresponding to the rule version before the update, and the back-end update system instance loads the rule base snapshot corresponding to the rule version after the update; each system instance is an independent runtime environment, and is respectively bound to different logical slots of the distributed cache system;

[0043] S553. Call the simulator through the front-end system instance and the back-end update system instance respectively, and independently execute the following test steps S01 to S04 on the same test transaction sample set;

[0044] S554. Obtain the first number of scenarios counted after the execution of steps S01 to S04 of the post-update system instance, and the second number of scenarios counted after the execution of steps S01 to S04 of the pre-update system instance.

[0045] S555. Compare the number of the first scenario with the number of the second scenario: If the number of the first scenario is greater than the number of the second scenario, then the joint incremental learning update is deemed valid, the post-update system is allowed to be deployed in the local production environment, and the computing resources occupied by the simulator are released and its cached data is cleared; otherwise, the update is deemed invalid, the front-end system instance continues to run, an update failure alarm is output, and the simulator is retained for fault reproduction and rule rollback analysis.

[0046] A system for implementing the bank transaction operation paradigm mining method described in the above scheme includes:

[0047] The data acquisition and preprocessing module is used to acquire bank transaction log stream data, perform data preprocessing on the bank transaction log stream data, and generate a standardized transaction sequence dataset; the data preprocessing includes at least de-identification processing and feature encoding based on transaction elements;

[0048] The scenario grouping module, connected to the data acquisition and preprocessing module, is used to perform scenario labeling processing on the transaction sequence dataset, generate unique scenario label identifiers based on the transaction elements, and perform primary-secondary-secondary three-level grouping on the transaction sequence dataset according to the unique scenario label identifiers to obtain transaction operation subsequences under multiple scenario groups.

[0049] The frequent item clustering and summarization module is connected to the scenario grouping module. It is used to perform frequent item clustering based on dynamic support for each scenario group and to mine frequent operation paradigms under each scenario group. The dynamic support is adaptively generated according to the frequency distribution and statistical characteristics of transaction sequences within the scenario group.

[0050] The rule base generation module is connected to the frequent item clustering and summarization module and is used to perform pattern fusion on frequent operation paradigms under different scenario groups. The pattern fusion includes: identifying and merging common steps in multiple frequent operation paradigms, while marking differentiated steps in different paradigms, and generating a bank transaction operation paradigm library with an IF-THEN rule structure.

[0051] The learning module, connected to the rule base generation module, is used to update the bank transaction operation paradigm library in real time using incremental transaction data based on a joint incremental learning mechanism, and cache the updated rules to a distributed caching system. A timestamp version control mechanism is used to manage multiple versions of the updated rules, which is used to provide real-time transaction recommendations or risk control decisions.

[0052] The present invention has at least the following beneficial effects:

[0053] 1. This invention can generate unique scene tags based on factors such as transaction amount, account type, and channel, and applies increased or decreased minimum support thresholds for high-frequency and low-frequency scenes respectively. This mechanism effectively solves the technical problems of redundant rules in high-frequency scenes and missing rules in low-frequency key scenes in traditional frequent item mining.

[0054] 2. This invention significantly improves the cluster cohesion and statistical significance of frequent operation sequence mining by employing K-means++ pre-clustering combined with FP-Growth mining and introducing the DBI index to verify and correct the clustering results. Furthermore, it extracts common steps and labels differentiated steps through the longest common subsequence, and organizes the IF-THEN rule base using a hierarchical rule tree, achieving structured storage and efficient reuse of operation paradigms. Merging and storing common steps greatly reduces memory usage, while conditional triggering of differentiated steps ensures process adaptability in special scenarios.

[0055] 3. This invention achieves low-latency updates to the rule base through joint incremental learning using Mini-Batch K-means and incremental FP-Growth, and supports version rollback through transaction log snapshots. Redis distributed caching, combined with LRU eviction and blue-green deployment hot switching, enables real-time transaction recommendations or risk control interception based on updated operational paradigms. Attached Figure Description

[0056] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0057] Figure 1 Here is a flowchart of a bank transaction operation paradigm mining method provided in Embodiment 1 of the present invention;

[0058] Figure 2 A flowchart of S03 provided in Embodiment 1 of the present invention;

[0059] Figure 3 A flowchart of S04 provided in Embodiment 1 of the present invention;

[0060] Figure 4 This is a flowchart of S05 provided in Embodiment 1 of the present invention;

[0061] Figure 5 This is a flowchart of S551-S555 provided in Embodiment 2 of the present invention;

[0062] Figure 6 This is a module diagram provided for Embodiment 3 of the present invention. Detailed Implementation

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

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

[0065] Example 1

[0066] This embodiment provides a method, system, and storage medium for mining bank transaction operation paradigms. The method includes the following steps: Figure 1 As shown:

[0067] S01. Real-time collection of bank transaction log stream data to form a timestamped dataset A. Data in dataset A is extracted and preprocessed to obtain a transaction sequence dataset A'. The transaction sequence dataset A' includes at least de-identification processing and feature encoding based on transaction elements.

[0068] Furthermore, the data preprocessing in the above embodiments is based on the SHA-256 algorithm to desensitize sensitive identifiers in the transaction logs;

[0069] Secondly, the aforementioned transaction elements should at least include transaction amount, account type, business processing channel, transaction location, and customer type;

[0070] Furthermore, the feature encoding in the above embodiments includes at least binning and discretizing continuous transaction elements, and using one-hot encoding or label encoding for categorical transaction elements.

[0071] Specifically, transaction log stream data is collected in real time through the log interface or message queue (such as Kafka) of the bank's core system. Each transaction log record is accompanied by a precise timestamp (accurate to the millisecond level), and all records accumulated in chronological order constitute the original dataset A.

[0072] The data then enters the preprocessing stage. The de-identification process uses the SHA-256 hash algorithm to irreversibly encrypt sensitive identifiers in the logs. For example, inputting an ID number “xxxxxxxxxxxxxxxxxx” into SHA-256 yields a fixed-length hexadecimal hash value “7c8d...a3f2”, and the original plaintext is no longer retained; similarly, the mobile phone number “13912345678” becomes “9e4a...b1c3” after hashing.

[0073] Transaction element extraction refers to extracting business attributes that significantly impact operational processes from cleaned logs. Specifically, this includes: transaction amount (continuous numerical type, such as 150,000.00), account type (categorical type, enumerated values ​​such as "corporate basic account", "personal savings card", "credit card"), transaction channel (categorical type, such as "mobile banking", "counter", "ATM", "corporate online banking"), transaction location (categorical or numerical type, which can be IP address, branch number, or latitude and longitude range), and customer type (categorical type, such as "ordinary individual", "VIP", "micro-enterprise", "large enterprise"). Taking the above transfer as an example, the extracted elements are: amount = 150,000.00, account type = corporate basic account, channel = corporate online banking, location = Beijing, customer type = corporate VIP.

[0074] Feature encoding converts non-numerical transaction elements into numerical vectors that can be directly computed by machine learning algorithms (such as K-means++). For continuous transaction elements (such as amount), binning discretization is used: the amount range is divided into several levels, for example, setting the bin boundaries as [0, 1000), [1000, 10000), [10000, 100000), [100000, +∞), then 150000.00 falls into the fourth bin and is encoded as "amount level = 4". For categorical transaction elements, one-hot encoding or label encoding is used: one-hot encoding expands each category into a binary dimension. For example, "channel" has three possible values ​​{mobile banking, corporate online banking, counter}, then "corporate online banking" is encoded as [0, 1, 0]; label encoding directly maps to integers, such as "individual" = 1, "corporate VIP" = 2, "corporate ordinary" = 3. However, it should be noted that label encoding implies an order relationship, so one-hot encoding is preferred when the categories have no natural order. After the above encoding is completed, an original transaction record is transformed into a numerical feature vector.

[0075] S02. Input the transaction sequence dataset A' into the preset model to extract the data subset B under the corresponding label scenario. Based on multiple data subsets B, perform hierarchical processing according to preset conditions to obtain transaction operation subsequences under multiple scenario groups.

[0076] Furthermore, the above-mentioned layered processing includes:

[0077] The first layer uses major business categories as the primary grouping dimension;

[0078] The second layer, within the main group, uses transaction scenarios as the subgroup dimension;

[0079] The third layer, within the subgroup, uses the context of the operation behavior as the auxiliary grouping dimension, and dynamically aggregates and generates auxiliary groups according to a preset similarity threshold;

[0080] The preset model processes the transaction sequence dataset A' by constructing feature vectors from transaction elements, using the PCA algorithm to reduce the dimensionality of the feature vectors, and then generating a unique scene label based on the dimensionality-reduced feature vectors.

[0081] Specifically, to achieve accurate scenario attribution for each transaction sequence, the pre-defined model first extracts transaction elements strongly related to the business scenario from the transaction sequence dataset, constructing a high-dimensional feature vector. Transaction elements include at least transaction amount (continuous), account type (e.g., personal settlement account, corporate basic account, interbank account), business processing channel (e.g., mobile banking, counter, self-service terminal), transaction location (regional code), and customer type (e.g., ordinary, VIP, institutional). Due to the differences in scale and high dimensionality of these features, the model first standardizes the original features (e.g., Z-score normalization), and then uses Principal Component Analysis (PCA) to reduce the dimensionality of the high-dimensional feature vector, retaining the top principal components with a cumulative variance contribution rate exceeding 90%. After dimensionality reduction, based on the principal component score vector, the model generates a globally unique "scenario label identifier" for each transaction sequence through hash mapping or cluster center matching. After obtaining the scenario label identifier for each transaction sequence, the system further performs a three-level grouping process: "primary-secondary-secondary." This hierarchical processing is not a simple first-level classification, but rather a gradual refinement of the context of the operational behavior through three progressive levels.

[0082] The first layer (primary grouping) uses business categories as the coarsest level of division. Business categories are typically determined by the business type codes in the bank's core system, such as "deposit business," "loan business," "transfer and remittance business," "foreign exchange business," and "wealth management business." This layer of grouping ensures that the operational processes of different business types are isolated at the root level, avoiding the mixing of ineffective patterns across business types.

[0083] The second layer (subgrouping): Within the main grouping, further subdivisions are made based on transaction scenarios. Transaction scenarios are determined by the specific transaction types or triggering conditions within the major business category. For example, under the main group "Transfer and Remittance Business," it can be subdivided into scenarios such as "Intra-bank Transfer," "Inter-bank Transfer," "Cross-border Remittance," and "Bulk Payment." This layer of grouping allows for the differentiation of transaction operations with different processing logics within the same major business category.

[0084] The third layer (sub-grouping): Within this sub-grouping, the operational behavior context serves as the finest-grained grouping criterion. Operational behavior context includes features such as the length of the operation sequence, the type of key operation nodes (e.g., whether it includes special steps like "authorization approval," "face recognition," or "CAPTCHA verification"), and the time density of the operation. Crucially, the third layer introduces a dynamic aggregation mechanism: instead of treating each independent operational behavior context as a group, it dynamically merges subsequences with similar behavior context features into the same sub-group according to a preset similarity threshold. Similarity can be measured using edit distance (Levenshtein Distance) or the longest common subsequence (LCS) ratio. When the similarity between two operational subsequences exceeds a threshold (e.g., 0.85), they are grouped into the same sub-group. This dynamic aggregation mechanism effectively solves the grouping fragmentation problem in operation logs caused by subtle differences (such as an extra page refresh or a missing input validation), significantly improving statistical validity.

[0085] S03. For each scenario group, perform frequent item clustering based on dynamic support to mine frequent operation paradigms under each scenario group, so as to obtain frequent operation paradigms under different scenario groups.

[0086] Furthermore, in the above embodiments, dynamic support performs frequent item clustering, including the following steps (such as... Figure 2 ):

[0087] S31. Based on the timestamp length of dataset A, and then based on the obtained window length, collect the sliding window statistics on the frequency of transactions for each scenario group within the time window;

[0088] S32. Calculate the support baseline value for this scenario group based on the frequency of transaction occurrence;

[0089] S33. A nonlinear mapping function based on logarithmic function is adopted to dynamically adjust the minimum support threshold in combination with the length distribution of operation sequences within the scene group, and the upper and lower bounds of the minimum support threshold are limited so that the minimum support threshold corresponding to the high frequency scene group is increased to filter redundant rules, and the minimum support threshold corresponding to the low frequency scene group is decreased to retain key paradigms.

[0090] Furthermore, in the above embodiments, frequent item clustering is performed by using the K-means++ algorithm to cluster transaction operation sequences within the same scenario group, wherein the number of clusters K is determined by a combination of the elbow method and the silhouette coefficient.

[0091] Within each cluster, the FP-Growth algorithm is used to mine frequent operation sequences, which serve as the operation paradigm corresponding to that cluster. After clustering is completed, the DBI index is used to verify and correct the clustering results, and the number and division of clusters are dynamically adjusted accordingly.

[0092] Specifically, before mining frequent operational paradigms under each scenario group, an adaptive minimum support threshold needs to be dynamically calculated for that scenario group to replace the globally fixed support parameter in traditional methods. Specifically, the system first reads the transaction sequence dataset A corresponding to the scenario group, extracts the timestamp information of each transaction record, calculates the time span of the entire dataset A (i.e., the difference between the maximum and minimum timestamps), and generates a series of time windows based on a preset sliding window step size (e.g., in days, with a step size of 1 day) and window width (e.g., 7 days). For example, assuming the time span of dataset A for a certain "large cross-border remittance" scenario group is 30 days, the system will generate 24 sliding windows with a length of 7 days and a step size of 1 day (days 1-7, 2-8, ..., 24-30). Within each time window, the total number of transactions occurring under that scenario group is counted, thus obtaining a frequency sequence that changes over time.

[0093] Based on the frequency sequence described above, the system calculates the baseline support value for this scenario group. Typically, the average or median of the frequencies across each time window is used to reflect the average activity level of the scenario during regular time periods. Subsequently, a nonlinear mapping function based on a logarithmic function is employed to dynamically adjust the minimum support threshold.

[0094] After determining the dynamic minimum support threshold for each scenario group, the system adopts a three-stage hybrid strategy of "K-means++ pre-clustering + intra-cluster FP-Growth mining + DBI exponential verification correction" to extract frequent operation paradigms.

[0095] Phase 1: K-means++ Pre-clustering. For all transaction operation sequences under the same scenario group (each sequence consists of a series of operation IDs, such as "Login → Select Account → Enter Amount → Verify U-Shield → Confirm Submission"), the system first uses the K-means++ algorithm to cluster them. Unlike ordinary K-means, K-means++ selects initial cluster centers probabilistically, avoiding the local optimum problem caused by random initialization. During clustering, the similarity between operation sequences is measured using Dynamic Time Warping (DTW) distance or Longest Common Subsequence (LCS) distance, rather than simple Euclidean distance, because the operation sequences are variable-length sequential data. The number of clusters K is determined using a joint strategy of "elbow method combined with silhouette coefficient": the system performs clustering in the range of K=2 to K=15, calculating the sum of squared errors (SSE) within each cluster and the average silhouette coefficient of all samples for each K value. SSE decreases as K increases, and when the rate of decrease slows down significantly, an "elbow" point is formed, and the K value corresponding to this point is selected as a candidate; at the same time, the K value with the largest average silhouette coefficient is selected as another candidate. If the two values ​​are consistent, the value is adopted directly; otherwise, the K value with the higher profile coefficient is preferred because the profile coefficient can better reflect the intra-cluster compactness and inter-cluster separation.

[0096] The second stage: Intra-cluster FP-Growth mining. Within each cluster, the system uses all operation sequences within that cluster as input and employs the FP-Growth (Frequent Pattern Growth) algorithm to mine frequent operation sequences. The core idea of ​​FP-Growth is: first, scan the sequence database, count the frequency of each operation, and filter out items below the dynamic minimum support threshold; second, construct an FP-Tree (Frequent Pattern Tree) in descending order of frequency, compressing and storing operation sequences with shared prefixes; finally, recursively mine the conditional pattern base of the FP-Tree to generate all frequent operation sequences. Compared to the Apriori algorithm, FP-Growth avoids multiple scans of the database and the explosive generation of candidate sets, exhibiting significant performance advantages when processing large-scale, long-sequence data such as bank transaction logs. The frequent operation sequences mined from each cluster are the corresponding operation paradigms for that cluster—for example, if 80% of the sequences in a cluster contain "login → select receiving bank → enter account number → verify account name → submit → SMS verification," then this 6-step sequence is marked as an operation paradigm.

[0097] Phase 3: DBI Index Validation and Dynamic Correction. After clustering, the system uses the Davies-Bouldin Index (DBI) to quantitatively evaluate the compactness and segregation of the clustering results. The DBI index is calculated as the ratio of the average distance from each sample within a cluster to the cluster center (intra-cluster dispersion) to the distance between cluster centers (inter-cluster separation). A smaller DBI value indicates higher clustering quality. If the DBI index of the current clustering result exceeds a preset threshold (e.g., 1.2), it indicates poor clustering performance (possibly due to improper K value selection or changes in data distribution). The system will automatically trigger a correction process: first, it attempts to re-cluster near the original K value (e.g., K±1, K±2), selecting the K value with the smallest DBI index; if all attempts fail to reduce the DBI below the threshold, a hierarchical clustering merging strategy is initiated, merging the two adjacent clusters with the highest similarity, recalculating the DBI, and iterating until the DBI reaches the target. For example, suppose that in a certain “financial purchase” scenario, when the initial K=5, the DBI=1.5 (exceeding the threshold), the system tries K=4 and gets DBI=1.1 (meeting the standard), then automatically adjusts the number of clusters to 4; if the adjustment is still not ideal, then further merge two clusters that are highly similar in operation sequence patterns (e.g., LCS similarity greater than 0.85) to finally obtain the optimized clustering partition.

[0098] Through the four-layer progressive mechanism of "dynamic support adjustment + K-means++ pre-clustering + intra-cluster FP-Growth + DBI correction", this method can adaptively mine frequent operation paradigms that are both statistically significant and business interpretable under different scenario groupings, providing high-quality input for subsequent pattern fusion and rule base construction.

[0099] S04. Perform pattern fusion on frequent operation paradigms under different scenario groups to identify and merge common steps in multiple frequent operation paradigms, while marking differentiated steps in different paradigms to generate a bank transaction operation paradigm library with IF-THEN rule structure.

[0100] Furthermore, the above embodiments perform pattern fusion on frequent operation paradigms under different scenario groups, including the following steps (such as...). Figure 3 (as shown)

[0101] S41. Input multiple operation paradigms under the same scenario group into the longest common subsequence algorithm to extract common steps;

[0102] S42. Use common steps as the main process for this scenario grouping;

[0103] S43. Mark the operation sequence segments other than the common steps in each operation paradigm as differentiated steps, and associate triggering conditions with each differentiated step.

[0104] The generation of a bank transaction operation paradigm library with an IF-THEN rule structure includes:

[0105] The conditions section of the rule includes a unique identifier for the scene tag and the triggering conditions for the differentiated steps;

[0106] The action part of the rule contains the operation sequence of differentiated steps or the jump pointer of common steps;

[0107] The bank transaction operation paradigm library is organized as a hierarchical rule tree, with the root node being a unique identifier for the scenario label, the intermediate nodes being common steps, and the leaf nodes being differentiated steps.

[0108] Specifically, after clustering frequent items for different scenario groups, each scenario group typically generates multiple frequent operation paradigms (i.e., high-frequency operation sequences). These paradigms may contain a large number of repetitive operation steps; storing them all directly would cause rule redundancy and reduce matching efficiency. Meanwhile, the differences in steps between different paradigms are key to reflecting the unique characteristics of a specific transaction scenario. Therefore, this step employs pattern fusion technology to structurally integrate multiple operation paradigms within the same scenario group, generating a compact and easily searchable IF-THEN rule base.

[0109] Specifically, all frequent operation paradigms within the same scenario group are taken as input, and the Longest Common Subsequence (LCS) algorithm is called. The LCS algorithm finds the longest common subsequence that appears sequentially among multiple sequences; this subsequence represents the common steps of these operation paradigms. For example, for the scenario group "personal online banking transfer," the three frequently discovered operation paradigms might be:

[0110] Paradigm A: Log in → Select Transfer → Enter Recipient Account → Enter Amount → Enter Verification Code → Confirm Submission

[0111] Paradigm B: Log in → Select Transfer → Enter Recipient Account → Enter Amount → Face Verification → Confirm and Submit

[0112] Paradigm C: Login → Select Transfer → Enter Recipient Account → Enter Amount → Enter Verification Code → SMS Confirmation → Confirm Submission. The common steps extracted using the LCS algorithm are: Login → Select Transfer → Enter Recipient Account → Enter Amount → Confirm Submission. This common step constitutes the "main process" for this scenario group.

[0113] The extracted common steps are used as the backbone process for this scenario group. The backbone process represents the core steps that all operations in this scenario must go through, and only one copy needs to be saved in the subsequent rule storage, avoiding duplicate storage.

[0114] For each original operational paradigm, the segments remaining after removing common steps in its operational sequence are marked as differentiated steps. Simultaneously, triggering conditions are associated with each differentiated step. Triggering conditions typically originate from key transaction elements (such as amount range, account type, channel, etc.) in the scenario labels generated in step S2. Continuing with the example above:

[0115] The differentiating steps in Paradigm A are: inputting a verification code. The triggering condition can be set as: transaction amount ≤ 5000 yuan and no risk control flag.

[0116] The differentiation step in Paradigm B is facial recognition verification. The triggering condition can be set as: transaction amount > 5000 yuan and transaction amount ≤ 20000 yuan.

[0117] The differentiation steps in Paradigm C are: enter the verification code → SMS secondary confirmation. The triggering condition can be set as: transaction amount > 20,000 yuan or account has abnormal login risk.

[0118] Generation of IF-THEN rule structures.

[0119] After completing the above steps, the system will generate a rule structure with IF-THEN logic, implemented as follows: The condition part (IF) of the rule consists of two parts: one is a unique identifier for the scenario label (e.g., "personal online banking transfer_domestic_debit card"), and the other is the triggering condition associated with the differentiated step (e.g., "transaction amount > 5000 and ≤ 20000"). The action part (THEN) of the rule contains the specific operation sequence of the differentiated step, or, when there is no differentiated step (i.e., the paradigm is completely equivalent to the main process), a jump pointer to a common step is provided.

[0120] To facilitate efficient retrieval and real-time matching, the entire banking transaction operation paradigm library is organized into a hierarchical rule tree:

[0121] Root node: A unique identifier for the scene tag. For example, "Personal online banking transfer_Domestic_Debit card". Different scene tags correspond to different subtrees.

[0122] Intermediate nodes: Each operation in the common steps (i.e., the main process). They are connected sequentially to form a path. For example, the first child node of the root node is "Login", the second child node is "Select Transfer", the third child node is "Enter Recipient Account", the fourth child node is "Enter Amount", and the fifth child node is "Confirm Submission". These nodes can be shared by all rules in this scenario.

[0123] Leaf nodes: Differentiated steps. Each leaf node is attached to its corresponding common step node and includes a trigger condition. For example, under the intermediate node "Confirm Submission", three leaf nodes extend, corresponding to "Enter Verification Code", "Face Recognition Verification", and "Enter Verification Code → SMS Secondary Confirmation", with each leaf node marked with its own trigger condition.

[0124] When the system receives a real-time transaction request (such as a customer initiating a domestic transfer of 12,000 yuan through their personal online banking), the processing flow is as follows:

[0125] Extract the scene elements of the request, generate the scene tag "personal online banking transfer_domestic_debit card", and locate the corresponding rule tree root node.

[0126] Execute common steps sequentially along the intermediate nodes (these steps are mandatory and do not require conditional checks).

[0127] Upon reaching the leaf node layer, the leaf node conditions are matched based on the transaction amount (12,000 yuan) in the request: since 12,000 > 5,000 and ≤ 20,000, the leaf node "face verification" is matched.

[0128] The rules engine returns the "face verification" step in the THEN section and guides the user to complete this differentiated operation.

[0129] If another request is for 3,000 yuan, the "Enter verification code" leaf node is hit; if the amount is 50,000 yuan and an abnormal account login is detected, the "Enter verification code → SMS secondary confirmation" leaf node is hit.

[0130] By integrating the above-mentioned patterns and organizing hierarchical rule trees, this invention achieves compact storage of the operation paradigm library (common steps are stored only once), fast retrieval (the time complexity of the tree structure is O(L), where L is the tree depth), and flexible adaptation to differentiated processes, significantly reducing the storage overhead of the rule library and the online matching latency.

[0131] S05. Based on the joint incremental learning mechanism, the bank transaction operation paradigm library is updated in real time using incremental transaction data. The updated rules are cached in a distributed cache system and a simulator is created. Then, at least two timestamped versions of the front-end system and the back-end update system are created, and steps S01-S04 are executed respectively. If the number of scenarios in the bank transaction operation paradigm library obtained by the back-end update system is greater than the number of scenarios in the bank transaction operation paradigm library obtained by the front-end system, then the back-end update system is allowed to be deployed locally and the simulator and its cached data are deleted.

[0132] Furthermore, the joint incremental learning mechanism in the above embodiments includes the following steps (such as...) Figure 4 (as shown)

[0133] S51. The Mini-Batch K-means algorithm is used to perform incremental clustering updates on the unique identifiers of the scene labels of newly added transaction sequences;

[0134] S52. Use the incremental FP-Growth algorithm to perform incremental mining of frequent itemsets for each group after clustering;

[0135] S53. When the amount of newly added transaction data reaches the preset update threshold, the reconstruction of the IF-THEN rule structure is triggered, including the re-extraction of common steps and the addition, deletion and modification of differentiated steps.

[0136] S54. After the update is completed, an incremental snapshot of the rule changes is recorded using a transaction log mechanism to support the rollback and version tracking of the rule base.

[0137] Specifically, the Mini-Batch K-means algorithm is used to incrementally cluster and update the scene label unique identifiers of newly added transaction sequences. Unlike the traditional K-means algorithm, which requires re-clustering all historical data each time, Mini-Batch K-means generates small batches of data (e.g., 500 transaction sequences per batch) through random sampling. Based on this batch of data, new cluster centers are calculated and then weighted and merged with the historical cluster centers. In the specific implementation, the system maintains a cluster center vector for each existing scene label unique identifier. When a new transaction sequence enters the system, the distance between the feature vector of the sequence and each historical cluster center is first calculated, and it is assigned to the nearest neighbor scene group. Subsequently, the cluster centers are incrementally updated using all the new samples in the batch. The update formula is: New center = (1 - learning rate) × old center + learning rate × batch mean. For example, in actual banking scenarios, if "large interbank transfers (single transaction > 5 million yuan)" and "small intrabank transfers (single transaction < 10,000 yuan)" have been initially divided into two independent scenario groups, when a new transaction type such as "medium-amount cross-border remittances (1 million to 5 million yuan)" appears after the system goes live, Mini-Batch K-means will automatically determine whether to classify it into the existing group or create a new group based on the feature distribution of the new samples. If the feature vector of the new transaction sequence is more than a preset threshold away from the cluster center of "large interbank transfers", the system will dynamically create a third scenario group and assign a new scenario label with a unique identifier (such as "SCENE_CROSS_MID_001").

[0138] Incremental FP-Growth algorithm is used to incrementally mine frequent itemsets for each clustered group. In a banking transaction system, the number of newly added transaction logs can reach millions every day. If the FP tree is reconstructed and frequent itemsets are mined for each update, the computational cost would be extremely high. The core idea of ​​incremental FP-Growth is to maintain the FP tree structure of historical transactions and its frequent itemset statistics. When a new transaction sequence arrives, the new sequence is only inserted into the existing FP tree, and the node count and conditional pattern base are updated. In the specific implementation, the system maintains an independent incremental FP tree for each scenario group. When a new transaction sequence is assigned to a scenario group by step S51, the system inserts the operation step list of the sequence (such as "login → select account → enter amount → obtain verification code → confirm submission") as a transaction into the corresponding FP tree, and records the item support increment in the new transaction. For example, in the "large corporate remittance" scenario group, the historically mined frequent operation paradigm is: A (identity authentication) → B (fill in remittance information) → C (supervisor authorization) → D (submit). As business grows, regulatory requirements necessitate the addition of an "anti-money laundering declaration checklist" step E. When processing new transactions involving step E, the incremental FP-Growth algorithm adds a path to node E in the FP-tree and updates the support count of the relevant path. Once the support reaches a dynamic support threshold, the algorithm automatically includes step E in the frequent operation paradigm for that scenario group, forming a new paradigm: A→B→C→E→D. This process is fully automated and requires no manual rule configuration.

[0139] When the amount of newly added transaction data reaches a preset update threshold, the IF-THEN rule structure is reconstructed. The system can set the update threshold based on a quantity threshold (e.g., every 5000 newly added valid transaction sequences) or a time window threshold (e.g., 2 AM daily). When the trigger condition is met, the system calls the Longest Common Subsequence (LCS) algorithm to reanalyze the updated set of frequent operation paradigms. For example, in the "personal online banking transfer" scenario group, the system might identify the following two operation paradigms:

[0140] Paradigm 1: "Log in → Select recipient → Enter amount → SMS verification → Confirm";

[0141] Paradigm 2: "Login → Select Recipient → Enter Amount → Facial Recognition → Confirm". The LCS algorithm extracts the common steps "Login → Select Recipient → Enter Amount → Confirm" as the main process, while marking "SMS Verification" and "Facial Recognition" as differentiated steps.

[0142] Subsequently, the system generates corresponding IF-THEN rules: IF Scenario Label = "Personal Online Banking Transfer" AND Verification Method = "SMS Verification" THEN Execute Differentiated Step "SMS Verification"; IF Scenario Label = "Personal Online Banking Transfer" AND Verification Method = "Face Recognition" THEN Execute Differentiated Step "Face Recognition". When new transaction data continues to accumulate, leading to the emergence of new frequent patterns (such as the addition of a "fingerprint verification" step F), the system will insert step F as a new differentiated step into the rule tree during the next reconstruction, and dynamically adjust its priority in the rule tree based on its matching frequency with the actual operation sequence.

[0143] After the update is completed, an incremental snapshot of the rule changes is recorded using a transaction log mechanism to support rule base rollback and version tracking. Specifically, the system generates a globally unique transaction ID (e.g., "TX_xxxxx_xxx_A3F2" based on timestamps and hash values) for each rule update operation and writes all changes in this update to a log file in a structured format. The changes include at least the newly added scenario tags and their corresponding operation paradigms, deleted scenario tags and their reasons, and the differentiated steps that resulted in the changes and a comparison of their triggering conditions before and after. For example, a log entry for a rule change transaction can be represented as:

[0144] {"TX_ID":"TX_xxxxx_xxx_A3F2","ACTION":"UPDATE",

[0145] "SCENE":"SCENE_CORP_HIGH_001", "OLD_RULE":"A→B→C→D",

[0146] "NEW_RULE":"A→B→C→E→D","REASON":"The support for the new anti-money laundering steps has reached the threshold"}.

[0147] When a new version of the rule base deployed in the production environment experiences an anomaly (such as a significant drop in transaction processing success rate), operations and maintenance personnel can quickly roll back the rule base to a stable version by specifying a historical time point or transaction ID.

[0148] Example 2

[0149] Based on Embodiment 1, this embodiment caches the updated rules to a distributed caching system and creates a simulator. Then, it creates at least two timestamped versions of the front-end system and the back-end update system, and executes steps S01-S04 respectively. If the number of scenarios in the bank transaction operation paradigm library obtained by the back-end update system is greater than the number of scenarios in the bank transaction operation paradigm library obtained by the front-end system, then it allows the local deployment of the back-end update system and the deletion of the simulator and its cached data, including the following steps (e.g.) Figure 5(as shown)

[0150] S551. In response to the joint incremental learning mechanism, the bank transaction operation paradigm library is updated in real time. The updated rules are cached in a distributed caching system, and a simulator is created based on container isolation technology. The simulator is used to simulate the transaction request traffic and rule matching behavior in the production environment. The simulator is configured with a test transaction sample set and a request generator.

[0151] S552. Based on the rule base snapshot and timestamp version control mechanism, create at least two system instances, including one front-end system instance and one back-end update system instance; wherein, the front-end system instance loads the rule base snapshot corresponding to the rule version before the update, and the back-end update system instance loads the rule base snapshot corresponding to the rule version after the update; each system instance is an independent runtime environment, and is bound to different logical slots of the distributed caching system respectively;

[0152] S553. Call the simulator through the front-end system instance and the back-end update system instance respectively, and independently execute the following test steps S01 to S04 on the same test transaction sample set.

[0153] S554. Obtain the first scene count obtained after the subsequent update system instance executes steps S01 to S04, and the second scene count obtained after the preceding system instance executes steps S01 to S04.

[0154] S555. Compare the number of the first scenario with the number of the second scenario: If the number of the first scenario is greater than the number of the second scenario, the joint incremental learning update is deemed valid, allowing the deployment of the post-update system in the local production environment, and releasing the computing resources occupied by the simulator and clearing its cached data; otherwise, the update is deemed invalid, the front-end system instance continues to run, an update failure alarm is output, and the simulator is retained for fault reproduction and rule rollback analysis.

[0155] Specifically, after the joint incremental learning mechanism completes the update of the bank transaction operation paradigm library, the system first needs to synchronize the newly generated rule set from the computation layer to a distributed caching system (such as a Redis cluster) to ensure that subsequent verification can perform rule matching with production-grade performance. Simultaneously, the system calls a container orchestration tool (such as Docker or Kubernetes) to create an independent simulator instance based on container isolation technology. The core function of this simulator is to simulate the transaction request pressure and rule matching behavior of a real production environment. It must be pre-configured with two key components: first, a test transaction sample set. This sample set should cover typical scenarios in the incremental transaction data within the current period (such as personal transfers, corporate remittances, risk control authorizations, etc.), and should also include historical scenarios that were marked as key paradigms in the previous version but may be affected by this update; second, a request generator, which can send transaction requests to the system instance under test according to a preset concurrency level (e.g., 50 requests per second) and time distribution (e.g., Poisson distribution), and record the scenario label and rule hit result corresponding to each request.

[0156] Once the simulator is ready, the system creates two independent runtime system instances based on a rule base snapshot and timestamp version control mechanism. Specifically, the system reads two versions of the rule base snapshot from different logical slots in the distributed cache: the front-end system instance loads the rule version before the update, with a timestamp of T0; the back-end update system instance loads the new rule version produced by this joint incremental learning, with a timestamp of T1. Each system instance runs in an isolated container or virtual environment and is bound to different logical slots in the distributed cache system (e.g., through different Redis database numbers or key prefixes for isolation) to avoid cache pollution during the verification process. For example, assuming the original rule base key-value prefix is ​​"OP:v1", the front-end system instance is bound to "OP:v1 / validate", and the back-end system instance is bound to "OP:v2 / validate", with the two sets of rules logically completely separated.

[0157] Next, the two system instances independently execute test steps S01 to S04 on the exact same test sample set. The input and output of the test process are completely identical: S01 collects the test transaction log stream generated by the simulator, and forms a standardized sequence after SHA-256 desensitization and feature encoding; S02 calculates a unique identifier for the scenario label based on transaction elements (amount range, account type, channel, etc.) and performs primary-secondary-secondary three-level grouping; S03 performs K-means++ pre-clustering and FP-Growth mining within each group, combining dynamic support (such as logarithmic function adaptive threshold), to extract frequent operation paradigms; S04 merges common steps and marks differentiated steps using the longest common subsequence algorithm, finally outputting a complete bank transaction operation paradigm library, and counting the number of scenarios contained in the paradigm library. It is important to emphasize that each step from S01 to S04 uses the same random seed, the same algorithm parameters (such as K value determined by the elbow method, and the same upper and lower bounds of minimum support), and the same computing resource quota, thus ensuring that the difference in statistical results between the two instances only comes from the difference in the rule base version.

[0158] After execution, the system obtains the number of the first scenario (denoted as NT1) from the post-update system instance and the number of the second scenario (denoted as NT0) from the pre-update system instance. For example, suppose that in the test of the pre-update system instance (old rule base), a total of 120 valid scenarios (i.e., the set of operational paradigms that can generate valid IF-THEN rules under different scenario tags) were identified after the complete mining process; while in the test of the post-update system instance (new rule base), due to the addition of paradigm capture for the low-frequency scenario of "cross-border large remittance + corporate account + counter channel" by incremental learning, and the merging of multiple redundant ordinary query rules, a total of 158 scenarios were finally counted. Obviously, NT1=158>NT0=120, indicating that this joint incremental learning effectively improved the scenario coverage capability of the rule base.

[0159] Based on the above comparison results, the system executes deployment decisions as follows: When the number of first scenarios is significantly greater than the number of second scenarios, the update is deemed valid. The system automatically triggers the post-update system deployment process in the production environment (e.g., gradually switching the new version to all online nodes via blue-green deployment or canary deployment). Simultaneously, it calls the container API to release the CPU / memory resources occupied by the simulator and clears its internal cached test sample set and intermediate calculation results to avoid resource waste. Conversely, if NT1 ≤ NT0, for example, if the number of scenarios drops from 120 to 98 due to a erroneous merging of key steps or an incorrect increase in dynamic support in the new rule base, the system determines the update is invalid. It maintains the front-end system instance running in the production environment and outputs detailed update failure alarms (including speculation on the cause of failure, such as "incremental FP-Growth not converged" or "Mini-Batch clustering drift"). At the same time, it retains the simulator and its cached data for operations personnel to reproduce the fault and perform rule rollback analysis by replaying the test sample set. This closed-loop verification mechanism effectively ensures the reliability and security of the bank's transaction operation paradigm library during its dynamic evolution, preventing substandard updates from directly polluting the production environment.

[0160] Example 3

[0161] Based on the above embodiment one, this embodiment aims to provide a system for running the method, which includes (such as...) Figure 6 (as shown)

[0162] The data acquisition and preprocessing module is used to collect bank transaction log stream data, perform data preprocessing on the bank transaction log stream data, and generate a standardized transaction sequence dataset; data preprocessing includes at least de-identification processing and feature encoding based on transaction elements;

[0163] The scenario grouping module, connected to the data acquisition and preprocessing module, is used to perform scenario labeling on the transaction sequence dataset. It generates unique scenario label identifiers based on transaction elements and groups the transaction sequence dataset into three levels: primary, secondary, and secondary, resulting in multiple transaction operation subsequences under different scenario groups.

[0164] The frequent item clustering and summarization module is connected to the scenario grouping module. It is used to perform frequent item clustering based on dynamic support for each scenario group and to discover frequent operation paradigms under each scenario group. The dynamic support is adaptively generated according to the frequency distribution and statistical characteristics of the transaction sequences within the scenario group.

[0165] The rule base generation module, connected to the frequent item clustering and summarization module, is used to perform pattern fusion on frequent operation paradigms under different scenario groups. Pattern fusion includes: identifying and merging common steps in multiple frequent operation paradigms, while marking differentiated steps in different paradigms, and generating a bank transaction operation paradigm library with an IF-THEN rule structure.

[0166] The learning module, connected to the rule base generation module, is used to update the bank's transaction operation paradigm library in real time using incremental transaction data based on a joint incremental learning mechanism. The updated rules are cached in a distributed caching system, and a timestamp version control mechanism is used to manage multiple versions of the updated rules, which is used to provide real-time transaction recommendations or risk control decisions.

[0167] Example 4

[0168] This invention provides a non-transitory computer-readable storage medium storing at least one instruction or at least one program segment, which is loaded and executed by a processor to implement the following steps:

[0169] Real-time collected bank transaction log stream data is used to form a timestamped dataset A. Data in dataset A is extracted and preprocessed to obtain a transaction sequence dataset A'. The transaction sequence dataset A' includes at least de-identification processing and feature encoding based on transaction elements.

[0170] Input the transaction sequence dataset A' into the preset model to extract the data subset B under the corresponding label scenario. Based on multiple data subsets B, perform hierarchical processing according to preset conditions to obtain transaction operation subsequences under multiple scenario groups.

[0171] For each scenario group, frequent item clustering is performed based on dynamic support to mine frequent operation paradigms under each scenario group, so as to obtain frequent operation paradigms under different scenario groups.

[0172] Pattern fusion is performed on frequent operation paradigms under different scenario groups to identify and merge common steps in multiple frequent operation paradigms. At the same time, differentiated steps in different paradigms are marked to generate a bank transaction operation paradigm library with IF-THEN rule structure.

[0173] Based on the joint incremental learning mechanism, the bank transaction operation paradigm library is updated in real time using incremental transaction data. The updated rules are cached in a distributed cache system and a simulator is created. Then, at least two timestamped versions of the front-end system and the back-end update system are created, and steps S01-S04 are executed respectively. If the number of scenarios in the bank transaction operation paradigm library obtained by the back-end update system is greater than the number of scenarios in the bank transaction operation paradigm library obtained by the front-end system, then the back-end update system can be deployed locally and the simulator and its cached data can be deleted.

[0174] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0175] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0176] Example 5

[0177] This invention provides an electronic device, including a processor and a memory, wherein the memory stores at least one instruction or at least one program segment, and the at least one instruction or the at least one program segment is loaded and executed by the processor to implement the following steps:

[0178] Real-time collected bank transaction log stream data is used to form a timestamped dataset A. Data in dataset A is extracted and preprocessed to obtain a transaction sequence dataset A'. The transaction sequence dataset A' includes at least de-identification processing and feature encoding based on transaction elements.

[0179] Input the transaction sequence dataset A' into the preset model to extract the data subset B under the corresponding label scenario. Based on multiple data subsets B, perform hierarchical processing according to preset conditions to obtain transaction operation subsequences under multiple scenario groups.

[0180] For each scenario group, frequent item clustering is performed based on dynamic support to mine frequent operation paradigms under each scenario group, so as to obtain frequent operation paradigms under different scenario groups.

[0181] Pattern fusion is performed on frequent operation paradigms under different scenario groups to identify and merge common steps in multiple frequent operation paradigms. At the same time, differentiated steps in different paradigms are marked to generate a bank transaction operation paradigm library with IF-THEN rule structure.

[0182] Based on the joint incremental learning mechanism, the bank transaction operation paradigm library is updated in real time using incremental transaction data. The updated rules are cached in a distributed cache system and a simulator is created. Then, at least two timestamped versions of the front-end system and the back-end update system are created, and steps S01-S04 are executed respectively. If the number of scenarios in the bank transaction operation paradigm library obtained by the back-end update system is greater than the number of scenarios in the bank transaction operation paradigm library obtained by the front-end system, then the back-end update system can be deployed locally and the simulator and its cached data can be deleted.

[0183] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention in any way. Although the present invention has been disclosed above with reference to preferred embodiments, it is not intended to limit the present invention. Any person skilled in the art can make some modifications or alterations to the above-disclosed technical content to create equivalent embodiments without departing from the scope of the present invention. Any simple modifications, equivalent changes and alterations made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the scope of the present invention.

Claims

1. A method for mining bank transaction operation paradigms, characterized in that, Includes the following steps: S01. Real-time collection of bank transaction log stream data to form a timestamped dataset A, extracting data from dataset A and preprocessing it to obtain a transaction sequence dataset A', wherein the transaction sequence dataset A' includes at least de-identification processing and feature encoding based on transaction elements; S02. Input the transaction sequence dataset A' into a preset model to extract the data subset B under the corresponding label scenario. Based on multiple data subsets B, perform hierarchical processing according to preset conditions to obtain transaction operation subsequences under multiple scenario groups. S03. For each scenario group, perform frequent item clustering based on dynamic support to mine frequent operation paradigms under each scenario group in order to obtain frequent operation paradigms under different scenario groups. S04. Perform pattern fusion on the frequent operation paradigms under the different scenario groups to identify and merge the common steps in multiple frequent operation paradigms, and mark the differentiated steps in different paradigms to generate a bank transaction operation paradigm library with IF-THEN rule structure. S05. Based on the joint incremental learning mechanism, the bank transaction operation paradigm library is updated in real time using incremental transaction data, and the updated rules are cached in a distributed cache system and a simulator is created. Then, at least two timestamped versions of the front-end system and the back-end update system are created, and steps S01-S04 are executed respectively. If the number of scenarios in the bank transaction operation paradigm library obtained by the back-end update system is greater than the number of scenarios in the bank transaction operation paradigm library obtained by the front-end system, then the back-end update system is allowed to be deployed locally and the simulator and its cached data are deleted.

2. The method for mining bank transaction operation paradigms according to claim 1, characterized in that, The data preprocessing in S01 is based on the SHA-256 algorithm to desensitize sensitive identifiers in the transaction logs; The transaction elements include at least the transaction amount, account type, business processing channel, transaction location, and customer type; The feature encoding includes at least binning and discretizing continuous transaction elements, and using one-hot encoding or label encoding for categorical transaction elements. The layering process in S02 includes: The first layer uses major business categories as the primary grouping dimension; The second layer, within the main group, uses the transaction scenario as the subgroup dimension; The third layer involves using the operational behavior context as a secondary grouping dimension within the subgroup, and dynamically aggregating and generating secondary groups according to a preset similarity threshold. The processing of the transaction sequence dataset A' by the preset model is based on constructing feature vectors from the transaction elements, using the PCA algorithm to reduce the dimensionality of the feature vectors, and then generating a unique identifier for the scene label based on the dimensionality-reduced feature vectors.

3. The method for mining bank transaction operation paradigms according to claim 1, characterized in that, The dynamic support in step S03 performs frequent item clustering, including the following steps: S31. Based on the timestamp length of dataset A, and then based on the obtained window length, collect the sliding window statistics on the frequency of transactions for each scenario group within the time window; S32. Calculate the support baseline value of the scenario grouping based on the frequency of the transactions; S33. A nonlinear mapping function based on a logarithmic function is adopted to dynamically adjust the minimum support threshold in combination with the length distribution of the operation sequence within the scene group, and the upper and lower bounds of the minimum support threshold are limited so that the minimum support threshold corresponding to the high-frequency scene group is increased to filter redundant rules, and the minimum support threshold corresponding to the low-frequency scene group is decreased to retain key paradigms.

4. The method for mining bank transaction operation paradigms according to claim 1, characterized in that, The frequent item clustering in step S03 is achieved by using the K-means++ algorithm to cluster transaction operation sequences within the same scenario group, wherein the number of clusters K is determined by a combination of the elbow method and the silhouette coefficient. Within each cluster, the FP-Growth algorithm is used to mine frequent operation sequences, which serve as the operation paradigm corresponding to that cluster. After clustering is completed, the DBI index is used to verify and correct the clustering results, and the number and division of clusters are dynamically adjusted accordingly.

5. The method for mining bank transaction operation paradigms according to claim 1, characterized in that, The pattern fusion of frequent operation paradigms under different scenario groups in step S04 includes the following steps: S41. Input multiple operation paradigms under the same scenario group into the longest common subsequence algorithm to extract the common steps; S42. Use the common steps as the main process of this scenario grouping; S43. Mark the operation sequence fragments other than the common steps in each operation paradigm as the differentiated steps, and associate triggering conditions with each differentiated step; The generation of the bank transaction operation paradigm library with the IF-THEN rule structure includes: The condition part of the rule includes the unique identifier of the scene label and the triggering conditions of the differentiation step; The action part of the rule includes the operation sequence of the differentiated steps or the jump pointer of the common steps; The bank transaction operation paradigm library is organized as a hierarchical rule tree, with the root node being a unique identifier for the scenario label, the intermediate nodes being common steps, and the leaf nodes being differentiated steps.

6. The method for mining bank transaction operation paradigms according to claim 1, characterized in that, The joint incremental learning mechanism in step S05 includes the following steps: S51. The Mini-Batch K-means algorithm is used to perform incremental clustering updates on the unique identifiers of the scene labels of newly added transaction sequences; S52. Use the incremental FP-Growth algorithm to perform incremental mining of frequent itemsets for each group after clustering; S53. When the amount of newly added transaction data reaches the preset update threshold, the reconstruction of the IF-THEN rule structure is triggered, including the re-extraction of common steps and the addition, deletion and modification of differentiated steps. S54. After the update is completed, an incremental snapshot of the rule changes is recorded using a transaction log mechanism to support the rollback and version tracking of the rule base.

7. The method for mining bank transaction operation paradigms according to claim 6, characterized in that, In step S05, the updated rules are cached in a distributed caching system and a simulator is created. Then, at least two timestamped versions of the front-end system and the back-end update system are created, and steps S01-S04 are executed respectively. If the number of scenarios in the bank transaction operation paradigm library obtained by the back-end update system is greater than the number of scenarios in the bank transaction operation paradigm library obtained by the front-end system, then the back-end update system can be deployed locally and the simulator and its cached data can be deleted. This includes the following steps: S551. In response to the joint incremental learning mechanism, the bank transaction operation paradigm library is updated in real time, the updated rules are cached in a distributed caching system, and a simulator is created based on container isolation technology; the simulator is used to simulate the transaction request traffic and rule matching behavior in the production environment, and the simulator is configured with a test transaction sample set and a request generator. S552. Based on the rule base snapshot and timestamp version control mechanism, create at least two system instances, including a front-end system instance and a back-end update system instance; wherein, the front-end system instance loads the rule base snapshot corresponding to the rule version before the update, and the back-end update system instance loads the rule base snapshot corresponding to the rule version after the update; each system instance is an independent runtime environment, and is respectively bound to different logical slots of the distributed cache system; S553. Call the simulator through the front-end system instance and the back-end update system instance respectively, and independently execute the following test steps S01 to S04 on the same test transaction sample set; S554. Obtain the first number of scenarios counted after the execution of steps S01 to S04 of the post-update system instance, and the second number of scenarios counted after the execution of steps S01 to S04 of the pre-update system instance. S555. Compare the number of the first scenario with the number of the second scenario: If the number of the first scenario is greater than the number of the second scenario, then the joint incremental learning update is deemed valid, the post-update system is allowed to be deployed in the local production environment, and the computing resources occupied by the simulator are released and its cached data is cleared; otherwise, the update is deemed invalid, the front-end system instance continues to run, an update failure alarm is output, and the simulator is retained for fault reproduction and rule rollback analysis.

8. A system for implementing the bank transaction operation paradigm mining method according to any one of claims 1-7, characterized in that, include: The data acquisition and preprocessing module is used to acquire bank transaction log stream data, perform data preprocessing on the bank transaction log stream data, and generate a standardized transaction sequence dataset; the data preprocessing includes at least de-identification processing and feature encoding based on transaction elements; The scenario grouping module, connected to the data acquisition and preprocessing module, is used to perform scenario labeling processing on the transaction sequence dataset, generate a unique scenario label identifier based on the transaction elements, and perform primary-secondary-secondary three-level grouping on the transaction sequence dataset according to the unique scenario label identifier to obtain transaction operation subsequences under multiple scenario groups. The frequent item clustering and summarization module is connected to the scenario grouping module. It is used to perform frequent item clustering based on dynamic support for each scenario group and to mine frequent operation paradigms under each scenario group. The dynamic support is adaptively generated based on the frequency distribution and statistical characteristics of the transaction sequences within the scenario group; The rule base generation module is connected to the frequent item clustering and summarization module and is used to perform pattern fusion on frequent operation paradigms under different scenario groups. The pattern fusion includes: identifying and merging common steps in multiple frequent operation paradigms, while marking differentiated steps in different paradigms, and generating a bank transaction operation paradigm library with an IF-THEN rule structure. The learning module, connected to the rule base generation module, is used to update the bank transaction operation paradigm library in real time using incremental transaction data based on a joint incremental learning mechanism, and cache the updated rules to a distributed caching system. A timestamp version control mechanism is used to manage multiple versions of the updated rules, which is used to provide real-time transaction recommendations or risk control decisions.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the bank transaction operation paradigm mining method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the bank transaction operation paradigm mining method according to any one of claims 1 to 7.

Images