A Monitoring Method and Device for Anti-Money Laundering Suspicious Transaction Data

Abstract

The present invention relates to the field of information technology and provides a method and device for monitoring suspicious transaction data for anti-money laundering. The main purpose is to solve the problem of adding verification steps during data transmission, storage, and processing to prevent the loss of file numbers and file fields, and to avoid errors in the basic logic of field information, which directly affects the quality of data analysis. The solution includes a data source detection task, which implements system clock scanning and obtains the data preparation status of the upstream system. When the upstream system generates a file containing customer money laundering data in a file sharing area, it marks the data as ready; otherwise, it continues to wait; when searching for a file generated by the upstream system in the file sharing area, it extracts data to obtain anti-money laundering data, which includes customer data, transaction data, and account data; generates the basic data table based on the anti-money laundering data; and calls an anti-money laundering suspicion model to screen the basic data table and generate screening results.

Description

Technical Field

[0001] The present invention relates to the field of information technology and provides a method and device for monitoring suspicious transaction data for anti-money laundering. Background Art

[0002] With the rapid development of China's economy, FinTech, represented by big data, cloud computing, and blockchain, is gaining traction in the financial sector. The industry's data computing capabilities have significantly increased, credit assessment capabilities have achieved breakthroughs, and risk management has been effectively enhanced. The enhanced business capabilities of financial institutions have led to rapid growth in the variety, speed, and efficiency of their services, and the volume of transaction data generated daily is also growing. Accurately identifying suspicious entities within this massive amount of data is becoming increasingly difficult.

[0003] Suspicious transaction monitoring will accumulate and incorporate customer information from multiple sources. Once an account transaction matches a suspicious transaction monitoring model, an intelligent suspicious transaction monitoring system, built on this data, will automatically issue an alert. Artificial intelligence technology will analyze customer behavior based on past transactions, identifying unusual transactions and uncovering potential illegal or criminal activity. This will effectively address the limitations of the "model screening + list monitoring + manual screening" monitoring model and significantly enhance the effectiveness of financial institutions' anti-money laundering efforts. Comprehensive analysis of unusual customer transactions, using data collected from diverse sources, can effectively integrate massive amounts of internal and external customer data, enabling effective and in-depth analysis and processing of unusual customer transactions. Compared to human judgment and human capital, this technology is more reliable, faster, and more cost-effective. Implementing unusual behavior alerts within the system will help humans promptly identify new money laundering crimes. Furthermore, AI will also facilitate routine anti-money laundering data detection, collection, and identification tasks, such as identifying ultimate beneficial owners and re-entering accounts.

[0004] This technology is used in the field of anti-money laundering suspicious transaction monitoring, effectively solving the problem of a substantial increase in the amount of transaction data from financial institutions received by the anti-money laundering database and the number of transactions monitored every day reaching new highs. Summary of the Invention

[0005] This solution mainly solves the following problems:

[0006] Ensure authenticity: Add verification steps during data transmission, storage, and processing to prevent missing file numbers or file fields, and avoid errors in the basic logic of field information, which directly affect the quality of data analysis.

[0007] In order to solve the above problems, the present invention adopts the following technical solutions:

[0008] A method for monitoring suspicious transaction data for anti-money laundering, the method comprising:

[0009] Step S1, data source detection task, uses java.util.Timer to implement system clock scanning, and obtains the data preparation status of the upstream system through the data preparation flag. When the upstream system generates the SYM_YYYYMMDD.ok file containing the customer's money laundering data in the file sharing area, it indicates that the data has been prepared. Otherwise, continue waiting;

[0010] Step S2: When the upstream system generates the file SYM_YYYYMMDD.ok in the file sharing area in step S1, data extraction is performed to obtain anti-money laundering data, which includes customer data, transaction data, and account data.

[0011] Step S3: generating the basic data table according to the date, transaction type and transaction channel corresponding to the anti-money laundering data;

[0012] Step S4: calling the anti-money laundering suspicious model to perform data screening on the basic data table and generate a screening result;

[0013] Step S5: Using the screening results, executing SQL statements according to the rules, determining suspicious transactions, and loading customers that meet the requirements into the anti-money laundering case table;

[0014] Step S6: aggregate and count the data in the anti-money laundering case table, archive the information, clean the data, and present the customer to the front desk. Then, the bank's business personnel manually screen the case. If it is suspicious, it will be reported to the People's Bank of China. If it is not suspicious, it will be excluded.

[0015] In the above technical solution, extracting the data source task data includes: Step 2 includes the following steps:

[0016] Step 2.1. Create a stealth file: Create a guard process in the background. The guard process creates an empty file aml.sok and opens the file through the open() function. Then, it calls the Unix system command ulink to forcibly cancel the hard link of the file, making the file invisible. Unless the guard process exits abnormally or exits, the file will always exist. The main function of this step is to prevent the background guard process from being executed repeatedly and to establish the aml.sok socket service.

[0017] Step 2.2: The Guardian process scans the specified file area for SYM_YYYYMMDD.ok every 5 minutes to see if it has been created. YYYYMMDD is the date to be loaded. If the file is found, the value of the i_ready variable in the Guardian process is rewritten to 1. Otherwise, it defaults to 0.

[0018] In step 2.3, the money laundering client initiates an inquiry message by accessing the aml.sok socket service. After receiving the inquiry message, the guard process sends the value of i_ready to the anti-money laundering client. If the value of i_ready is 0, the anti-money laundering client enters sleep mode for 15 minutes. If the value of i_ready is 1, it initiates FTP data access and obtains the SYM_YYYYMMDD.ok file from the upstream system to obtain the customer's anti-money laundering data, including customer, account, and transaction data files and control files. The data files are used for anti-money laundering model analysis, and the control files describe the size of the corresponding data files, MD5 values, and configuration information of each data field.

[0019] In the above technical solution, step 3 includes:

[0020] Step 3.1, first access the calendar table mc00_datatime to obtain the current date for which data needs to be obtained;

[0021] Step 3.2: Perform MD5 calculations on the customer, account, and transaction data files, and compare the resulting MD5 values with the corresponding customer, account, and transaction control files. If the MD5 values of the two are consistent, the number and fields of the data files are consistent with those of the upstream system. This step ensures the authenticity of the system data source, thereby fundamentally ensuring the authenticity of the entire system.

[0022] Step 3.3 compares the field configuration information in the control file with the field configuration information recorded in the configuration table mc00_ds_tables. If they match, the file can be loaded and used directly. If not, the corresponding table in the database needs to be adjusted. An automated script is called to adjust the base table to match the configuration information in the control file. Based on the Java program and the configuration table mc00_ds_tables, a shell script is called to load the upstream data file into the anti-money laundering database metadata table. This step ensures timely system adjustments and improves system robustness. Changes to individual upstream system fields do not require significant manual adjustments to the system.

[0023] Shell script configuration instructions:

[0024] userid--ORACLE username / password

[0025] control-control file

[0026] log-log file

[0027] * indicates that the data file is after the control file. If it is an independent data file, replace the file with *

[0028] bad-bad data file, records incorrect unloaded data

[0029] data-data file, *data parameter can only specify one data file. If the control file also specifies the data file through infile, and specifies multiple data files, sqlldr will load the first one when it is executed.

[0030] The data file specified by the data parameter, the first data file specified by infile in the control file is ignored, but the data files specified by subsequent infiles continue to be valid

[0031] discard-discarded data files, not generated by default, must be specified

[0032] discardmax - the maximum value of data allowed to be discarded (all defaults)

[0033] skip -- skips the number of records. Count the number of rows to skip starting from the first row in the data file. * For multi-table loading, if there is a when condition, or if multi-table loading is done directly, this parameter is invalid if the number of records to be loaded is different.

[0034] errors - the number of error records allowed, if exceeded, the task will be terminated

[0035] In the above technical solution, in step 4, the money laundering suspicion model is executed in parallel on multiple nodes. The specific algorithm is:

[0036] 4a. By performing hash calculation on the customer numbers in the anti-money laundering data, the customer data is evenly distributed across several computing nodes;

[0037] 4b. Associate the customer table with the account table to distribute the account data to the same computing nodes as the corresponding customers.

[0038] 4c. By associating the account table with the transaction table, the transaction data is distributed on the same computing nodes as the corresponding accounts and customers;

[0039] 4d. Anti-money laundering customer, account, and transaction data are distributed across several computing nodes, enabling data parallel computing and improving the computational efficiency of suspicious anti-money laundering rules. However, it is necessary to prevent broadcast noise between multiple nodes. To this end, by executing steps 4a, 4b, and 4c, since the customer, account, and transaction data of the same customer are distributed on the same computing node, broadcast communication between computing nodes is eliminated at the data level, thereby improving the efficiency of data distribution computing.

[0040] In the above technical solution, in step 4, calling the anti-money laundering suspicious model to screen the data in the basic data table and generating the screening results includes: using preset calling rules, calling the corresponding anti-money laundering suspicious model to screen the data in the basic data table and generating the screening results, wherein the screening results include suspicious transaction data, suspicious customer information and suspicious account data.

[0041] Anti-money laundering rules are divided into two categories: large-value monitoring rules and suspicious-value monitoring rules. Large-value monitoring rules refer to the mandatory individual or corporate transaction data published by the People's Bank of China. Suspicious-value monitoring rules target eight major types of money laundering: telecommunications fraud, underground banking, drug-related activities, gambling-related activities, illegal fundraising, pyramid schemes, illegal cash withdrawals, and illegal tax evasion. Anti-money laundering rules are executed by executing various types of dedicated stored procedures in the database.

[0042] A monitoring device for anti-money laundering suspicious transaction data, comprising:

[0043] The data source detection module, which is a data source detection task, uses java.util.Timer to implement system clock scanning and obtain the data preparation status of the upstream system by marking the data preparation. When the upstream system generates the SYM_YYYYMMDD.ok file containing the customer's money laundering data in the file sharing area, it indicates that the data has been prepared. Otherwise, it continues to wait.

[0044] The data extraction module extracts data when it finds the SYM_YYYYMMDD.ok file generated by the upstream system in the file sharing area, and obtains anti-money laundering data, which includes customer data, transaction data, and account data.

[0045] Basic data table module: generates the basic data table according to the date, transaction type and transaction channel corresponding to the anti-money laundering data;

[0046] Screening module: calling the anti-money laundering suspicious model to screen the basic data table and generate screening results;

[0047] Table writing module: uses the screening results to execute SQL statements according to the rules, identifies suspicious transactions, and loads customers who meet the requirements into the anti-money laundering case table;

[0048] The screening module aggregates and compiles data from the anti-money laundering case table, archives the information, cleans the data, displays the customer on the front desk, and then screens the case. If it is suspicious, it will be reported to the People's Bank of China, and if it is not suspicious, it will be excluded.

[0049] In the above technical solution, extracting data from the data source task data includes: data extraction module:

[0050] Step 2.1. Create a stealth file: Create a guard process in the background. The guard process creates an empty file aml.sok and opens the file through the open() function. Then, it calls the Unix system command ulink to forcibly cancel the hard link of the file, making the file invisible. Unless the guard process exits abnormally or exits, the file will always exist. The main function of this step is to prevent the background guard process from being executed repeatedly and to establish the aml.sok socket service.

[0051] Step 2.2: The Guardian process scans the specified file area for SYM_YYYYMMDD.ok every 5 minutes to see if it has been created. YYYYMMDD is the date to be loaded. If the file is found, the value of the i_ready variable in the Guardian process is rewritten to 1. Otherwise, it defaults to 0.

[0052] In step 2.3, the money laundering client initiates an inquiry message by accessing the aml.sok socket service. After receiving the inquiry message, the guard process sends the value of i_ready to the anti-money laundering client. If the value of i_ready is 0, the anti-money laundering client enters sleep mode for 15 minutes. If the value of i_ready is 1, it initiates FTP data access and obtains the SYM_YYYYMMDD.ok file from the upstream system to obtain the customer's anti-money laundering data.

[0053] In the above technical solution, the basic data table module:

[0054] Step 3.1, first access the calendar table mc00_datatime to obtain the current date for which data needs to be obtained;

[0055] Step 3.2: Based on the Java program and the configuration table mc00_ds_tables, call the shell script to load the upstream data file into the anti-money laundering database metadata table.

[0056] In the above technical solution, in the screening module, the money laundering suspicion model is executed in parallel on multiple nodes. The specific algorithm is:

[0057] 4a. By performing hash calculation on the customer numbers in the anti-money laundering data, the customer data is evenly distributed across several computing nodes;

[0058] 4b. Associate the customer table with the account table to distribute the account data to the same computing nodes as the corresponding customers.

[0059] 4c. By associating the account table with the transaction table, the transaction data is distributed on the same computing nodes as the corresponding accounts and customers;

[0060] 4d. Anti-money laundering customer, account, and transaction data are distributed across several computing nodes, enabling data parallel computing and improving the computational efficiency of suspicious anti-money laundering rules. However, it is necessary to prevent broadcast noise between multiple nodes. To this end, by executing steps 4a, 4b, and 4c, since the customer, account, and transaction data of the same customer are distributed on the same computing node, broadcast communication between computing nodes is eliminated at the data level, thereby improving the efficiency of data distribution computing.

[0061] In the above technical solution, the screening module calls the anti-money laundering suspicious model to screen the basic data table and generate screening results, which includes: using preset call rules to call the corresponding anti-money laundering suspicious model to screen the basic data table and generate screening results. The screening results include suspicious transaction data, suspicious customer information, and suspicious account data. Anti-money laundering call rules are divided into two categories: large-value monitoring rules and suspicious monitoring rules. Large-value monitoring rules are based on the mandatory personal or corporate transaction data published by the People's Bank of China, while suspicious monitoring rules are designated to monitor eight major types of money laundering: telecommunications fraud, underground banking, drug-related crimes, gambling-related crimes, illegal fundraising, pyramid schemes, illegal cash withdrawal, and illegal tax evasion. Anti-money laundering rules are executed by executing various types of dedicated stored procedures in the database.

[0062] Because the present invention adopts the above technical solution, it has the following beneficial effects:

[0063] 1. Ensure authenticity: Add verification steps during data transmission, storage, and processing to prevent missing file numbers and file fields, and avoid errors in the basic logic of field information, which directly affect the quality of data analysis.

[0064] 2. Ensure timeliness: Strengthen the data modification linkage prompt function. Once the front-end business system modifies the field information, it should promptly notify the back-end data warehouse to initiate the review and modification mechanism.

[0065] 3. Ensure high efficiency: By comprehensively applying automated database partitioning technology, a single database computing node is expanded to a theoretically unlimited number of computing nodes, significantly improving the efficiency of anti-money laundering model calculations. DETAILED DESCRIPTION

[0066] The following is a detailed description of the embodiments of the present invention. Although the present invention will be described and illustrated in conjunction with certain specific embodiments, it should be noted that the present invention is not limited to these embodiments. On the contrary, modifications or equivalent substitutions of the present invention are intended to fall within the scope of the claims of the present invention.

[0067] In addition, in order to better illustrate the present invention, numerous specific details are given in the following detailed description. It will be understood by those skilled in the art that the present invention can also be implemented without these specific details.

[0068] Step S1, data source detection task, obtains the upstream system data preparation status, and uses java.util.Timer to implement system clock scanning

[0069] Step S2: extract data tasks.

[0070] Step S3: Acquire anti-money laundering data, including customer data, transaction data, and account data. The anti-money laundering data is acquired through an upstream business system.

[0071] Step S4: standardize the anti-money laundering data to generate a basic data table.

[0072] Step S5: Calling the anti-money laundering suspicious model to screen the basic data table and generate a screening result. During the data screening, data that meets the description of the anti-money laundering suspicious model is screened out as the screening result.

[0073] Step S6: using the screening results to determine suspicious transactions. Further determining suspicious transactions based on the screening results.

[0074] Step S7, manserver: implement post-batch calculation, aggregate and count the data required for anti-money laundering, archive information, and clean up data.

[0075] Suspicious transactions include:

[0076] 1. For unknown reasons, customer accounts frequently receive and pay cash in a manner close to the standards for large-value cash transactions, raising suspicion of evading large-value transaction monitoring.

[0077] 2. Customers transfer funds from multiple bank accounts and transfer them out to one account.

[0078] 3. Customers transfer funds from one bank account and then transfer them out to multiple accounts.

[0079] 4. When customers subscribe to or redeem funds in the short term, transaction fees are not considered.

[0080] 5. A fund account that has been idle for a long time is suddenly activated for unknown reasons, and a large number of fund transactions occur in a short period of time.

[0081] 6. Customer information that is identical to that on blacklists, high-risk area lists, or lists of foreign dignitaries.

[0082] 7. The source of the customer entrustment is abnormal. Multiple customer transactions occur from the same entrustment source (MAC, IP or mobile phone), and the transaction behaviors are similar.

[0083] 8. The source of the client's entrustment is abnormal, there are multiple sources of entrustment, and the transaction is large.

[0084] 9. There are abnormalities in the client’s occupation, asset size, or transaction scale.

[0085] 10. There are abnormalities in the client’s age, asset size, and transaction scale.

[0086] 11. The client frequently engages in abnormal trading behavior such as buying high and selling low, resulting in continuous losses.

[0087] 12. After changing the custodian bank, the client transfers a large amount of assets to the new custodian bank within a short period of time.

[0088] 13. Broker clients frequently engage in large-volume securities transactions with commission rates exceeding market standards.

[0089] 14. The client's order price for buying or selling stocks listed on the National Equities Exchange and Quotations System is abnormal, with large price deviations.

[0090] 15. The client frequently conducts the same business multiple times in one day (excluding client-entrusted stock and on-exchange fund business).

[0091] 16. The customer modifies the key information of the certificate and then transfers the funds.

[0092] 17. If clients engage in multiple transactions with each other as counterparties on the same day, and the transaction amounts are large and account for a high proportion, there may be abnormal circumstances of cross-trading.

[0093] 18. Accounts with certain correlations engage in multiple counterparty transactions with each other within a day, and the transaction amounts are large.

[0094] 19. The client changes the custodian bank multiple times within a short period of time and withdraws funds.

[0095] 20. If clients with high or medium risk levels engage in multiple transactions with each other within a day, and the transaction amounts are large, there may be abnormal situations of cross-trading.

[0096] Anti-money laundering data verification: Extracting data from data source tasks includes: scanning the data source preparation status, determining whether the data source data is ready, and the specific date range of data that can be scanned, which is automatically maintained by the system without manual intervention.

[0097] Anti-money laundering data includes: the anti-money laundering data is obtained from multiple upstream business systems in the form of data files. The system automatically splits the task list tasks according to frequency and triggers them one by one in order of frequency from low to high.

[0098] Standardize the anti-money laundering data and generate the basic data table, including: generating the basic data table according to the date, transaction type and transaction channel corresponding to the anti-money laundering data, and generating the task list according to the data source.

[0099] Calling the suspicious anti-money laundering model to screen the basic data table and generate screening results includes: using preset call rules to call the corresponding suspicious anti-money laundering model to screen the basic data table and generate screening results. The screening results include suspicious transaction data, suspicious customer information, and suspicious account data. The basic anti-money laundering data table covers all customer, account, and transaction flow information of financial institutions. The so-called anti-money laundering rules are the money laundering characteristics that this customer, account, and transaction flow information meets.

[0100] Using the screening results to determine suspicious transactions includes: sending the screening results to a business operating system, using the business operating system to screen suspicious transaction data, suspicious customer information, and suspicious account data to determine suspicious transactions.

[0101] Using pre-set creation rules, a suspicious anti-money laundering model configuration is established. When all trigger conditions are met, the trigger is activated, and the corresponding task is activated and can be sent to the execution queue. Before the triggered task is sent to the execution queue, the system verifies the task splitter configuration and, if necessary, splits the task to perform data desensitization and testing on the suspicious anti-money laundering model.

[0102] The business functions of the system cover the core work of anti-money laundering regulatory requirements; it realizes front-end monitoring and management of the extraction, conversion and loading process of the system's risk monitoring data, mainly including business data source management, data extraction script management, data loading script management, data unloading script management, data table management and data script conversion management.

[0103] The data processing component integrates and analyzes AML data using the "Anti-Money Laundering Application Computing Zone" built on the Dataware data warehouse platform and the Shell + SQL LDR scripting language. Daily bank transaction and account data is loaded into the AML basic data tables via the data job scheduling platform. The "data job scheduling platform" is an automated batch job management tool that allows for configuring different triggering conditions for batch job execution based on different scenarios. These conditions include scheduled execution and job-dependent execution.

[0104] In commercial banks' IT systems, anti-money laundering data integrates customer data, transaction data, and account data. It is characterized by large volumes, wide coverage, and complex business backgrounds. Data generated by upstream business systems is loaded into the data warehouse daily as data files. The data warehouse processes this raw data based on dimensions such as date, transaction type, and transaction channel to create basic anti-money laundering data tables. Based on real money laundering cases and the central bank's anti-money laundering regulations, commercial banks incorporate their own business data characteristics and develop data screening logic for various anti-money laundering scenarios, following the principles of "case characterization, feature indicatorization, and indicator modeling." If this data screening logic can identify data within the anti-money laundering data cored by the "anti-money laundering basic data tables," it generates various types of "anti-money laundering suspicious transaction" data.

[0105] The aforementioned "data screening logic" is the "anti-money laundering suspicion model." The anti-money laundering system of the present invention implements model screening criteria using the SQLLDR scripting language based on different types of suspicion models. Similarly, through the data warehouse data job scheduling platform, SHELL+SQLLDR script jobs are interdependently organized to form an anti-money laundering workflow. At the end of each day, the anti-money laundering workflow screens out suspicious data (including suspicious transaction data, suspicious customer information, and suspicious account data) and transmits this suspicious data to the business operating system via the file transfer component.

[0106] The business operating system is designed and implemented based on the J2EE technical architecture. A portion of the anti-money laundering business process processing and human interaction is implemented through a unified JAVA display interface. The implementation of this interface functionality relies on transaction processing on the server side, while business presentation is based on transaction information returned by the backend. The server side is an application process system based on the J2EE architecture and componentized design. It receives service requests from the presentation layer, implements the business logic, and returns the results to the presentation layer. Regarding report data presentation, flexible reporting methods are used to support business personnel in independently defining report formats and intuitive graphical presentation methods. Detailed data queries are supported. Based on the specific characteristics of anti-money laundering business, fixed reports that meet regulatory requirements are generated.

[0107] Data processing is the core business logic implementation of risk monitoring rule processing. Data processing must meet the following requirements:

[0108] 1. Newly imported transaction data can be processed continuously, stably, on time and accurately every day;

[0109] 2. Ensure the correct relationship between related data in terms of time and business logic;

[0110] 3. Backend data processing should not affect the normal use of foreground functions;

[0111] 4. Ensure the integrity and consistency of transactions;

[0112] 5. Each specific business logic should be organized in the system in a pluggable manner, so that new business logic can be expanded;

[0113] 6. Improve efficiency as much as possible and reduce I / O throughput and network load pressure;

[0114] Because the AML suspicious transaction model is customer-centric, testing and tuning using unmasked data is necessary to verify its accuracy. To simultaneously meet the data security and AML testing needs of commercial banks, the establishment of an AML laboratory is essential.

[0115] The purpose of the Anti-Money Laundering Laboratory is to primarily develop, validate, and analyze models for anti-money laundering business monitoring. The laboratory assists businesses with data analysis and mining through tools such as SAS. Data mining modeling can be used to define typical behavioral characteristics, establish behavioral patterns and transaction scenarios, and form a risk identification and quantification system. Mature risk modeling methods and tools are then used to solidify risk points and monitoring strategies. The system then assists with real-time identification and analysis, as well as continuous monitoring and early warning. The following are the characteristics of the model laboratory:

[0116] Data analysis: By analyzing the basic situation of internal data, understanding the basic data distribution and indicators, mastering business rules, customer characteristics and behavioral habits, and providing reference for model definition, optimization and risk analysis.

[0117] Model definition: realize online design of models and provide flexible customization tools based on the interface.

[0118] Model verification: Model simulation calculation and result review based on real data.

[0119] Model review: Implement review process management of the model design process.

[0120] Model production: realize the production release management of the model design process.

[0121] Model tracking: Continuously track and analyze model operation results and status, and provide model optimization suggestions.

[0122] The laboratory accesses source system production data from the data warehouse and loads data regularly on a monthly basis.

[0123] Many anti-money laundering suspicious transaction models are designed and implemented based on regulatory guidelines. They analyze and integrate massive amounts of bank transaction data, customer information, and account data, extracting case characteristics and quantifying these characteristics through indicators. This allows these patterns to be fixed and formed into suspicious transaction models. This makes suspicious transaction models manageable and tunable, becoming tangible assets for commercial banks.

[0124] The system has a data computing task monitoring platform (referred to as the monitoring platform). Due to the wide variety of anti-money laundering suspicious transaction models, the business data involved varies. To ensure the orderly batch execution of these numerous suspicious transaction models, a carefully configured data monitoring platform is required. The monitoring platform should possess multiple management functions. The monitoring platform is a tool for automatically managing batch jobs. A batch program is called a scheduled job. Under normal circumstances, a scheduled job will only execute if all preconditions (called input dependencies) are met. Upon completion, a scheduled job generates a success flag (called an output dependency). This success flag can manifest in various ways, such as generating a file or writing a success record to a database table. These output dependencies are typically used for subsequent jobs. Subsequent jobs can execute upon detecting the success flag of the preceding job.

[0125] When a scheduled job encounters an exception during execution and needs to be terminated, the monitoring platform provides a suspend function, which can be implemented by "killing the process." Re-running the job simply re-executes the batch program. Of course, "re-running the batch program" requires that the batch code be written to support multiple executions. Regarding the entire manual processing and screening process, an automated process has been implemented for the exchange of suspicious data between the data warehouse's anti-money laundering application computing area and the business operating system. Furthermore, a full manual processing process has been established, including "suspicious case screening," "suspicious transaction confirmation," "customer due diligence," and "customer funds transaction chain diagram."

[0126] The anti-money laundering suspicion model screens anti-money laundering data and identifies suspicious transactions based on the screening results, solving problems faced by the anti-money laundering field, such as data dispersion and insufficient data analysis and early warning capabilities. It also improves the efficiency and accuracy of anti-money laundering monitoring, thereby significantly improving detection quality across the enterprise.

[0127] A data acquisition module is used to acquire anti-money laundering data, including customer data, transaction data, and account data;

[0128] A data standardization module, used to standardize the anti-money laundering data and generate a basic data table;

[0129] A data screening module is used to call an anti-money laundering suspicious model to perform data screening on the basic data table and generate a screening result;

[0130] The suspicious transaction module is used to determine suspicious transactions using the screening results.

[0131] The data acquisition module includes: a data acquisition unit, which is used to acquire the anti-money laundering data in the form of data files from multiple upstream business systems.

[0132] The data standardization module includes: a data standardization unit, which is used to generate the basic data table according to the date, transaction type and transaction channel corresponding to the anti-money laundering data.

[0133] The data screening module includes: a data screening unit, which is used to use preset calling rules to call the corresponding anti-money laundering suspicious model to screen the basic data table and generate screening results. The screening results include suspicious transaction data, suspicious customer information and suspicious account data.

[0134] Using the screening results to determine suspicious transactions includes: sending the screening results to a business operating system, using the business operating system to screen suspicious transaction data, suspicious customer information, and suspicious account data to determine suspicious transactions.

[0135] The device of the present invention also includes: a model building unit, which is used to use preset creation rules to build an anti-money laundering suspicious model; and a desensitization testing unit, which is used to perform data desensitization and testing on the anti-money laundering suspicious model.

Claims

1. A method for monitoring suspicious transaction data for anti-money laundering, characterized in that: The method comprises: Step S1, data source detection task, uses java.util.Timer to implement system clock scanning, and obtains the data preparation status of the upstream system through the data preparation flag. When the upstream system generates the SYM_YYYYMMDD.ok file containing the customer's money laundering data in the file sharing area, it indicates that the data has been prepared. Otherwise, continue waiting; Step S2: When the upstream system generates the file SYM_YYYYMMDD.ok in the file sharing area in step S1, data extraction is performed to obtain anti-money laundering data, which includes customer data, transaction data, and account data. Step 2.

1. Create a stealth file: Create a guard process in the background. The guard process creates an empty file aml.sok and opens the file through the open() function. Then, it calls the Unix system command ulink to forcibly cancel the hard link of the file, making the file invisible. Unless the guard process exits abnormally or exits, the file always exists. The main function of this step is to prevent the background guard process from being executed repeatedly and to establish the aml.sok socket service. Step 2.2: The guard process scans the specified file area for SYM_YYYYMMDD.ok every 5 minutes to see if it has been created. YYYYMMDD is the date to be loaded. If the file is found, the value of the i_ready variable in the guard process is rewritten to 1. Otherwise, it defaults to 0. Step 2.3: The money laundering client initiates a query message by accessing the aml.sok socket service. After receiving the query message, the guard process sends the value of i_ready to the anti-money laundering client. If the value of i_ready is 0, the anti-money laundering client enters sleep mode for 15 minutes. If the value of i_ready is 1, it initiates FTP data access and obtains the SYM_YYYYMMDD.ok file from the upstream system. This obtains the client's anti-money laundering data, including customer, account, and transaction data files and control files. The data files are used for anti-money laundering model analysis, and the control files describe the size of the corresponding data files, MD5 values, and configuration information for each data field. Step S3: Generate a basic data table based on the date, transaction type and transaction channel corresponding to the anti-money laundering data; Step 3.1, first access the calendar table mc00_datatime to obtain the current date for which data needs to be obtained; Step 3.2: Perform MD5 calculations on the customer, account, and transaction data files, and compare the resulting MD5 values with those of the corresponding customer, account, and transaction control files. If the MD5 values of the two are consistent, the number and fields of the data files are consistent with those in the upstream system. Step 3.3: Compare the field configuration information in the control file with the field configuration information recorded in the configuration table mc00_ds_tables. If they are consistent, the file can be directly loaded and used. If they are inconsistent, the corresponding table in the database needs to be adjusted. Call an automated script to adjust the basic table to be consistent with the configuration information in the control file. Based on the Java program and the configuration table mc00_ds_tables, call a shell script to load the upstream data file into the anti-money laundering database metadata table to obtain the basic data table. Step S4: calling the anti-money laundering suspicious model to perform data screening on the basic data table and generate a screening result; Step S5: Using the screening results, executing SQL statements according to the rules, determining suspicious transactions, and loading customers that meet the requirements into the anti-money laundering case table; Step S6: aggregate and count the data in the anti-money laundering case table, archive the information, clean the data, and present the customer to the front desk. Then, the bank's business personnel manually screen the case. If it is suspicious, it will be reported to the People's Bank of China. If it is not suspicious, it will be excluded.

2. The method for monitoring suspicious transaction data for anti-money laundering according to claim 1, characterized in that: In step 4, the money laundering suspicion model is executed in parallel on multiple nodes. The specific algorithm is as follows: 4a. By performing hash calculation on the customer numbers in the anti-money laundering data, the customer data is evenly distributed across several computing nodes; 4b. Associate the customer table with the account table to distribute the account data to the same computing nodes as the corresponding customers. 4c. By associating the account table with the transaction table, the transaction data is distributed on the same computing nodes as the corresponding accounts and customers; 4d. Anti-money laundering customer, account, and transaction data are distributed across several computing nodes, enabling data parallel computing and improving the computational efficiency of suspicious anti-money laundering rules. However, it is necessary to prevent broadcast noise between multiple nodes. To this end, by executing steps 4a, 4b, and 4c, since the customer, account, and transaction data of the same customer are distributed on the same computing node, broadcast communication between computing nodes is eliminated at the data level, thereby improving the efficiency of data distribution computing.

3. The method for monitoring suspicious transaction data for anti-money laundering according to claim 1, characterized in that: In step 4, calling the anti-money laundering suspicious model to screen the basic data table and generate the screening results includes: using the preset calling rules, calling the corresponding anti-money laundering suspicious model to screen the basic data table and generate the screening results, and the screening results include suspicious transaction data, suspicious customer information and suspicious account data; the anti-money laundering calling rules are divided into two categories: large-value monitoring rules and suspicious monitoring rules. The large-value monitoring rules are personal or corporate transaction data that must be reported and announced by the People's Bank of China. The suspicious monitoring rules are designated for 8 major types of money laundering monitoring rules for telecommunications anti-fraud, underground banks, drug-related, gambling-related, illegal fundraising, pyramid schemes, illegal cashing, and illegal tax evasion. The anti-money laundering rules are executed by executing various types of exclusive stored procedures in the database.

4. A monitoring device for anti-money laundering suspicious transaction data, characterized in that: include: The data source detection module, which is a data source detection task, uses java.util.Timer to implement system clock scanning and obtain the data preparation status of the upstream system by marking the data preparation. When the upstream system generates the SYM_YYYYMMDD.ok file containing the customer's money laundering data in the file sharing area, it indicates that the data has been prepared. Otherwise, it continues to wait. The data extraction module extracts data when it finds the SYM_YYYYMMDD.ok file generated by the upstream system in the file sharing area, and obtains anti-money laundering data, which includes customer data, transaction data, and account data. Basic data table module: generates the basic data table according to the date, transaction type and transaction channel corresponding to the anti-money laundering data; Screening module: calling the anti-money laundering suspicious model to screen the basic data table and generate screening results; Table writing module: uses the screening results to execute SQL statements according to the rules, identifies suspicious transactions, and loads customers who meet the requirements into the anti-money laundering case table; The screening module aggregates and compiles data from the anti-money laundering case table, archives the information, cleans the data, displays the customer information on the front desk, and then screens the case. If it is suspected, it will be reported to the People's Bank of China, and if it is not suspected, it will be excluded. Extracting data from data source tasks includes: Data extraction module: Step 2.

1. Create a stealth file: Create a guard process in the background. The guard process creates an empty file aml.sok and opens the file through the open() function. Then, it calls the Unix system command ulink to forcibly cancel the hard link of the file, making the file invisible. Unless the guard process exits abnormally or exits, the file will always exist. The main function of this step is to prevent the background guard process from being executed repeatedly and to establish the aml.sok socket service. Step 2.2: The guard process scans the specified file area for SYM_YYYYMMDD.ok every 5 minutes to see if it has been created. YYYYMMDD is the date to be loaded. If the file is found, the value of the i_ready variable in the guard process is rewritten to 1. Otherwise, it defaults to 0. Step 2.3: The money laundering client initiates an inquiry message by accessing the aml.sok socket service. After receiving the inquiry message, the guard process sends the value of i_ready to the anti-money laundering client. If the value of i_ready is 0, the anti-money laundering client enters sleep mode for 15 minutes. If the value of i_ready is 1, it initiates FTP data access and obtains the SYM_YYYYMMDD.ok file from the upstream system to obtain the customer's anti-money laundering data. Basic data table module: Step 3.1, first access the calendar table mc00_datatime to obtain the current date for which data needs to be obtained; Step 3.3: Based on the Java program and the configuration table mc00_ds_tables, call the shell script to load the upstream data file into the anti-money laundering database metadata table.

5. The device for monitoring suspicious transaction data for anti-money laundering according to claim 4, characterized in that: In the screening module, the anti-money laundering suspicious model is executed in parallel on multiple nodes. The specific algorithm is as follows: 4a. By performing hash calculation on the customer numbers in the anti-money laundering data, the customer data is evenly distributed across several computing nodes; 4b. Associate the customer table with the account table to distribute the account data to the same computing nodes as the corresponding customers. 4c. By associating the account table with the transaction table, the transaction data is distributed on the same computing nodes as the corresponding accounts and customers; 4d. Anti-money laundering customer, account, and transaction data are distributed across several computing nodes, enabling data parallel computing and improving the computational efficiency of suspicious anti-money laundering rules. However, it is necessary to prevent broadcast noise between multiple nodes. To this end, by executing steps 4a, 4b, and 4c, since the customer, account, and transaction data of the same customer are distributed on the same computing node, broadcast communication between computing nodes is eliminated at the data level, thereby improving the efficiency of data distribution computing.

6. The monitoring device for anti-money laundering suspicious transaction data according to claim 4, characterized in that: The screening module calls the anti-money laundering suspicious model to perform data screening on the basic data table, and generates screening results, including: using preset calling rules, calling the corresponding anti-money laundering suspicious model to perform data screening on the basic data table, and generating screening results, the screening results including suspicious transaction data, suspicious customer information and suspicious account data; anti-money laundering calling rules are divided into two categories: large-value monitoring rules and suspicious monitoring rules. Large-value monitoring rules are personal or corporate transaction data that must be reported and announced by the People's Bank of China. Suspicious monitoring rules are designated for eight major types of money laundering monitoring rules, including telecommunications anti-fraud, underground banks, drug-related, gambling-related, illegal fundraising, pyramid schemes, illegal cashing, and illegal tax evasion. Anti-money laundering rules are executed by executing various types of exclusive stored procedures in the database.