[DE Blog #23] Data Engineering Trong Ngành FinTech & Banking: Kiến Trúc Sổ Cái Kép (Double-Entry Ledger), Đối Soát 3 Bên & Tính Toàn Vẹn Tài Chính Tuyệt Đối

1. Bối cảnh thực tế (Context & Problem Statement)

Trong các hệ thống E-commerce hay Ad-Tech, việc thất thoát $0.01\%$ log sự kiện nhấp chuột có thể chấp nhận được. Nhưng trong FinTech và Ngân hàng (Core Banking, Ví điện tử, Cổng thanh toán):

Sai lệch dù chỉ 1 đồng cũng có thể dẫn đến hậu quả pháp lý nghiêm trọng, không vượt qua được các đợt thanh tra kiểm toán (KPMG, PwC, Ngân hàng Nhà nước) và có nguy cơ bị tước giấy phép hoạt động.
Phải xử lý hàng chục triệu giao dịch mỗi ngày nhưng tuyệt đối không được phép xảy ra hiện tượng "tiền tự sinh ra hoặc biến mất" (Balance Inconsistency).

Các thách thức kỹ thuật sống còn của Data Engineer trong ngành Tài chính:

Loại bỏ hoàn toàn Race Condition khi cập nhật số dư: Không sử dụng các câu lệnh ghi đè số dư trực tiếp.
Quy trình Đối soát 3 bên (3-Way Reconciliation): Tự động đối chiếu hàng triệu giao dịch giữa Sổ cái nội bộ (Internal Ledger) $\leftrightarrow$ Sao kê Ngân hàng đối tác (Bank Settlement) $\leftrightarrow$ Báo cáo Đơn vị chấp nhận thanh toán (Merchant Report).

2. Các Khái Niệm & Cơ Chế Cốt Lõi

2.1. Nguyên Tắc Sổ Cái Kép (Double-Entry Bookkeeping)

Nguyên tắc cốt lõi của ngành kế toán tài chính 500 năm qua: Tiền không bao giờ tự nhiên sinh ra hay mất đi, nó chỉ chuyển từ tài khoản này sang tài khoản khác.

Mọi giao dịch tài chính bắt buộc phải bao gồm ít nhất 2 bút toán đối ứng (Entries):
- Ghi Nợ (Debit - Nợ): Tăng tài sản hoặc giảm nợ phải trả.
- Ghi Có (Credit - Có): Giảm tài sản hoặc tăng nợ phải trả.
Phương trình bất biến bất khả xâm phạm: $\sum \text{Debits} = \sum \text{Credits} \quad \Longleftrightarrow \quad \sum \text{Debits} - \sum \text{Credits} = 0$
Ví dụ: Người dùng A nạp 100.000đ vào Ví điện tử từ tài khoản Vietcombank:
- Debit: Tài khoản Tiền gửi Ngân hàng của Ví (Asset) $+100.000\text{đ}$ .
- Credit: Tài khoản Số dư Khách hàng A (Liability) $+100.000\text{đ}$ .
- Tổng Debit $-$ Tổng Credit $= 0$ (Cân bằng tuyệt đối).

2.2. Kiến Trúc Event-Sourced Ledger (Sổ Cái Bất Biến)

❌ Anti-Pattern (Cực kỳ nguy hiểm):
```
-- Tuyệt đối không làm điều này trong hệ thống tài chính:
UPDATE accounts SET balance = balance + 100000 WHERE user_id = 'user_123';
```
$\rightarrow$ $\to$ Mất dấu vết lịch sử, dễ bị lỗi đồng thời (Lost Updates), không thể chứng minh cho kiểm toán viên.
✅ Best Practice (Append-Only Event Sourcing):
- Bảng accounts không có cột balance có thể chỉnh sửa tự do.
- Mọi biến động đều được ghi nối tiếp vào bảng ledger_entries (Chỉ ghi thêm, không bao giờ sửa/xóa - Append-Only & Immutable).
- Số dư tại bất kỳ thời điểm nào được tính bằng tổng lũy kế các dòng Debit/Credit: $\text{Balance}(t) = \sum_{i=1}^{t} (\text{Credits}_i - \text{Debits}_i)$

2.3. Hệ Thống Đối Soát Tài Chính Tự Động 3 Bên (Automated 3-Way Reconciliation)

Mỗi ngày, một giao dịch thanh toán xuất hiện ở 3 hệ thống độc lập:

Bên 1 - Sổ cái nội bộ (Internal Core Ledger): Nhật ký giao dịch ghi nhận trên hệ thống ví/cổng thanh toán.
Bên 2 - Báo cáo sao kê Ngân hàng (Bank Clearing / Settlement Files): File sao kê (chuẩn MT940 / ISO 20022 / CSV) gửi từ Vietcombank, Techcombank, Napas qua SFTP mỗi sáng.
Bên 3 - Báo cáo Đơn vị bán hàng (Merchant Settlement Report): Giao dịch được ghi nhận tại hệ thống của bên bán (Shopee, Grab, Lazada).

Nhiệm vụ của Data Pipeline Đối soát:

So khớp các cặp giao dịch theo Mã tham chiếu (Transaction Reference ID), Số tiền (Amount) và Thời gian (Timestamp).
Phát hiện và đưa các trường hợp lệch tiền vào Hàng đợi Xử lý Ngoại lệ (Exception Handling Queue).

3. Các Bảng Markdown So Sánh Chi Tiết

📊 Bảng 1: So Sánh Cập Nhật Số Dư Trực Tiếp vs. Sổ Cái Kép Bất Biến (Event-Sourced Ledger)

Tiêu chí	Cập nhật trực tiếp (`UPDATE accounts`)	Sổ cái kép bất biến (`INSERT ledger_entries`)
Tính toàn vẹn & Kiểm toán	Kém (Không biết ai đã sửa, sửa lúc nào, sửa vì lý do gì)	Hoàn hảo 100% (Lưu vết mọi giao dịch, không thể làm giả số dư)
Khả năng khôi phục (Audit Trail)	Không thể phục hồi trạng thái quá khứ	Time-Travel hoàn hảo (Tính lại số dư của bất kỳ ngày nào trong quá khứ)
Xử lý xung đột đồng thời	Dễ bị nghẽn (Row-level Lock) và sai lệch số dư	Ghi tuần tự Append-only cực nhanh, không xung đột khóa
Hỗ trợ nghiệp vụ kế toán	Khó tích hợp với hệ thống kế toán doanh nghiệp (ERP)	Chuẩn mực tương thích 100% với hệ thống Kế toán Quốc tế
Đánh giá trong ngành	Nghiêm cấm trong FinTech/Banking	Tiêu chuẩn bắt buộc của các hệ thống Core Banking hiện đại

📊 Bảng 2: So Sánh 3 Phương Thức Kiểm Soát Tranh Chấp Số Dư Tài Chính

Phương thức	Cơ chế hoạt động	Ưu điểm	Nhược điểm	Use-case tối ưu
Pessimistic Locking (`SELECT FOR UPDATE`)	Khóa chặt dòng tài khoản trong suốt Transaction	An toàn tuyệt đối, không có xung đột	Giảm thông lượng (Throughput thấp), dễ gây Timeout nếu traffic cao	Giao dịch rút tiền/chuyển khoản giá trị lớn
Optimistic Concurrency Control (OCC)	Kiểm tra số phiên bản (`version = version + 1`)	Không khóa tài nguyên, thông lượng đọc cao	Phải retry liên tục nếu nhiều giao dịch cùng tác động 1 tài khoản	Tài khoản người dùng cá nhân thông thường
In-Memory Sequential Queue (LMAX / TigerBeetle)	Xử lý đơn luồng cực nhanh trên RAM qua Ring Buffer	Siêu tốc ( $100\text{k} - 1\text{M}$ tx/s), không cần lock	Cần kiến trúc chuyên dụng và cơ chế Snapshot bền vững	Tài khoản tổng (Hot Accounts / Merchant Wallet) có hàng nghìn tx/s

📊 Bảng 3: Ma Trận Các Loại Sai Lệch Đối Soát Tài Chính Thường Gặp (Reconciliation Matrix)

Loại sai lệch	Nguyên nhân phát sinh	Hướng xử lý tự động của Data Pipeline
Missing in Bank (Có ở Ví, thiếu ở Bank)	Giao dịch bị treo kết nối mạng lúc gọi API sang Bank	Tự động gọi API truy vấn trạng thái (Query Status) hoặc phát lệnh hoàn tiền
Missing in Internal (Có ở Bank, thiếu ở Ví)	Khách hàng chuyển khoản trực tiếp qua Napas 24/7 nhưng webhook bị trễ	Pipeline tự động sinh bút toán nạp tiền bù (Auto-credit) vào ví khách hàng
Amount Mismatch (Lệch số tiền)	Lỗi làm tròn số thập phân hoặc tính sai phí giao dịch	Gắn cờ cảnh báo (Flag for Manual Review) cho kế toán can thiệp
Timing Difference (Lệch thời gian)	Giao dịch thực hiện lúc `23:59:59` sang ngày hôm sau Bank mới hạch toán	Áp dụng cửa sổ đối soát trượt (Rolling Window $\pm 24\text{h}$ )

4. Kiến Trúc Thiết Kế Toàn Diện (Full System Design Walkthrough)

[User App / POS Terminal]
            |
            v (HTTPS POST /payment với Idempotency-Key)
+-----------------------------------------------------------------------------------+
| PAYMENT ORCHESTRATION & CORE LEDGER (OLTP Layer)                                  |
|                                                                                   |
|  [Payment Gateway API] ---> [Saga Orchestrator] ---> [Double-Entry Ledger Engine] |
|                                                            |                      |
|                                                            v                      |
|                                                [PostgreSQL / Aurora DB]           |
|                                                (Append-Only Ledger Tables)        |
+------------------------------------------------------------+----------------------+
                                                             |
                                                             v (Log-based CDC via Debezium)
+------------------------------------------------------------+----------------------+
| FINANCIAL DATA LAKEHOUSE & AUDIT VAULT (Apache Iceberg on S3)                     |
|                                                                                   |
|  [Kafka Topic: "financial-ledger-events" (acks=all, Replication=3)]               |
|           |                                                                       |
|           v                                                                       |
|  [Apache Iceberg on S3 (Write-Once-Read-Many / WORM Storage)]                     |
|   - Bảng bất biến lưu trữ toàn bộ lịch sử bút toán tài chính                      |
|   - Mã hóa AES-256 + Audit Log truy cập phục vụ kiểm toán                         |
+------------------------------------+----------------------------------------------+
                                     |
                                     v
+------------------------------------+----------------------------------------------+
| AUTOMATED 3-WAY RECONCILIATION ENGINE (Apache Spark Batch)                        |
|                                                                                   |
|   [Bank SFTP: MT940 / CSV]     [Merchant Settlement Reports]                      |
|              \                             /                                      |
|               v                           v                                       |
|    [Spark Ingestion]              [Spark Ingestion]                               |
|              \                             /                                      |
|               +------------+--------------+                                       |
|                            |                                                      |
|                            v                                                      |
|  [Spark Reconciliation Core: 3-Way Fuzzy & Exact Matching Engine]                 |
|           |                                                                       |
|           +---> [Matched Ledger: 99.98% hoàn toàn trùng khớp]                     |
|           |                                                                       |
|           +---> [Discrepancy Exception Queue -> Bắn cảnh báo cho đội Finance]     |
|           |                                                                       |
|           +---> [Auto-Adjustment Jobs: Tự động phát sinh bút toán bù trừ]         |
+-----------------------------------------------------------------------------------+

5. Góc Ôn Luyện Phỏng Vấn (Interview Corner)

❓ Câu hỏi 1: Tại sao các hệ thống Core Banking và FinTech Ledger hiện đại không bao giờ dùng lệnh `UPDATE` để thay đổi số dư tài khoản? Hãy giải thích cách thiết kế bảng Sổ cái kép (Double-Entry Ledger) và cách tính số dư khả dụng.

Gợi ý trả lời:
- Lý do nghiêm cấm lệnh UPDATE:
  1. Làm mất hoàn toàn dấu vết kiểm toán (Audit Trail) – không thể chứng minh cho kiểm toán viên số tiền thay đổi từ nguồn nào.
  2. Dễ gây tranh chấp khóa (Row Locking) làm giảm nghiêm trọng thông lượng xử lý giao dịch.
  3. Không thể thực hiện quay ngược thời gian (Time-Travel / Point-in-Time Reconstruction) để xác minh số dư tại một thời điểm chính xác trong quá khứ.
- Thiết kế cấu trúc bảng Sổ cái kép:
  - Bảng transactions: Lưu thông tin nghiệp vụ chung (transaction_id, type, description, created_at).
  - Bảng ledger_entries: Lưu các bút toán tài chính chi tiết:
```
CREATE TABLE ledger_entries (
    entry_id BIGINT PRIMARY KEY,
    transaction_id VARCHAR(64) NOT NULL,
    account_id VARCHAR(64) NOT NULL,
    entry_type VARCHAR(10) NOT NULL CHECK (entry_type IN ('DEBIT', 'CREDIT')),
    amount DECIMAL(18, 4) NOT NULL CHECK (amount > 0),
    currency VARCHAR(3) NOT NULL,
    created_at TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP
);
```
- Cách tính số dư khả dụng:
  - Balance = SUM(CASE WHEN entry_type = 'CREDIT' THEN amount ELSE -amount END).
  - Để tối ưu hóa hiệu năng đọc, hệ thống định kỳ tạo các bản chụp số dư (Balance Snapshots) vào cuối mỗi ngày và chỉ cần cộng dồn các ledger_entries phát sinh từ sau thời điểm snapshot đó.

❓ Câu hỏi 2: Làm thế nào để thiết kế một Data Pipeline Đối soát tự động 3 bên (3-Way Reconciliation) xử lý hàng chục triệu giao dịch mỗi ngày?

Gợi ý trả lời theo 4 bước:
1. Tầng Ingestion & Chuẩn hóa dữ liệu (Standardization): Kéo các file sao kê từ SFTP của các ngân hàng (vốn có định dạng khác nhau: CSV, Fixed-width, XML/ISO 20022), phân tích và chuẩn hóa về cùng một cấu trúc dữ liệu chung (Common Canonical Schema).
2. Giai đoạn 1 - Exact Matching (Khớp chính xác): Sử dụng Spark SQL thực hiện phép FULL OUTER JOIN giữa 3 nguồn dựa trên transaction_ref_id và amount. $99\%+$ các giao dịch hợp lệ sẽ được khớp thành công ngay ở bước này.
3. Giai đoạn 2 - Rule-based & Window Matching (Khớp theo quy tắc mở rộng): Đối với các giao dịch còn lại, thực hiện khớp mở rộng trong cửa sổ thời gian trượt ( $\pm 24\text{ giờ}$ ) để xử lý các giao dịch phát sinh vào lúc giao thừa giữa 2 ngày.
4. Giai đoạn 3 - Phân loại sai lệch & Tự động bù trừ (Exception & Auto-adjustment): Các bản ghi không khớp được phân loại vào các nhóm sai lệch (Bảng 3). Hệ thống tự động kích hoạt các lệnh xử lý bù trừ (ví dụ tự động hoàn tiền nếu ngân hàng báo trừ tiền nhưng ví chưa cộng) hoặc gửi cảnh báo lên Dashboard cho đội Vận hành Kế toán.

❓ Câu hỏi 3: Khi một tài khoản người nhận là "Hot Account" (ví dụ: Tài khoản nhận tiền ủng hộ từ thiện hoặc Tài khoản của Sàn thương mại điện tử) có hàng nghìn giao dịch đổ vào mỗi giây, kỹ thuật nào giúp tránh hiện tượng nghẽn khóa (Lock Contention) trên Database?

Gợi ý trả lời:
- Vấn đề: Nếu dùng SELECT FOR UPDATE trên một tài khoản nhận tiền có $5,000\text{ tx/s}$ , toàn bộ các giao dịch phải xếp hàng chờ đợi nhau, gây nghẽn cổ chai nghiêm trọng và sập API.
- Các giải pháp kỹ thuật tối ưu:
  1. Tận dụng tính chất Append-Only: Vì tài khoản nhận tiền chỉ nhận các lệnh Ghi Có (Credit), ta không cần kiểm tra số dư hiện tại có đủ hay không (khác với tài khoản người gửi cần kiểm tra số dư). Do đó, chỉ cần thực hiện lệnh INSERT bút toán mới vào bảng ledger_entries mà hoàn toàn không cần khóa bảng/dòng.
  2. Kỹ thuật Sharded Accounts (Phân mảnh tài khoản ảo): Chia tài khoản lớn thành $N$ tài khoản con (ví dụ: MERCHANT_MAIN_1, MERCHANT_MAIN_2, ..., MERCHANT_MAIN_10). Khi có giao dịch ghi có, hệ thống phân phối ngẫu nhiên vào 1 trong 10 tài khoản con. Khi cần tính tổng số dư, chỉ cần cộng dồn số dư của 10 tài khoản con lại.
  3. Sử dụng Engine Sổ cái chuyên dụng (như TigerBeetle): Áp dụng kiến trúc bộ nhớ đơn luồng (Single-threaded Ring Buffer / LMAX Disruptor) trên phần cứng NVMe tối ưu hóa, có thể ghi nhận hàng triệu bút toán tài chính mỗi giây mà không cần dùng Database Locks truyền thống.

6. Tóm Tắt Ghi Nhớ Nhanh (Key Takeaways)

Nguyên tắc Sổ Cái Kép (Double-Entry): Mọi giao dịch tài chính phải có $\sum \text{Debits} = \sum \text{Credits}$ .
Tuyệt đối không dùng lệnh UPDATE để sửa số dư; luôn sử dụng mô hình Append-Only Event-Sourced Ledger bất biến.
Hệ thống Đối soát tự động 3 bên (3-Way Reconciliation) với Spark là tấm lá chắn bảo vệ doanh nghiệp khỏi thất thoát tài chính và gian lận.
Tối ưu hóa Hot Accounts bằng kỹ thuật Append-Only không khóa hoặc Phân mảnh tài khoản (Sharded Accounts).