Dữ liệu thanh toán cho Data & BI

Đây là bài khép lại series Thanh toán & Chuyển tiền chuyên sâu. Sau khi đã đi qua tổng quan hệ thống thanh toán, chuẩn bản tin ISO 20022, định tuyến, quyết toán và đối soát, bài này chuyển góc nhìn từ người vận hành sang người làm dữ liệu: làm sao biến dòng chảy giao dịch thanh toán thành các chỉ số, cảnh báo và dashboard giúp ngân hàng chạy trơn tru.

Nếu bạn mới vào series, nên đọc trước Tổng quan thanh toán và ISO 20022 để nắm vốn từ vựng; còn phần đối soát chi tiết nằm ở Đối soát thanh toán.

1. Vì sao dữ liệu thanh toán lại quý

Dữ liệu thanh toán là một trong những tài sản dữ liệu giá trị nhất mà một ngân hàng sở hữu, vì bốn đặc tính:

• Khối lượng lớn và liên tục. Một ngân hàng bán lẻ cỡ trung xử lý hàng triệu giao dịch mỗi ngày qua nhiều kênh: chuyển khoản nhanh 24/7 (NAPAS 247), RTGS/IBPS, thẻ, ví điện tử, thu hộ/chi hộ. Đây là nguồn sự kiện dày đặc, đều đặn, phản ánh nhịp đập của toàn hệ thống.
• Tính thời gian thực. Khác với dữ liệu cuối ngày của kế toán, thanh toán diễn ra theo giây. Một sự cố định tuyến hay nghẽn hạn mức thanh khoản cần được nhìn thấy ngay, không phải sáng hôm sau.
• Phản ánh hành vi và rủi ro. Mỗi giao dịch mang thông tin ai trả cho ai, bao nhiêu, kênh nào, mục đích gì, vào giờ nào. Đây là nguyên liệu thô cho phân tích hành vi khách hàng, phát hiện gian lận, và giám sát AML.
• Là điểm giao của nhiều bộ phận. Cùng một tập dữ liệu phục vụ: vận hành (Ops — STP rate, exception aging), giám sát (NOC — throughput, độ trễ), tài chính (Treasury — vị thế nostro), tuân thủ (AML — mẫu bất thường), và BI (xu hướng doanh thu phí).

Vì phục vụ nhiều "khách hàng nội bộ" như vậy, xây một mô hình dữ liệu thanh toán chuẩn hóa và một lớp KPI dùng chung là bài toán nền tảng.

2. Mô hình dữ liệu thanh toán

Ở kho dữ liệu, ta thường mô hình hóa thanh toán theo dạng star schema: một bảng fact trung tâm ghi từng giao dịch, bao quanh là các dimension mô tả bối cảnh.

Bảng fact: payment / transaction

Mỗi dòng là một giao dịch thanh toán, với các nhóm cột:

• Định danh & liên kết: payment_id, end_to_end_id (ID xuyên suốt theo ISO 20022), debtor_account, creditor_account, debtor_bank, creditor_bank.
• Số tiền & loại tiền: amount, currency, và có thể amount_local (quy đổi VND để so sánh).
• Kênh & tuyến: channel (mobile, internet banking, ATM, quầy, API), scheme (NAPAS 247, IBPS/RTGS, SWIFT), corridor (cặp quốc gia/ngân hàng với giao dịch quốc tế), purpose_code.
• Trạng thái: status (xem vòng đời bên dưới), reject_reason / return_code.
• Dấu thời gian (timestamps): đây là phần quan trọng nhất cho KPI. Tối thiểu nên có initiated_at (khởi tạo), validated_at, cleared_at (bù trừ), và settled_at (quyết toán). Chênh lệch giữa các mốc này chính là các loại latency.

Vòng đời trạng thái

Một giao dịch đi qua chuỗi trạng thái, và mô hình dữ liệu nên ghi lại được từng bước (hoặc ít nhất trạng thái cuối cùng cùng timestamp tương ứng):

initiated → validated → cleared → settled
                 │           │
                 └──────────►└──────► returned / rejected

• initiated: khách hàng bấm gửi, hệ thống ghi nhận.
• validated: qua kiểm tra số dư, hạn mức, sàng lọc AML/sanctions, định dạng bản tin.
• cleared: bản tin đã được trao đổi và đối chiếu qua hệ chuyển mạch/bù trừ.
• settled: tiền đã thực sự chuyển giao giữa hai ngân hàng (quyết toán).
• returned / rejected: bị từ chối (rejected — thường ở khâu validate) hoặc bị trả lại (returned — sau khi đã gửi đi nhưng ngân hàng nhận không ghi có được, ví dụ sai tài khoản).

Phân biệt rejected và returned rất quan trọng vì chúng chỉ ra vấn đề ở những khâu khác nhau: reject nhiều thường là lỗi phía đầu vào/khách hàng, return nhiều thường là lỗi dữ liệu người thụ hưởng hoặc đối tác.

Các dimension

• dim_bank: BIC/mã ngân hàng, tên, quốc gia — dùng chung cho cả debtor và creditor bank.
• dim_channel: kênh khởi tạo và thuộc tính (self-service hay có người, phí).
• dim_corridor: cặp tuyến thanh toán, dùng cho giao dịch xuyên biên giới.
• dim_purpose: mã mục đích (lương, hóa đơn, thương mại...), hữu ích cho AML và BI.
• dim_date / dim_time: để cắt theo ngày, giờ, ngày lễ, giờ cao điểm.

3. KPI vận hành cần theo dõi

Dưới đây là bộ chỉ số cốt lõi mà bất kỳ dashboard giám sát thanh toán nào cũng nên có.

Vài lưu ý thực chiến:

• STP rate là chỉ số "sức khỏe" hàng đầu. STP giảm nghĩa là Ops phải sửa tay nhiều hơn — chi phí, độ trễ và rủi ro sai sót đều tăng. Mục tiêu thường là >95%.
• Throughput peak quan trọng hơn trung bình khi lập kế hoạch năng lực. Đỉnh thường rơi vào giờ trưa, cuối tháng (trả lương) và dịp lễ Tết.
• Latency nên nhìn theo percentile, không nhìn trung bình — p99 mới cho thấy trải nghiệm tệ nhất khách gặp.
• Exception aging: giao dịch treo càng lâu, khả năng khiếu nại và rủi ro càng cao.

4. Các dạng phân tích thường gặp

Ngoài dashboard KPI, đội dữ liệu thanh toán thường phục vụ các phân tích sâu hơn:

• Đối soát (reconciliation): join dữ liệu nội bộ (những gì hệ thống của ta ghi nhận) với sao kê từ đối tác / hệ chuyển mạch (những gì họ ghi nhận), để tìm chênh lệch: giao dịch có ở ta mà không có ở họ, hoặc lệch số tiền. Chi tiết ở bài đối soát.
• Phát hiện bất thường theo giờ: so sánh phân bố giao dịch theo giờ với baseline lịch sử. Một cú sụt throughput lúc 10h sáng ngày thường có thể là dấu hiệu sự cố kênh.
• Phân tích return codes: nhóm các mã trả về theo thời gian và theo đối tác để phát hiện một ngân hàng nhận đang có vấn đề, hay một loại lỗi dữ liệu đang gia tăng.
• Giám sát thanh khoản nostro: theo dõi dòng tiền vào/ra tài khoản nostro để đảm bảo đủ số dư quyết toán; cảnh báo khi vị thế tiến gần hạn mức.

5. Chất lượng dữ liệu và bảo mật

• ISO 20022 giúp dữ liệu có cấu trúc. Vì bản tin được định nghĩa theo schema XML rõ ràng (các trường như số tiền, mục đích, bên liên quan đều có vị trí xác định), việc trích xuất vào kho dữ liệu sạch và nhất quán hơn nhiều so với các định dạng cũ dạng free-text. Đây là lợi thế lớn cho phân tích.
• Dữ liệu thanh toán là dữ liệu nhạy cảm. Nó chứa PII (tên, số tài khoản) và thông tin tài chính. Nguyên tắc: mask/hash số tài khoản và thông tin định danh khi đưa vào môi trường phân tích; phân quyền chặt; và tuân thủ quy định bảo vệ dữ liệu. Phần lớn phân tích vận hành (STP, throughput, return rate) không cần biết danh tính khách — chỉ cần dữ liệu tổng hợp.

6. Đưa dữ liệu ra near-real-time

Dashboard giám sát chỉ hữu ích khi dữ liệu tươi. Cách phổ biến là dùng CDC (Change Data Capture) để bắt thay đổi từ hệ giao dịch (thường là Oracle của core banking) và đẩy qua một hệ thống streaming như Kafka, rồi từ đó nạp vào kho dữ liệu / công cụ BI với độ trễ chỉ vài giây đến vài phút.

Luồng trên có hai nhánh: nhánh stream (CDC → Kafka → giám sát/kho) cho các KPI cần tức thời, và nhánh batch (ETL cuối ngày → kho) cho đối soát và báo cáo tài chính đòi hỏi số liệu chốt sổ. Chi tiết kỹ thuật của hai mảnh này nằm ở Oracle CDC — Tổng quan và Kiến trúc Kafka.

7. Ví dụ SQL phân tích thanh toán (chạy được trên sandbox)

SQL Builder trong sandbox dùng PostgreSQL và chỉ chạy một câu SELECT/WITH/EXPLAIN. Schema mẫu (dữ liệu nhỏ):

• customers(id, full_name, city, created_at)
• accounts(id, customer_id, account_no, balance, currency)
• transactions(id, account_id, amount, kind, created_at) — coi mỗi dòng là một giao dịch thanh toán
• employees(...), departments(...) — không dùng ở đây.

Lưu ý quan hệ: transactions.account_id → accounts.id, và tên khách hàng lấy từ customers.full_name qua accounts.customer_id (không có cột customer_name).

7.1. Tổng giá trị và số lượng giao dịch theo loại (kind)

Đây chính là KPI "giá trị & khối lượng theo kênh" ở quy mô nhỏ: coi kind như kênh/loại thanh toán.

▶ Chạy được trong SQL Builder

SELECT
    kind,
    COUNT(*)              AS so_giao_dich,
    SUM(amount)           AS tong_gia_tri,
    ROUND(AVG(amount), 2) AS gia_tri_trung_binh
FROM transactions
GROUP BY kind
ORDER BY tong_gia_tri DESC;

7.2. Giá trị thanh toán theo ngày

Mô phỏng biểu đồ xu hướng theo ngày trên dashboard. Dùng to_char để gom theo ngày.

▶ Chạy được trong SQL Builder

SELECT
    to_char(created_at, 'YYYY-MM-DD') AS ngay,
    COUNT(*)                          AS so_giao_dich,
    SUM(amount)                       AS tong_gia_tri
FROM transactions
GROUP BY to_char(created_at, 'YYYY-MM-DD')
ORDER BY ngay;

7.3. Top tài khoản theo dòng tiền (kèm tên khách hàng)

Phân tích "top payer/payee": tài khoản nào phát sinh dòng tiền lớn nhất. Join xuyên transactions → accounts → customers để lấy tên.

▶ Chạy được trong SQL Builder

SELECT
    a.account_no,
    c.full_name,
    COUNT(t.id)    AS so_giao_dich,
    SUM(t.amount)  AS tong_dong_tien
FROM transactions t
JOIN accounts  a ON t.account_id = a.id
JOIN customers c ON a.customer_id = c.id
GROUP BY a.account_no, c.full_name
ORDER BY tong_dong_tien DESC
LIMIT 5;

7.4. Phân bố giao dịch theo giờ trong ngày

Đây là nền tảng cho "phát hiện bất thường theo giờ" và cho việc lập kế hoạch năng lực (tìm giờ cao điểm). Dùng extract(hour ...).

▶ Chạy được trong SQL Builder

SELECT
    EXTRACT(HOUR FROM created_at) AS gio,
    COUNT(*)                      AS so_giao_dich,
    SUM(amount)                   AS tong_gia_tri
FROM transactions
GROUP BY EXTRACT(HOUR FROM created_at)
ORDER BY gio;

7.5. Tỷ trọng giá trị mỗi loại giao dịch (dùng CTE)

Một chỉ số hay dùng trên dashboard: mỗi kênh chiếm bao nhiêu phần trăm tổng giá trị. Dùng WITH để tính tổng trước rồi chia.

▶ Chạy được trong SQL Builder

WITH tong AS (
    SELECT SUM(amount) AS tong_toan_bo
    FROM transactions
)
SELECT
    t.kind,
    SUM(t.amount)                                          AS gia_tri,
    ROUND(100.0 * SUM(t.amount) / MAX(g.tong_toan_bo), 2)  AS ty_trong_phan_tram
FROM transactions t
CROSS JOIN tong g
GROUP BY t.kind
ORDER BY gia_tri DESC;

Mẹo: cả 5 câu đều là một câu lệnh và dùng đúng tên cột schema mẫu, dán thẳng vào SQL Builder là chạy. Muốn xem kế hoạch thực thi, thêm EXPLAIN ở đầu câu.

8. Use case thực tế: dashboard giám sát thanh toán real-time

Hình dung một màn hình lớn treo trong phòng vận hành thanh toán (Payment NOC), làm mới mỗi vài giây nhờ luồng CDC → Kafka ở mục 6:

• Ô "STP rate" (số lớn ở giữa). Hiển thị STP rate của 15 phút gần nhất, kèm mũi tên so với cùng kỳ hôm qua. Nền xanh nếu >95%, vàng 90–95%, đỏ <90%. Khi tụt xuống đỏ, Ops biết ngay có làn giao dịch đang bị đẩy sang xử lý tay.
• Biểu đồ throughput theo thời gian. Đường giao dịch/giây, chồng lên đường baseline lịch sử (đường đứt). Nếu đường thực tế rơi khỏi baseline đột ngột → nghi có nghẽn kênh hoặc downtime của một scheme.
• Bảng "Return/Reject reasons". Top mã lỗi trong 1 giờ qua, sắp theo số lượng. Một mã bỗng nhảy vọt (ví dụ "sai tài khoản người nhận" tăng gấp 5) là tín hiệu điều tra ngay, có thể do một đối tác lỗi hệ thống.
• Latency p95/p99. Đo settled_at − initiated_at. Đuôi p99 phình to nghĩa là một tỷ lệ nhỏ khách hàng đang chờ lâu bất thường.
• Exception aging. Danh sách giao dịch treo, sắp theo thời gian tồn đọng giảm dần, để Ops xử lý cái cũ nhất trước.
• Thanh khoản nostro. Với thanh toán quốc tế: số dư nostro theo từng ngân hàng đại lý, cảnh báo khi tiến gần ngưỡng.

Điểm mấu chốt là toàn bộ dashboard này chỉ là các câu SQL tổng hợp (rất giống mục 7, chỉ khác quy mô và tần suất) chạy trên dữ liệu được CDC cập nhật liên tục, cộng với một lớp cảnh báo đẩy ra kênh on-call khi ngưỡng bị phá. Muốn xem một ví dụ dashboard ngân hàng hoàn chỉnh hơn, tham khảo Case study dashboard ngân hàng.

9. Ghi nhớ

• Dữ liệu thanh toán quý vì khối lượng lớn, thời gian thực, phản ánh hành vi & rủi ro, và phục vụ nhiều bộ phận cùng lúc.
• Mô hình hóa theo star schema: một fact giao dịch (số tiền, các bên, kênh, trạng thái, và bộ timestamps initiated/cleared/settled) bao quanh bởi các dimension (bank, channel, corridor, purpose, date).
• Bộ KPI cốt lõi: STP rate, throughput (peak!), latency theo percentile, failure/return rate, reject reason mix, giá trị/khối lượng theo kênh, exception aging.
• Phân biệt rejected (lỗi đầu vào, khâu validate) và returned (lỗi phía nhận, sau khi gửi) — chúng chỉ ra vấn đề ở khâu khác nhau.
• ISO 20022 làm dữ liệu có cấu trúc, dễ trích xuất; nhưng dữ liệu thanh toán là nhạy cảm — mask PII và phân quyền chặt.
• Để dashboard tươi, dùng CDC → Kafka cho nhánh near-real-time và batch ETL cho đối soát/báo cáo chốt sổ.
• Trong SQL Builder (PostgreSQL, một câu SELECT/WITH): dùng GROUP BY kind, to_char(created_at,'YYYY-MM-DD'), extract(hour ...), và join transactions → accounts → customers để tái tạo các KPI thu nhỏ.

Bài liên quan: Tổng quan thanh toán · ISO 20022 · Đối soát thanh toán · Oracle CDC · Kafka · Dashboard ngân hàng