Intelligent early warning method and device for anti-electricity fraud, and medium

Abstract

The invention discloses an intelligent early warning method and device for anti-electricity fraud and a medium, and relates to the technical field of data processing methods based on financial purposes. The method comprises the following steps: acquiring multi-source data from a plurality of heterogeneous data sources, and performing data treatment on the multi-source data to generate a standardized risk data set; the multi-source data comprises a real-time data stream, a quasi-real-time data stream and an offline data stream, and the data management comprises data splicing, data cleaning and data labeling processing; based on the standardized risk data set, executing index calculation through a calculation engine to generate a plurality of risk indexes, and inputting the risk indexes into a multi-modal risk decision engine to execute expert rule decision and machine learning model decision in parallel to generate a risk early warning signal; generating a risk check list based on the risk early warning signal, and issuing the risk check list to a specified mechanism to execute a corresponding disposal action; the processing actions comprise transaction blocking, account management and control and verification issuing.

Description

Technical Field

[0001] This application relates to the field of data processing methods for financial purposes, and in particular to an intelligent early warning method, device and medium for combating telecommunications fraud. Background Technology

[0002] With the accelerated digitalization of financial services, financial crimes such as telecommunications fraud are becoming increasingly organized, professional, and covert, posing a severe challenge to financial institutions' risk monitoring and real-time interception capabilities. Operational risk monitoring and control, particularly in the area of ​​anti-telecom fraud, has become a core component of financial institutions' technological defense systems. Currently, the industry generally relies on rule-based post-event risk monitoring systems that trigger alerts after batch processing transaction data at the end of the day. This delayed response mechanism is ill-suited to the rapid same-day transfer of funds characteristic of telecom fraud, resulting in severely insufficient timeliness in early warning and response, and an inability to effectively intercept fraudulent funds.

[0003] Existing technologies rely on a single early warning method, resulting in low accuracy and high false alarm rates, easily generating a large number of invalid warnings and increasing the workload of operational verification. Furthermore, real-time monitoring during events and batch analysis after events are usually handled by two independent systems. The fragmentation of data and processes leads to fragmented risk assessments for the same account, resulting not only in duplicate verification tasks and reduced processing efficiency, but also hindering a comprehensive understanding and collaborative judgment of account risks. Summary of the Invention

[0004] This application provides an intelligent early warning method, device, and medium for combating telecom fraud, in order to solve the above-mentioned technical problems.

[0005] On the one hand, embodiments of this application provide an intelligent early warning method for combating telecom fraud, including: Multi-source data is obtained from multiple heterogeneous data sources, and data governance is performed on the multi-source data to generate a standardized risk dataset; the multi-source data includes real-time data streams, near real-time data streams, and offline data streams, and the data governance includes data splicing, data cleaning, and data tagging. Based on the standardized risk dataset, the computing engine performs index calculations to generate multiple risk indicators, which are then input into a multimodal risk decision engine to execute expert rule decisions and machine learning model decisions in parallel, thereby generating risk warning signals. Based on the risk warning signal, a risk verification form is generated and issued to the designated institution to carry out corresponding handling actions; the handling actions include transaction blocking, account control and verification issuance.

[0006] In one implementation of this application, based on the standardized risk dataset, a computing engine performs indicator calculations to generate multiple risk indicators, specifically including: The standardized risk dataset is accessed through a real-time indicator calculation engine, and real-time risk indicators are dynamically calculated within a preset time window; the time window includes a sliding window and a scrolling window. Load the batch-processed wide table of data and perform incremental calculations on the full offline data to obtain long-term batch risk indicators. During real-time indicator calculation, intermediate processing results of streaming data are persisted to memory storage, forming a multi-dimensional data cube structure that allows for data updates and indicator queries.

[0007] In one implementation of this application, the risk indicators are input into a multimodal risk decision engine to execute expert rule-based decision-making and machine learning model-based decision-making in parallel, generating risk warning signals, specifically including: For expert rule-based decision-making, risk indicators are obtained from the indicator cache and judged according to the hit-based rule conditions. If all conditions are met, an early warning signal is generated directly, or the preset numerical score corresponding to each rule condition in the scoring system is accumulated and added. If the final total risk score exceeds the preset threshold, an early warning signal is generated. For machine learning model decision-making, risk indicator values ​​are obtained from the indicator cache, the executable file is run to output risk probability values, and the risk probability values ​​are compared with preset risk probability thresholds. If the risk probability value exceeds the preset risk probability threshold, the model rule is determined to be hit. The hit result is used as a single rule to trigger an early warning signal, or the hit result is used as a scoring item in the scoring system rule and included in the total risk score, thereby realizing the fusion judgment of expert rules and machine learning models.

[0008] In one implementation of this application, for expert rule-based decision-making, risk indicators are retrieved from an indicator cache and judged according to hit-based rule conditions. If all conditions are met, an early warning signal is directly generated; or, points are accumulated according to the preset numerical scores corresponding to each rule condition in the scoring system. If the final total risk score exceeds a preset threshold, an early warning signal is generated. Specifically, this includes: Configure hit rules in the multimodal risk decision engine and define hit rule conditions through the rule management interface; the hit rule conditions include at least age conditions, transaction amount conditions, transaction frequency conditions, and balance conditions; By combining multiple hit-based rule conditions, a hit warning signal is triggered when all the combined conditions are met simultaneously by real-time streaming risk indicators or batch risk indicators. In the multimodal risk decision engine, scoring rules are configured, and numerical scores are assigned to each scoring rule condition; the numerical scores include positive scores and negative scores. When a risk indicator matches a single scoring rule condition, the corresponding score is accumulated, the total score is calculated, and the total score is compared with a preset total score threshold. When the total score exceeds the preset total score threshold, a scoring warning signal is triggered.

[0009] In one implementation of this application, for machine learning model decision-making, risk indicator values ​​are obtained from an indicator cache, an executable file is run to output risk probability values, and the risk probability values ​​are compared with a preset risk probability threshold. If the risk probability value exceeds the preset risk probability threshold, the model rule is determined to have been hit. The hit result is used as a single rule to trigger an early warning signal, or the hit result is used as a scoring item in a scoring system rule and included in the total risk score, thereby realizing the fusion judgment of expert rules and machine learning models. Specifically, this includes: A machine learning model is integrated into the multimodal risk decision engine. A pre-trained executable file is loaded through the pre-trained machine learning model, and multiple risk indicator values ​​are input. The executable file includes PMML format or HTTP format. The machine learning model outputs a risk probability value, which is then compared with a configured probability threshold. If the risk probability value exceeds the probability threshold, a model warning signal is generated. The risk probability value output by the machine learning model is used as the trigger condition for a hit-based rule, or the risk probability value output by the machine learning model is used as a scoring item for a scoring system rule. The rule results and model results are combined to generate the final risk warning signal.

[0010] In one implementation of this application, a risk verification form is generated based on the risk warning signal, and the risk verification form is sent to a designated institution to execute corresponding actions, specifically including: Based on the risk level identifier and rule type information in the risk warning signal, a standardized risk verification form data record is created; the risk verification form data record includes account number, customer identifier, warning trigger timestamp, description of the triggered suspicious characteristics, and a list of associated transaction records; According to the pre-configured handling strategy mapping table, when the handling operation is a real-time transaction blocking operation, the transaction is canceled by calling the core system through the interface; when the handling operation is an account non-counter suspension operation, the account function is restricted through the management interface; when the handling operation is an SMS reminder operation, a risk warning SMS is sent through the message service; and when the handling operation is a verification and distribution operation, the risk verification form is assigned to the corresponding business personnel. For risk warning signals identified as high-risk, the risk verification form is pushed to the business terminal of the corresponding account opening institution, and the account management interface is called simultaneously to implement management. Identify multiple risk warning signals generated within a preset time period at the same account or customer level, merge the corresponding multiple risk verification forms into a comprehensive verification form, and issue it to the corresponding business unit.

[0011] In one implementation of this application, multi-source data is obtained from multiple heterogeneous data sources, specifically including: The gateway front-end service connects to the real-time transaction channel interface to access channel transaction messages and converts the channel transaction messages into structured data streams to obtain real-time channel transaction data; the channel transaction messages include mobile banking transaction messages, online banking transaction messages, ATM transaction messages, and STM transaction messages; Listen for data change events to obtain near real-time change data, and asynchronously retrieve the corresponding data blocks in the form of a message queue; the data change events include changes in core transaction flow and changes in account information. Offline data files are received in batches at the end of each day through an offline scheduling task, and the offline data files are parsed and decoded in batches to obtain offline historical data; the offline data files include at least an account basic information table, a customer basic information table, a historical transaction record table, and a card basic information table; The real-time channel transaction data, the near real-time change data, and the offline historical data are subjected to integrity and consistency verification, and invalid or duplicate data records that pass the verification are removed to generate multi-source data after preliminary verification.

[0012] In one implementation of this application, data governance is performed on the multi-source data to generate a standardized risk dataset, specifically including: The data format of the multi-source data is converted into a data format that can be recognized by the anti-telecom fraud system, and supplementary information on account type and customer type is added from the offline cache, as well as IP address and MAC address resolution information is obtained from the external data interface; The multi-source data after standardization is combined with supplementary information on account type and customer type, as well as IP address and MAC address resolution information to form a complete data record. The real-time collected transaction data is preprocessed to remove non-active transaction types, and each transaction is assigned a corresponding transaction type identifier, amount range identifier, and behavior pattern identifier to generate a standardized risk dataset.

[0013] On the other hand, this application also provides an anti-telecom fraud intelligent early warning device, the device comprising: At least one processor; And, a memory communicatively connected to the at least one processor; The memory stores instructions that can be executed by the at least one processor, which are then executed by the at least one processor to enable the at least one processor to perform an anti-telecom fraud intelligent early warning method as described above.

[0014] On the other hand, this application also provides a non-volatile computer storage medium storing computer-executable instructions, which, when executed, implement the anti-telecom fraud intelligent early warning method described above.

[0015] This application provides an intelligent early warning method, device, and medium for combating telecom fraud, which has at least the following beneficial effects: By acquiring multi-source data from multiple heterogeneous data sources and performing unified governance, a standardized risk dataset is constructed, breaking down the barriers between real-time, near-real-time, and offline data. By integrating real-time data stream processing with batch data computation, a monitoring mechanism covering the entire lifecycle—before, during, and after an event—is established. This mechanism enables real-time identification and interception of fraudulent transactions, effectively blocking channels for the transfer of funds in telecommunications fraud and solving the problem of untimely early warnings. By constructing a multimodal decision engine that combines expert rules and machine learning models, the complementarity of rule judgment and intelligent learning is achieved. Based on early warning signals, verification orders are automatically generated and control actions are triggered, transforming the traditional verification mode that relies on manual experience into a data-driven approach. This not only reduces the time required for a single verification but also optimizes the allocation of risk management resources through mechanisms such as intelligent merging of duplicate early warnings and hierarchical classification and handling. Attached Figure Description

[0016] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings: Figure 1 A flowchart illustrating an intelligent early warning method for combating telecom fraud provided in this application embodiment; Figure 2 This is a schematic diagram of the internal structure of an anti-telecom fraud intelligent early warning device provided in an embodiment of this application. Detailed Implementation

[0017] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0018] The technical solutions provided by the various embodiments of this application are described in detail below with reference to the accompanying drawings.

[0019] Figure 1 This is a flowchart illustrating an intelligent early warning method for combating telecom fraud, provided in an embodiment of this application.

[0020] The analysis method involved in the embodiments of this application can be implemented by a terminal device or a server, and this application does not impose any special limitations on it. For ease of understanding and description, the following embodiments are all described in detail using a server as an example.

[0021] It should be noted that the server can be a single device or a system composed of multiple devices, i.e., a distributed server. This application does not make any specific limitations on this.

[0022] like Figure 1 As shown in the embodiment of this application, an intelligent early warning method for anti-telecom fraud includes: Step 101: Obtain multi-source data from multiple heterogeneous data sources, perform data governance on the multi-source data, and generate a standardized risk dataset.

[0023] It should be noted that the multi-source data in this application embodiment includes real-time data streams, near real-time data streams, and offline data streams, which come from various heterogeneous systems inside and outside the financial institution.

[0024] In this embodiment, the gateway front-end service first connects to various real-time transaction channel interfaces. It should be noted that the gateway front-end service, acting as the access hub between the system and external transaction channels, is deployed with a highly available architecture, capable of handling concurrent requests from multiple channels simultaneously. Specifically, when a customer initiates a transaction through channels such as mobile banking, online banking, ATM, or STM, the channel system pushes transaction messages to the gateway front-end service in real time. The gateway front-end service performs protocol parsing, data decryption, and format conversion on the received raw messages, transforming them into a unified structured data stream. For example, after parsing, the mobile banking transaction message extracts key fields such as transaction account, transaction time, transaction amount, transaction type, and device fingerprint, forming standardized real-time channel transaction data.

[0025] Understandably, near real-time data acquisition is achieved through a near real-time acquisition platform. This platform captures data change events occurring in the core system, such as changes in transaction logs and account information, by monitoring database log changes and message middleware events. Specifically, when the core system completes a transaction or updates account information, the near real-time acquisition platform immediately detects the data change and encapsulates the acquired near real-time change data into a unified message body. This message is then pushed asynchronously to downstream systems via a message queue. This approach minimizes the impact on the source system's performance while ensuring timely data acquisition. For example, when an account's balance changes, the near real-time acquisition platform will package and send the account's latest balance information, the changed amount, and the change time to a message queue shortly after the transaction is completed, for use by the anti-telecom fraud system.

[0026] It should be noted that offline data acquisition is accomplished through offline scheduling tasks. After the daily business hours conclude, the data lake scheduling platform automatically triggers offline data extraction tasks, batch-extracting data files such as account basic information tables, customer basic information tables, historical transaction records, card basic information tables, and customer account opening information tables from various business systems. These data files are compressed and encrypted before being transmitted to the anti-telecom fraud system. Upon receiving the files, the system first decrypts and decompresses them, then performs batch parsing and decoding of the data content, converting it into a standardized format that the system can process internally. For example, the historical transaction record table contains complete records of all transactions within a past period. During the parsing process, the system verifies the legality of the transaction amount and the validity of the transaction time, ensuring the accuracy and completeness of the data.

[0027] The system performs comprehensive integrity and consistency checks on the acquired real-time channel transaction data, near real-time change data, and offline historical data. Specifically, integrity checks include verifying whether required fields are missing and whether the number of data records meets expectations; consistency checks focus on whether the information of an entity across different data sources is consistent, such as whether the account balance obtained from real-time channels matches the balance obtained from near real-time data. For invalid or duplicate data records found during the verification process, the system will remove them and record them in the anomaly log, ultimately generating a preliminarily validated data set for subsequent data governance.

[0028] In this embodiment, data governance of multi-source data begins with data escaping of real-time data from real-time channels. It's important to note that data escaping refers to converting raw data from different channels with varying formats into a unified and recognizable data format within the anti-telecom fraud system. Specifically, the system uses predefined data mapping rules to map transaction message fields from different channels to a unified data model, while escaping special characters and uniformly converting encoding formats. For example, transaction messages from mobile banking might use JSON format, while messages from ATM channels might use XML format. After data escaping, these different formats of data are converted into the system's internal standard object model.

[0029] Understandably, after data escaping, the system supplements account and customer information from the offline cache and obtains IP and MAC address resolution information through external data interfaces. Specifically, the system maintains a distributed cache cluster storing basic information for all accounts and customers. When processing real-time transaction data, the system quickly retrieves the corresponding account type (e.g., corporate account, personal account) and customer type (e.g., individual customer, enterprise customer) from the cache based on the transaction account. Simultaneously, the system calls external data service interfaces to obtain corresponding geographic location information based on the transaction's IP address and device manufacturer information based on the MAC address. This supplementary information significantly enriches the dimensions of the original transaction data, providing more basis for subsequent risk analysis.

[0030] Data concatenation is a crucial step in integrating and associating escaped real-time data with various supplementary information. Specifically, the system uses the transaction serial number as the primary key to associate real-time transaction data, account type information, customer type information, IP address resolution results, and MAC address resolution results, forming a complete data record containing multi-dimensional information. For example, after data concatenation, an online banking transfer transaction not only includes basic information such as the transaction amount and time, but also supplements information such as the account type, customer risk level, geographical location of the transaction IP, and characteristics of the transaction device. The integration of this information lays the foundation for a comprehensive assessment of transaction risk.

[0031] It's important to note that preprocessing near-real-time transaction data is a crucial step in data governance. Preprocessing primarily involves two aspects: first, eliminating non-initiated transactions; and second, using a tagging engine to assign multi-dimensional labels to transactions. Specifically, the system identifies and filters out automatically initiated non-initiated transactions using predefined rules, such as interest settlement transactions, system account adjustment transactions, and batch payment / collection transactions, ensuring that subsequent risk analysis focuses on customer-initiated transactions. Simultaneously, the tagging engine automatically adds transaction type identifiers (e.g., transfer, consumption, inquiry), amount range identifiers (e.g., large, medium, small), and behavior pattern identifiers (e.g., nighttime transactions, cross-regional transactions, high-frequency transactions) to each transaction based on its characteristics. These labels not only facilitate subsequent indicator calculations and rule judgments but also provide a rich feature engineering foundation for machine learning models. Through this data governance process, a standardized risk dataset is ultimately generated.

[0032] Step 102: Based on the standardized risk dataset, the computing engine performs indicator calculations to generate multiple risk indicators, and inputs the risk indicators into the multimodal risk decision engine to execute expert rule decisions and machine learning model decisions in parallel, generating risk warning signals.

[0033] In this embodiment, a standardized risk dataset that has undergone data governance is first accessed through a real-time indicator calculation engine. It should be noted that the real-time indicator calculation engine is a computing framework designed for processing streaming data. It continuously receives real-time data streams after data governance and defines various time windows. Specifically, when the system starts or business rules change, real-time risk indicators are dynamically calculated based on preset time windows. It should be noted that time windows include two main types: sliding windows and rolling windows. Sliding windows slide continuously along the time axis at a fixed length, with each window containing data within a specific time period, and adjacent windows overlapping. Rolling windows divide the data stream into non-overlapping continuous windows according to fixed time intervals. For sliding windows, the data stream is divided into overlapping time periods based on event timestamps, such as generating a 60-minute window every 5 minutes. For rolling windows, continuous non-overlapping time periods are generated, such as 1-3 minutes for the first window, 4-6 minutes for the second window, and so on. After the first window ends, it scrolls to the second window, and after the second window ends, it continues scrolling to the next window. For example, the system is configured with a sliding window of 1 hour to calculate the account's cumulative transaction amount in the past hour. This window slides once per minute to ensure that transaction data in the most recent hour is always available. At the same time, a rolling window of 24 hours is configured to calculate the number of transactions in the past 24 hours. This window is updated at midnight every day to provide complete daily transaction statistics.

[0034] After loading the batch-processed wide table, the system divides the data into contiguous shards based on time (e.g., transaction dates) and assigns them to distributed executors. Each executor is responsible for storing and computing a specific set of shards, while registering the shard's metadata (e.g., time range, data volume) with the global coordinator. Forward processing is automatically triggered by a time window, such as calculating the latest indicators at midnight each day, with executors processing data sequentially according to shard order. Reverse processing is triggered by specific events, with executors processing shards in reverse order, such as data backfilling or error correction requests. During this process, the bidirectional processors synchronize their states using a time-series coordination algorithm. When reverse processing modifies data in a shard, the algorithm notifies the forward processor to update subsequent calculation results dependent on that shard. The distributed executors exchange shard processing states through a message broker (e.g., RabbitMQ), and finally, the aggregation node merges the bidirectional results to form a consistent risk indicator output, ensuring seamless integration of full and incremental computations.

[0035] It's important to note that intermediate processing results generated during the computation of streaming data are persisted to high-performance memory storage, forming a multi-dimensional data cube structure. Specifically, the multi-dimensional data cube is a unique data organization structure that uses multiple dimensions such as account, time, and transaction type as axes, storing various intermediate calculation results at the corresponding dimensional intersections. This structural design allows the system to quickly locate and retrieve indicator values ​​under specific dimensional combinations, while supporting high-frequency data updates and fast queries. For example, when new transaction data flows in, the system only needs to update the values ​​of the affected dimensional intersections, without recalculating the entire indicator system; when the decision engine needs to query a specific indicator for an account, the system can directly retrieve the value from the corresponding dimensional intersection, significantly reducing query latency.

[0036] In batch indicator calculation, a time-series coordination algorithm divides the time axis into continuous windows, such as daily or monthly shards, based on configuration parameters like window length and movement intervals, and assigns each window's data shard to a distributed executor. For example, when processing the number of trading counterparties over the past 90 days, the window is initially divided into 90 daily shards, with each executor responsible for aggregating data from a specific shard. When a window needs to be moved, such as expanding from 90 days to 120 days, the time-series coordination algorithm monitors a 90-day time threshold and triggers a movement event when 90 days are reached. The newly added 30-day data shard is assigned to an idle executor. The time-series coordination algorithm compares the old and new window states through the time-series coordinator, performing incremental calculations only on the new shards while reusing the snapshot results from the old window. Executors communicate with each other via message queues (such as Kafka) to synchronize window states. If an executor fails, the time-series coordination algorithm automatically switches to a backup node based on the snapshot, ensuring computational continuity. The entire process achieves seamless switching between full calculation (initial window) and incremental calculation (window movement), improving throughput.

[0037] In this embodiment, the system employs a parallel processing mechanism to simultaneously execute expert rule-based decisions and machine learning model decisions. It should be noted that the multimodal risk decision engine is an intelligent decision-making system that supports the collaborative operation of multiple decision-making modes; it can simultaneously handle rule-based judgments based on expert experience and data-driven model inference.

[0038] Specifically, for expert rule-based decision-making, the system first retrieves various risk indicator values ​​processed by the calculation engine from the indicator cache. These indicator values ​​are organized in the cache at multiple levels, such as account dimension and time dimension, supporting fast reading and updating. Expert rule-based decision-making is further divided into two processing modes: hit-based rule judgment and scoring-based rule judgment. In hit-based rule judgment, the system performs logical judgment according to pre-configured rule conditions, and generates an early warning signal directly when all conditions are met simultaneously. In scoring-based rule judgment, the system accumulates points based on the preset numerical score corresponding to each rule condition, and generates an early warning signal when the final total risk score exceeds a preset threshold. It should be noted that in this embodiment, the preset threshold corresponding to the total risk score is 10 points. The preset threshold can be adjusted according to the actual situation, and this application does not specifically limit it.

[0039] Understandably, the configuration of hit-based rules is done through the rule management interface. Business personnel can intuitively define various rule conditions, including age conditions, transaction amount conditions, transaction frequency conditions, balance conditions, and cumulative transaction conditions within a specified time period. Specifically, the age condition is used to determine whether the customer's age falls within a specific range; the transaction amount condition is used to monitor whether the transaction amount exceeds or falls below a set standard; the transaction frequency condition is used to count the transaction frequency within a specific time window; and the balance condition focuses on the account balance status after a transaction. The system uses logical operators to combine these conditions into complete rule logic. When real-time streaming risk indicators or batch risk indicators simultaneously meet all combined conditions, a hit warning signal is automatically triggered. For example, a typical hit-based rule can be configured such that the customer's age is greater than a set threshold, the cumulative transaction amount in the past 24 hours is greater than a set threshold, and the post-transaction balance is less than a set threshold. When all these conditions are met simultaneously, the system will immediately generate a high-risk warning signal. For example, taking the platform's configuration rule for large transactions by the elderly as an example, there are several triggering conditions: A: Age greater than or equal to 60 years old; B: Cumulative transaction amount in the past 24 hours greater than or equal to 50,000; C: Cumulative number of transactions with a balance less than 500 after the transaction is completed greater than or equal to 3; D: Cumulative number of transactions in the past 24 hours greater than or equal to 6. The rule is composed of A, B, C, and D. When a transaction enters, it enters the decision engine. The engine retrieves the calculated indicators from the cache and judges them according to the conditions assembled by the rule. If the conditions are met, an alert is generated. This method is a hit-based rule. It should be noted that in the above example, the age threshold is set to 60 years old, the cumulative transaction amount in the past 24 hours is set to 50,000, and the balance after the transaction is set to 500.

[0040] The system assigns specific numerical scores to each scoring rule condition. These scores include both positive bonuses and negative deductions, more accurately reflecting the importance of different risk characteristics. Specifically, when a risk indicator matches a single scoring rule condition, the system accumulates the corresponding score, calculates the total score in real time through the scoring accumulation module, and compares the total score with a preset threshold. For example, there are 5 rules: A: Large transactions by elderly people, B: Frequent transactions at night, C: Sudden activation of inactive accounts, D: Short-term quick in-and-out transactions, and E: Centralized inflows and dispersed outflows. Each rule is assigned a score, such as 3 for rule A, 4 for rule B, 5 for rule C, 1 for rule D, and 2 for rule E, with a preset threshold of 10 points. After the transaction record enters the decision engine, it will be scored according to these 5 rules. If all 5 rules are met, the system will accumulate all scores, and the final score of the transaction will be 3+4+5+1+2=15 points. Since the final score of 15 points for the transaction exceeds the preset threshold of 10 points, it indicates that the transaction has risks, and a warning signal and warning order of the corresponding level will be generated.

[0041] The machine learning model in this application employs a dual-model architecture of Gradient Boosting Decision Tree (GBDT) and Deep Neural Network (DNN). The GBDT model handles structured features, such as transaction amount and frequency, integrating multiple weak classifiers through a tree structure, making it suitable for capturing non-linear relationships between features. The DNN model handles sequential data, such as transaction time series, mining deep patterns through a multilayer perceptron. The model input consists of 20-dimensional standardized risk indicators, including the cumulative transaction amount in the past hour, the number of transactions in the past 24 hours, customer age, account opening duration, and customer asset level. These features are Z-score standardized before being input into the machine learning model to eliminate the influence of dimensions. After the processed risk indicators are input into the machine learning model, the output layer uses the Sigmoid function to generate a risk probability value between 0 and 1, representing the confidence level of whether a transaction is suspected of being fraudulent.

[0042] The machine learning model is trained based on historical transaction data, which includes positive samples (confirmed fraudulent transactions) and negative samples (normal transactions). For example, data from the past 12 months is used as the training set, and the most recent 3 months as the test set. The training process begins with feature selection, filtering out the top 5 most discriminative features, followed by hyperparameter adjustment. The trained model is integrated into the multimodal risk decision engine via either PMML or HTTP format. It should be noted that PMML format is used for static model deployment, suitable for simple GBDT models; the HTTP interface is used for dynamic model services, supporting real-time updates of DNN models. During inference, the engine retrieves real-time risk indicator values ​​from the indicator cache and inputs these values ​​into the trained machine learning model to obtain risk probability values. These probability values ​​participate in decision-making in two ways: first, as an independent rule, directly triggering an alert when the probability value exceeds a preset threshold (e.g., 0.995); second, as a scoring item integrated into expert rules, for example, converting the probability value linearly to a score of 1-10 and including it in the total risk score. This integration mechanism is implemented through a configurable strategy, allowing business personnel to dynamically adjust model weights and thresholds.

[0043] The system loads pre-trained executable files, such as PMML and HTTP formats, through a machine learning model, providing a unified integration method for different types of machine learning models. After the machine learning model parses the executable file, the system retrieves the corresponding risk indicators from the indicator cache according to the agreed-upon input order. For example, there are 20 risk indicators, including the cumulative transaction amount in the past hour, the cumulative number of transactions in the past 24 hours, customer age, account opening duration, customer assets, and the cumulative number of unique counterparties in the past 6 hours. These risk indicators are configured according to the input order and undergo rigorous standardization to ensure they meet the model's input requirements. The machine learning model specifies two output fields: one tending towards 1 and the other towards 0. In risk control scenarios, the value tending towards 1 is used as the risk probability value, reflecting the degree of risk of the current transaction or account being suspected of telecommunications fraud. After configuring the machine learning model, a rule is configured based on the risk indicator items of the machine learning model. This rule can be applied using a hit-based rule or a scoring rule. For example, if a hit-based rule is configured with conditions A: the risk probability threshold of the machine learning model tending towards 1 is greater than or equal to 0.995, and B: the cumulative number of transactions per day is greater than or equal to 3, the combined conditions of this rule are A&B. The transaction log is input into the decision engine, which retrieves the corresponding values ​​from the cache according to the risk indicators configured in the machine learning model, runs the executable file, and outputs the risk probability threshold corresponding to the transaction log, such as 0.999, and the cumulative number of transactions per day, which is 4. The system compares the output risk probability threshold of 0.999 with the configured risk probability threshold of 0.995. Since the output exceeds the threshold in the hit-based rule, and the cumulative number of transactions per day (4) also exceeds the number of transactions (3) in the hit-based rule, a model warning signal is triggered.

[0044] Understandably, the output of machine learning models can participate in risk decision-making in multiple ways. It can directly trigger warning signals as a single rule, or it can be included in the total risk score as a scoring item in a scoring system. Specifically, in the fusion decision-making mode, the system converts the risk probability threshold output by the machine learning model into a form recognizable by the rule engine. This can serve as a specific trigger condition for hit-based rules, or it can be converted into a score value in a scoring system according to a specific conversion rule for cumulative calculation. For example, the system can be configured with a fusion rule where the machine learning model's risk probability is greater than 0.95, or the age condition and transaction amount condition are met, and the model's risk probability is greater than 0.8. This configuration leverages the machine learning model's advantage in recognizing complex patterns while retaining the judgment ability of expert rules in specific scenarios. Through this deep fusion mechanism, the system can more comprehensively and accurately identify various types of telecom fraud risks, improving the coverage and accuracy of risk prevention and control.

[0045] Step 103: Generate a risk verification form based on the risk warning signal and issue the risk verification form to the designated agency to carry out the corresponding disposal actions.

[0046] It should be noted that the actions taken in this application embodiment include transaction blocking, account management, and verification issuance.

[0047] In this embodiment, the system first creates standardized risk verification form data records based on the risk level identifier and rule type information contained in the risk warning signal. It should be noted that the risk level identifier is automatically assigned by the multimodal risk decision engine based on rule hit rate or scoring results, typically divided into high, medium, and low risk levels. Different risk levels correspond to different levels of urgency and verification requirements. The rule type information records the specific rule or model category that triggered the warning, such as the frequent nighttime transaction rule or the machine learning fraud identification model. Specifically, the system automatically assembles complete verification form records through the verification form generation module. These records include core elements such as account number, customer identifier, warning trigger timestamp, description of the triggered suspicious characteristics, and a list of associated transaction flows. For example, when the system identifies that an account has triggered a small-amount test followed by a large-amount transfer rule, the verification form records detailed information about the account, the trigger time, and a description of specific suspicious characteristics. For instance, the description of suspicious characteristics might be, "Multiple small-amount test transactions followed by an immediate large-amount transfer occurred within the past hour," and all related transaction flows are arranged chronologically to form a complete chain of evidence.

[0048] Understandably, after a verification form is generated, the system will trigger corresponding actions based on a pre-configured handling strategy mapping table. This table is a key configuration table defining the handling methods corresponding to different risk levels and rule types, clarifying what handling measures should be taken under what risk circumstances. Specifically, when the handling action is a real-time transaction blocking operation, the system calls the core system's transaction suspension function through a dedicated interface service to intercept ongoing suspicious transactions in real time; when the handling action is a non-counter account suspension operation, the system restricts the account's non-counter business functions such as e-banking, mobile banking, and ATMs through the account management interface; when the handling action is an SMS alert operation, the system sends a risk warning SMS to the customer through the message service platform; and when the handling action is a verification issuance operation, the system uses a workflow engine to assign the risk verification form to the corresponding business personnel for subsequent verification according to a preset allocation logic. The execution of these handling actions is fully automated, requiring no manual intervention, ensuring timely risk response.

[0049] In this embodiment, the system employs a special direct-send processing logic for risk warning signals identified as high-risk. It should be noted that this direct-send logic is a special process designed to handle urgent high-risk situations, allowing the system to bypass conventional multi-layered approval processes and directly push the risk verification form to the account opening institution's business terminal. Specifically, when the system identifies a warning signal as high-risk, the verification form distribution module immediately activates the direct-send channel, sending the corresponding risk verification form to the account opening branch's business processing system in real time via a message push mechanism, while simultaneously invoking the account management interface to implement automatic control measures. For example, when the system detects that an account has triggered a fraudulent blacklist transaction and is determined to be high-risk, it immediately suspends all non-counter services for that account while generating the risk verification form, and directly pushes the risk verification form to the account opening branch's pending task list, ensuring that the risky account is effectively controlled at the first opportunity.

[0050] The system also provides a risk verification form merging function to optimize the allocation of verification resources. Specifically, based on key fields such as account number and customer identifier, it performs similarity matching, while also considering factors such as time proximity and correlation of risk characteristics. For multiple risk warning signals generated within a preset time period at the same account or customer level, it automatically identifies duplicate or highly related warning records. When multiple related warning signals are identified, the system merges the corresponding risk verification forms into a single comprehensive verification form. This comprehensive verification form contains complete data such as all rules that triggered the warnings, time distribution, and transaction history. For example, if an account triggers multiple rules such as frequent nighttime transactions, logins from different locations, and large transfers within a short period, the system will merge these independent warnings into a comprehensive multi-suspicious feature verification form. This allows business personnel to fully understand all the risk behaviors of the account during processing, avoiding efficiency losses caused by duplicate verifications. The merged comprehensive verification form will reassess the risk level and be issued to the corresponding business unit according to the optimized handling process, significantly improving the efficiency and quality of the verification work.

[0051] The above are embodiments of the method proposed in this application. Based on the same inventive concept, embodiments of this application also provide an intelligent early warning device for anti-telecom fraud, the structure of which is as follows: Figure 2 As shown.

[0052] Figure 2 This is a schematic diagram of the internal structure of an anti-telecom fraud intelligent early warning device provided in an embodiment of this application. Figure 2 As shown, the device includes: At least one processor; And, a memory that is communicatively connected to at least one processor; The memory stores instructions that can be executed by at least one processor, and the instructions, when executed by at least one processor, enable at least one processor to: Multi-source data is acquired from multiple heterogeneous data sources, and data governance is performed on the multi-source data to generate a standardized risk dataset. The multi-source data includes real-time data streams, near-real-time data streams, and offline data streams. Data governance includes data splicing, data cleaning, and data labeling. Based on a standardized risk dataset, the computing engine performs indicator calculations to generate multiple risk indicators, which are then input into a multimodal risk decision engine to execute expert rule decisions and machine learning model decisions in parallel, generating risk warning signals. Risk verification orders are generated based on risk warning signals and then sent to designated institutions to carry out corresponding actions. These actions include transaction blocking, account control, and verification issuance.

[0053] This application also provides a non-volatile computer storage medium storing computer-executable instructions, which, when executed, can: Multi-source data is acquired from multiple heterogeneous data sources, and data governance is performed on the multi-source data to generate a standardized risk dataset. The multi-source data includes real-time data streams, near-real-time data streams, and offline data streams. Data governance includes data splicing, data cleaning, and data labeling. Based on a standardized risk dataset, the computing engine performs indicator calculations to generate multiple risk indicators, which are then input into a multimodal risk decision engine to execute expert rule decisions and machine learning model decisions in parallel, generating risk warning signals. Risk verification orders are generated based on risk warning signals and then sent to designated institutions to carry out corresponding actions. These actions include transaction blocking, account control, and verification issuance.

[0054] The various embodiments in this application are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the device and medium embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the description of the method embodiments.

Claims

1. A smart early warning method for combating telecom fraud, characterized in that, The method includes: Multi-source data is obtained from multiple heterogeneous data sources, and data governance is performed on the multi-source data to generate a standardized risk dataset; the multi-source data includes real-time data streams, near real-time data streams, and offline data streams, and the data governance includes data splicing, data cleaning, and data tagging. Based on the standardized risk dataset, the computing engine performs index calculations to generate multiple risk indicators, which are then input into a multimodal risk decision engine to execute expert rule decisions and machine learning model decisions in parallel, thereby generating risk warning signals. Based on the risk warning signal, a risk verification form is generated and issued to the designated institution to carry out corresponding handling actions; the handling actions include transaction blocking, account control and verification issuance.

2. The intelligent early warning method for anti-telecom fraud according to claim 1, characterized in that, Based on the standardized risk dataset, a computing engine performs indicator calculations to generate multiple risk indicators, including: The standardized risk dataset is accessed through a real-time indicator calculation engine, and real-time risk indicators are dynamically calculated within a preset time window; the time window includes a sliding window and a scrolling window. Load the batch-processed wide table of data and perform incremental calculations on the full offline data to obtain long-term batch risk indicators. During real-time indicator calculation, intermediate processing results of streaming data are persisted to memory storage, forming a multi-dimensional data cube structure that allows for data updates and indicator queries.

3. The intelligent early warning method for anti-telecom fraud according to claim 1, characterized in that, The risk indicators are input into a multimodal risk decision engine to execute expert rule-based decision-making and machine learning model-based decision-making in parallel, generating risk warning signals, specifically including: For expert rule-based decision-making, risk indicators are obtained from the indicator cache and judged according to the hit-based rule conditions. If all conditions are met, an early warning signal is generated directly, or the preset numerical score corresponding to each rule condition in the scoring system is accumulated and added. If the final total risk score exceeds the preset threshold, an early warning signal is generated. For machine learning model decision-making, risk indicator values ​​are obtained from the indicator cache, the executable file is run to output risk probability values, and the risk probability values ​​are compared with preset risk probability thresholds. If the risk probability value exceeds the preset risk probability threshold, the model rule is determined to be hit. The hit result is used as a single rule to trigger an early warning signal, or the hit result is used as a scoring item in the scoring system rule and included in the total risk score, thereby realizing the fusion judgment of expert rules and machine learning models.

4. The intelligent early warning method for anti-telecom fraud according to claim 3, characterized in that, For expert rule-based decision-making, risk indicators are retrieved from the indicator cache and judged according to the hit-based rule conditions. If all conditions are met, an early warning signal is generated directly, or points are accumulated according to the preset numerical scores corresponding to each rule condition in the scoring system. If the final total risk score exceeds a preset threshold, an early warning signal is generated. Specifically, this includes: Configure hit rules in the multimodal risk decision engine and define hit rule conditions through the rule management interface; the hit rule conditions include at least age conditions, transaction amount conditions, transaction frequency conditions, and balance conditions; By combining multiple hit-based rule conditions, a hit warning signal is triggered when all the combined conditions are met simultaneously by real-time streaming risk indicators or batch risk indicators. In the multimodal risk decision engine, scoring rules are configured, and numerical scores are assigned to each scoring rule condition; the numerical scores include positive scores and negative scores. When a risk indicator matches a single scoring rule condition, the corresponding score is accumulated, the total score is calculated, and the total score is compared with a preset total score threshold. When the total score exceeds the preset total score threshold, a scoring warning signal is triggered.

5. The intelligent early warning method for anti-telecom fraud according to claim 3, characterized in that, For machine learning model decision-making, risk indicator values ​​are retrieved from the indicator cache, the executable file is run to output risk probability values, and these risk probability values ​​are compared with a preset risk probability threshold. If the risk probability exceeds the preset threshold, the model rule is determined to have been hit. The hit result is used as a single rule to trigger an early warning signal, or the hit result is used as a scoring item in a scoring system rule and included in the total risk score. This achieves the fusion judgment of expert rules and machine learning models, specifically including: A machine learning model is integrated into the multimodal risk decision engine. A pre-trained executable file is loaded through the pre-trained machine learning model, and multiple risk indicator values ​​are input. The executable file includes PMML format or HTTP format. The machine learning model outputs a risk probability value, which is then compared with a configured probability threshold. If the risk probability value exceeds the probability threshold, a model warning signal is generated. The risk probability value output by the machine learning model is used as the trigger condition for a hit-based rule, or the risk probability value output by the machine learning model is used as a scoring item for a scoring system rule. The rule results and model results are combined to generate the final risk warning signal.

6. The intelligent early warning method for anti-telecom fraud according to claim 1, characterized in that, Based on the aforementioned risk warning signal, a risk verification form is generated and issued to the designated agency to execute corresponding actions, specifically including: Based on the risk level identifier and rule type information in the risk warning signal, a standardized risk verification form data record is created; the risk verification form data record includes account number, customer identifier, warning trigger timestamp, description of the triggered suspicious characteristics, and a list of associated transaction records; According to the pre-configured handling strategy mapping table, when the handling operation is a real-time transaction blocking operation, the transaction is canceled by calling the core system through the interface; when the handling operation is an account non-counter suspension operation, the account function is restricted through the management interface; when the handling operation is an SMS reminder operation, a risk warning SMS is sent through the message service; and when the handling operation is a verification and distribution operation, the risk verification form is assigned to the corresponding business personnel. For risk warning signals identified as high-risk, the risk verification form is pushed to the business terminal of the corresponding account opening institution, and the account management interface is called simultaneously to implement management. Identify multiple risk warning signals generated within a preset time period at the same account or customer level, merge the corresponding multiple risk verification forms into a comprehensive verification form, and issue it to the corresponding business unit.

7. The intelligent early warning method for anti-telecom fraud according to claim 1, characterized in that, Obtaining multi-source data from multiple heterogeneous data sources, specifically including: The gateway front-end service connects to the real-time transaction channel interface to access channel transaction messages and converts the channel transaction messages into structured data streams to obtain real-time channel transaction data; the channel transaction messages include mobile banking transaction messages, online banking transaction messages, ATM transaction messages, and STM transaction messages; Listen for data change events to obtain near real-time change data, and asynchronously retrieve the corresponding data blocks in the form of a message queue; the data change events include changes in core transaction flow and changes in account information. Offline data files are received in batches at the end of each day through an offline scheduling task, and the offline data files are parsed and decoded in batches to obtain offline historical data; the offline data files include at least an account basic information table, a customer basic information table, a historical transaction record table, and a card basic information table; The real-time channel transaction data, the near real-time change data, and the offline historical data are subjected to integrity and consistency verification, and invalid or duplicate data records that pass the verification are removed to generate multi-source data after preliminary verification.

8. The intelligent early warning method for anti-telecom fraud according to claim 7, characterized in that, Data governance is performed on the multi-source data to generate a standardized risk dataset, specifically including: The data format of the multi-source data is converted into a data format that can be recognized by the anti-telecom fraud system, and supplementary information on account type and customer type is added from the offline cache, as well as IP address and MAC address resolution information is obtained from the external data interface; The multi-source data after standardization is combined with supplementary information on account type and customer type, as well as IP address and MAC address resolution information to form a complete data record. The real-time collected transaction data is preprocessed to remove non-active transaction types, and each transaction is assigned a corresponding transaction type identifier, amount range identifier, and behavior pattern identifier to generate a standardized risk dataset.

9. An intelligent early warning device for anti-telecom fraud, characterized in that, The device includes: At least one processor; And, a memory communicatively connected to the at least one processor; The memory stores instructions that can be executed by the at least one processor, which are executed by the at least one processor to enable the at least one processor to perform an anti-telecom fraud intelligent early warning method as described in any one of claims 1-8.

10. A non-volatile computer storage medium storing computer-executable instructions, characterized in that, When the computer-executable instructions are executed, they implement the anti-telecom fraud intelligent early warning method as described in any one of claims 1-8.

Images