HTAP Databases for Anti-Money Laundering in State-Owned Banks

When it comes to money laundering, many people believe it only happens in movies and TV shows. However, it can occur in our daily lives through various channels like art deals, cross-border investments, gambling, and securities trading. Anti-money laundering (AML) refers to the measures taken to prevent the concealment of the origins of illegally obtained money. 

Business Challenges

Banks are increasingly moving their services online, and becoming more digital and intelligent. With stricter regulations, financial institutions face significant challenges in their AML efforts. These include verifying customer identities, keeping detailed transaction records, monitoring and reporting suspicious activities promptly, and conducting regular risk assessments. Some specific challenges include: 

• Expanding Regulatory Scope and Data Storage Span: Regulations require financial institutions to reasonably assess money laundering and terrorist financing risk levels based on customer characteristics or account attributes in their AML work, and implement corresponding control measures accordingly. Simultaneously, financial institutions must ensure the completeness and accuracy of historical transaction records. For instance, certain cross-border remittance transaction records must be retained for at least five years.
• Increasing Demands on Reporting Timeliness and Data Accuracy: Regulatory bodies have raised the bar for transaction data reporting deadlines, such as completing submissions within 5 to 10 working days (with some scenarios requiring T+1 day data reporting). Financial institutions need to adopt efficient data processing methods to meet timeliness requirements while implementing complex identification and monitoring rules, and performing calculations for numerous quantitative indicators.
• Frequent Changes in Regulatory Rules: In the face of constantly innovating business models, AML systems need to employ rule engines to configure flexible monitoring models, filter and analyze data, and generate AML reports. System design must ensure rapid adaptation to regulatory rule changes, avoiding delays in updating business rules due to technical limitations such as “sharding keys”.

A state-owned bank’s original AML business system that was built on multiple data technology stacks and heterogeneous databases, faces issues such as high development and maintenance costs, inadequate mixed OLTP and OLAP processing capabilities, lack of large-scale elastic storage and high availability, and poor data timeliness. To address these problems, the bank reconstructed a global AML system based on the domestic HTAP distributed database TiDB. This system innovatively integrates stream computing with batch processing, supports high-concurrency data access and online interactive multi-dimensional queries, achieves the integration of multiple technology stacks, and ensures business continuity.

Construction of a Next Generation Anti-Money Laundering Business System

Business Architecture

The Real-time Anti-Money Laundering (AML) System primarily focuses on real-time monitoring of customer-initiated transactions. It receives transaction requests from upstream online systems through interfaces, registers them, and performs real-time rule set matching (such as cumulative transaction amounts and counts involving customer-submitted transactions and historical transactions). If a match occurs, case information is generated, and the processing result is returned to the caller in real-time. This system is classified as a critical business system (with 5 data replicas) and includes a disaster recovery cluster setup. The Real-time AML Business includes both online and batch operations, and from a business perspective, it includes modules such as customer due diligence and transaction due diligence.

Customer Due Diligence involves data tables including a customer information table with 600 million entries, a customer rating history table with tens of billions of entries (6 years of historical data), and a case table (with 1 billion entries). There are approximately 700,000 daytime transactions, involving insertion or updating of the customer information table based on customer dimensions. The batch-to-online mode is processed as an online interface, with potentially high instantaneous concurrency, primarily involving operations based on customer ID dimensions. This includes insert and update operations on the customer information table, as well as using the case table as a driving table for joining with multiple other tables. The batch calculation functionality computes result sets based on transaction records, the merged customer information table, and other tables through associations. It involves multiple calculation dimensions, potentially expanding the result set, with the expectation of completion within the same day.

Transaction Due Diligence involves data tables primarily including transaction tables, case tables, interception information tables, and behavior-type message tables (with data scales in the hundreds of millions, with behavior-type tables having even larger data volumes). Business functions include providing tellers with write and update operations for the interception information table; offering flexible data queries to tellers, involving multi-table joins, including paginated queries in form format, and primarily light AP-type aggregate queries.

Data Architecture

As shown in the figure above, the domestic real-time anti-money laundering component is vertically divided into online transactions and batch analysis parts according to business domains. Each part corresponds to an independent TiDB distributed database cluster. Each cluster includes two storage engines–TiKV for row storage and TiFlash for column storage.

• AMLT Cluster: The main cluster has a five-replica configuration, corresponding to the online transaction part, including customer due diligence, transaction due diligence, and public service modules. It primarily handles customer-dimension online and internal front-end scenarios. The average daily TPS is 200+, mainly dealing with due diligence for customer account opening and maintenance scenarios, as well as cross-border remittance transactions. Batch operations involve merging T-1 day customer information and transaction information into the main table.
• AMLA Cluster: The main cluster has a three-replica configuration. It corresponds to the batch analysis part, including SS and public service modules. This is primarily a data consumption system for internal and external list processing batch operations. The processed result tables are used for flexible online queries by internal business personnel. Due to its involvement with internal and external blacklists, this system is also of high importance and ensures business continuity.
• Peripheral Systems: These include nearly a hundred upstream online transaction systems that send transactions meeting anti-money laundering thresholds for inspection and screening via API interfaces.

Database Cluster Deployment

The bank deploys the TiDB main cluster across data centers in City A, with a disaster recovery cluster in City B. The main cluster adopts a 3+2 deployment mode across two data centers in the same city.

• Online operations use an active-active mode, with actual business read and write traffic in both data centers. Relevant tables can distribute leaders evenly across both data centers.
• Special attention is given to batch jobs. For application-side data migration, daily data loading, batch processing, and data export, priority is given to binding tables involved in pure batch operations to single-side leaders. This ensures affinity access between the application and TiDB leader replicas. The same principle applies to TiFlash replicas, effectively reducing cross-data center network traffic.
• For tables used in both online and batch operations, if using TiKV and not involving complex joins or subqueries, the current status can be maintained. Alternatively, the local read feature can be enabled as needed based on actual business situations.

Application Effectiveness

The new generation anti-money laundering business system interfaces with nearly a hundred upstream and downstream systems across the bank, storing hundreds of terabytes of data. While supporting daily incremental data of hundreds of millions of transactions and tens of millions of T+0 real-time queries, it achieves ultra-long span queries and a more complete and accurate panoramic view of transactions. This significantly enhances the comprehensive data service capabilities and customer experience in the mobile internet era, providing round-the-clock, diverse, and highly time-efficient services.

Key benefits include:

• High concurrency capability: Thanks to TiDB’s high concurrency and high throughput characteristics, the expected goals were smoothly achieved. The system demonstrated excellent read-write performance and stability, without experiencing delays or failures.
• Elastic horizontal scalability: TiDB’s native distributed architecture supports flexible on-demand expansion of computational power. The cluster expansion process is completely transparent to applications, simplifying operational management and effectively solving the capacity warning issues of single-machine Oracle systems.
• Efficient batch processing: The Spark component provides index support, and various computation push-downs allow Spark to efficiently read data from TiKV, significantly enhancing the performance of batch processing tasks. Spark also offers mass data update functionality while ensuring the atomicity of update transactions.
• Rapid data import: The system supports file loading pushed from upstream Hive data warehouses. With the technology of Spark batch processing writing directly to TiKV in parallel, data import performance has been greatly improved.

In summary, the new AML system, powered by TiDB, significantly improves the bank’s ability to detect and prevent money laundering, ensuring compliance with regulations and enhancing operational efficiency.