Open Banking 8 — Dữ liệu Open Banking cho phân tích & NCB

Open Banking là một câu chuyện dữ liệu

Xuyên suốt series này — từ tổng quan, API & chuẩn, consent & bảo mật, tổng hợp tài khoản, khởi tạo thanh toán, đến chia sẻ dữ liệu & riêng tư và hệ sinh thái fintech — có một sợi chỉ đỏ xuyên qua tất cả: dữ liệu. Open Banking bản chất là việc mở luồng dữ liệu tài khoản và giao dịch của khách hàng ra ngoài bức tường của một ngân hàng, có kiểm soát bằng consent. Vì vậy nó vừa tạo ra một khối lượng dữ liệu chưa từng có, vừa đòi hỏi năng lực dữ liệu để vận hành và khai thác.

Bài kết này gộp lại toàn bộ series dưới lăng kính người làm dữ liệu: Open Banking sinh ra nguồn dữ liệu gì, giải bài toán phân tích nào, kiến trúc và quản trị ra sao, đo lường nền tảng thế nào, và NCB nên đi theo lộ trình nào.

Bốn nguồn dữ liệu Open Banking tạo ra

• Dữ liệu tổng hợp tài khoản đa ngân hàng. Khi NCB đóng vai AISP hoặc hợp tác với aggregator (xem account aggregation), ta không chỉ thấy tài khoản khách mở tại NCB mà cả bức tranh tài chính của họ trải trên nhiều ngân hàng. Đây là dữ liệu quý nhất và cũng khó nhất vì phải chuẩn hoá từ nhiều nguồn.
• Lịch sử giao dịch phong phú. Từng dòng ghi nợ/ghi có, số tiền, thời điểm, diễn giải, đối tác. Đây là "dấu vân tay" hành vi tài chính của khách — nền tảng cho gần như mọi mô hình phân tích.
• Dữ liệu consent. Ai đã đồng ý chia sẻ gì, cho TPP nào, mục đích gì, hiệu lực đến bao giờ. Consent không phải cờ boolean mà là dữ liệu có vòng đời, phải lưu và truy vấn được.
• Log truy cập API. Mỗi lần một TPP gọi endpoint để lại một dòng log: ai gọi, gọi gì, khi nào, thành công hay lỗi, độ trễ. Đây vừa là bằng chứng audit vừa là nguồn đo lường hiệu quả nền tảng.

Các bài toán phân tích cốt lõi

Từ bốn nguồn trên, sáu nhóm bài toán phân tích nổi lên rõ nhất:

1. Phân loại & enrichment giao dịch. Diễn giải giao dịch thô ("CK QUA MB VCB...") gần như vô nghĩa cho phân tích. Bước enrichment gán mỗi giao dịch một danh mục (ăn uống, lương, điện nước, vay, đầu tư), một merchant chuẩn hoá, một chiều tiền thống nhất. Đây là nền tảng cho mọi thứ phía sau — không phân loại được thì không hiểu được hành vi.

2. Chân dung tài chính khách hàng (360 view). Gộp tài khoản, số dư, dòng tiền, sản phẩm đang dùng thành một hồ sơ duy nhất cho mỗi khách. Từ đó tính các đặc trưng: thu nhập ước lượng, mức chi tiêu, tỷ lệ tiết kiệm, độ ổn định dòng tiền.

3. Chấm điểm tín dụng thay thế từ dòng tiền. Thay vì chỉ dựa vào lịch sử tín dụng truyền thống (CIC), dữ liệu giao dịch cho phép chấm điểm dựa trên dòng tiền thực: thu nhập đều đặn không, có bị âm quỹ thường xuyên không, tỷ lệ trả nợ trên thu nhập bao nhiêu. Cách tiếp cận này đặc biệt giá trị cho nhóm khách "thin file" ít lịch sử tín dụng. Chi tiết mô hình xem chấm điểm & scorecard.

4. Phát hiện gian lận & AML realtime. Luồng thanh toán mở (payment initiation) tạo bề mặt tấn công mới. Phân tích trên dòng giao dịch giúp phát hiện bất thường (số tiền lệch chuẩn, tần suất đột biến, mẫu chuyển tiền lòng vòng) theo thời gian thực để chặn gian lận và sàng lọc rửa tiền. Nền tảng nghiệp vụ xem AML tổng quan.

5. Cá nhân hoá sản phẩm & dự báo dòng tiền. Hiểu hành vi cho phép gợi ý đúng sản phẩm (khách hay chi tiêu thẻ → gợi ý thẻ hoàn tiền; khách có số dư nhàn rỗi → gợi ý tiết kiệm), và dự báo dòng tiền để cảnh báo sớm rủi ro thấu chi.

6. Đo hiệu quả API & đối tác. Phân tích chính log API: TPP nào gọi nhiều, tỷ lệ lỗi ở đâu, sản phẩm API nào tạo doanh thu — vòng lặp phản hồi để tối ưu nền tảng.

Kiến trúc dữ liệu cho Open Banking

Về mặt kỹ thuật, một nền dữ liệu Open Banking đi từ sự kiện API thô đến mô hình/ML, xuyên suốt bởi một tầng quản trị consent. Sơ đồ dưới minh hoạ kiến trúc điển hình:

Bốn tầng chính:

• Thu thập sự kiện (streaming). Mỗi lần gọi API AIS/PIS, mỗi giao dịch, mỗi thay đổi consent phát ra một event. Đẩy vào một hàng đợi streaming (Kafka) cho phép xử lý gần realtime — điều kiện bắt buộc cho fraud/AML. Đây là điểm khác biệt lớn so với batch ETL truyền thống.
• Chuẩn hoá theo chuẩn giao dịch. Như đã phân tích ở bài 4, mỗi ngân hàng trả dữ liệu với cấu trúc, quy ước dấu và múi giờ khác nhau. Tầng này ép tất cả về một schema thống nhất (amount có dấu chuẩn, timestamp UTC, mã danh mục chuẩn) rồi enrichment. Không có tầng này, kho dữ liệu chỉ là đống rác có tổ chức.
• Kho phân tích / lakehouse. Mô hình phân lớp bronze (thô) → silver (đã chuẩn hoá) → gold (đã mô hình hoá cho phân tích). Lakehouse cho phép vừa lưu rẻ khối lượng lớn vừa truy vấn SQL và chạy ML trên cùng một chỗ. Nền tảng lakehouse xem data engineering — lakehouse.
• Khai thác. ML cho scoring/fraud/dự báo và BI cho KPI nền tảng — đọc chủ yếu từ tầng gold.

Điểm khác biệt so với data platform thông thường: tầng quản trị consent xuyên suốt. Nó không nằm tách rời mà "chèn ngang" vào mọi tầng khai thác — quyết định event nào được enrichment cho mục đích nào, dữ liệu nào được đưa vào truy vấn nào, feature nào hợp lệ cho mô hình nào. Chi tiết nguyên tắc chia sẻ & purpose limitation xem chia sẻ dữ liệu & riêng tư.

Chất lượng & lineage

Vì dữ liệu đến từ nhiều nguồn ngoài tầm kiểm soát, chất lượng là rủi ro thường trực: trường thiếu, dấu ngược, trùng lặp giao dịch, timestamp lệch. Cần các kiểm tra tự động (test tính đầy đủ, hợp lệ, nhất quán) ngay tại tầng chuẩn hoá, và lineage — truy vết mỗi bản ghi gold về nguồn thô nào — để khi mô hình sai còn lần được gốc. Khung chất lượng dữ liệu xem governance — data quality.

Quản trị: chỉ dùng đúng mục đích consent

Đây là ranh giới không được vượt. Khách đồng ý chia sẻ dữ liệu cho một mục đích cụ thể — ví dụ "để đánh giá khoản vay" — thì dữ liệu đó không được dùng cho mục đích khác như marketing chéo, trừ khi có consent riêng. Nguyên tắc purpose limitation (giới hạn mục đích) và data minimization (tối thiểu hoá) từ bài 6 phải được cài đặt thành cơ chế kỹ thuật, không chỉ là chính sách trên giấy:

• Gán nhãn mục đích cho dữ liệu và feature. Mỗi dataset/feature mang metadata "hợp lệ cho mục đích X". Pipeline từ chối join dữ liệu mục đích A vào mô hình mục đích B.
• Kiểm soát truy cập theo mục đích, không chỉ theo vai trò. Một data scientist có quyền đọc dữ liệu giao dịch không có nghĩa được đọc mọi giao dịch — chỉ những giao dịch có consent phủ đúng mục đích họ đang làm.
• Audit đầy đủ. Mọi truy cập dữ liệu nhạy cảm để lại log bất biến. Đây là bằng chứng tuân thủ Nghị định 13/2023/NĐ-CP và là công cụ điều tra khi có sự cố.

Khung tuân thủ riêng tư tổng thể xem governance — privacy & compliance. Bảo mật kỹ thuật (mã hoá, kiểm soát truy cập, khoá) xem access & crypto.

Đo lường nền tảng API

Khi NCB mở API cho TPP, nền tảng API trở thành một sản phẩm và phải được đo như sản phẩm. Các KPI cốt lõi (chi tiết khung đo xem BI — metrics & KPI):

Tỷ lệ thành công thấp ở một endpoint có thể do TPP gửi request sai (lỗi 4xx — vấn đề tài liệu/onboarding) hoặc do hệ thống ta (lỗi 5xx — vấn đề vận hành). Tách hai loại này ra là bước đầu để cải thiện đúng chỗ.

Minh hoạ SQL trên sandbox

Sandbox có schema đơn giản (customers, accounts, transactions, ...) không phải schema Open Banking đầy đủ, nhưng đủ để minh hoạ tinh thần của phân tích giao dịch. Truy vấn đầu tiên dựng một "profile dòng tiền" theo thành phố — nền cho 360 view: đếm khách, giao dịch trung bình, tổng ghi có và ghi nợ.

-- ▶ Chạy được
SELECT c.city,
       COUNT(DISTINCT c.id)                                  AS so_khach,
       COUNT(t.id)                                           AS so_giao_dich,
       ROUND(AVG(t.amount)::numeric, 2)                      AS gd_trung_binh,
       SUM(CASE WHEN t.amount > 0 THEN t.amount ELSE 0 END)  AS tong_ghi_co,
       SUM(CASE WHEN t.amount < 0 THEN -t.amount ELSE 0 END) AS tong_ghi_no
FROM transactions t
JOIN accounts  a ON t.account_id = a.id
JOIN customers c ON a.customer_id = c.id
GROUP BY c.city
ORDER BY tong_ghi_co DESC;

Chú ý AVG(...) trả double precision nên phải ép ::numeric trước khi ROUND(..., 2). Cùng ý tưởng phân tách ghi nợ/ghi có bằng CASE chính là mầm mống của bước phân loại giao dịch ở quy mô thật — chỉ khác là ta thay điều kiện dấu bằng mô hình phân loại danh mục.

Use case thực tế

Bối cảnh. NCB triển khai một sản phẩm cho vay tiêu dùng nhanh dựa trên dữ liệu Open Banking. Khách hàng cấp consent cho phép NCB (hoặc aggregator đối tác) đọc lịch sử giao dịch 12 tháng từ các ngân hàng khác. NCB muốn hai thứ trên cùng luồng dữ liệu đó: chấm điểm khoản vay từ dòng tiền và giám sát gian lận realtime.

Con số ước lượng (minh hoạ). Giả định NCB có 50.000 khách bật consent trong quý đầu, mỗi khách trung bình 300 giao dịch/năm → khoảng 15 triệu dòng giao dịch cần chuẩn hoá và enrichment. Nhóm "thin file" (ít lịch sử CIC) chiếm ~35% đơn vay; với nhóm này, mô hình dòng tiền giúp phê duyệt thêm ước tính 8–12% đơn mà scorecard truyền thống từ chối vì thiếu dữ liệu, đồng thời giữ tỷ lệ nợ xấu trong ngưỡng nhờ tín hiệu dòng tiền thực. Các số này là minh hoạ để hình dung quy mô, không phải số liệu thật.

Chấm điểm từ dòng tiền. Với mỗi khách, tính vài đặc trưng nền tảng từ giao dịch: dòng tiền ròng, số dư trung bình, tần suất giao dịch. Truy vấn dưới dựng khung đặc trưng thô (mô hình thật sẽ thêm nhiều feature và một scorecard — xem credit scoring):

-- ▶ Chạy được
SELECT c.id,
       c.full_name,
       COUNT(t.id)                        AS so_giao_dich,
       ROUND(SUM(t.amount)::numeric, 2)   AS dong_tien_rong,
       ROUND(AVG(a.balance)::numeric, 2)  AS so_du_trung_binh
FROM customers c
JOIN accounts  a ON a.customer_id = c.id
JOIN transactions t ON t.account_id = a.id
GROUP BY c.id, c.full_name
HAVING COUNT(t.id) >= 5
ORDER BY dong_tien_rong DESC
LIMIT 20;

Điều kiện HAVING COUNT(t.id) >= 5 phản ánh nguyên tắc thực chiến: khách quá ít giao dịch thì tín hiệu dòng tiền không đủ tin cậy để chấm điểm — cần fallback về đánh giá truyền thống.

Giám sát gian lận realtime. Trên cùng dòng giao dịch, một quy tắc phát hiện bất thường đơn giản nhưng hiệu quả là z-score: đánh dấu giao dịch lệch quá 3 lần độ lệch chuẩn so với trung bình của chính tài khoản đó. Trong sản xuất, phép tính này chạy trên stream (Kafka) để chặn trong mili-giây; trên sandbox ta minh hoạ bằng một truy vấn:

-- ▶ Chạy được
WITH stat AS (
    SELECT account_id,
           AVG(amount)::numeric    AS trung_binh,
           STDDEV(amount)::numeric AS do_lech_chuan
    FROM transactions
    GROUP BY account_id
)
SELECT t.id,
       t.account_id,
       t.amount,
       t.created_at,
       ROUND(s.trung_binh, 2)                                  AS tb_tai_khoan,
       ROUND((t.amount - s.trung_binh) / s.do_lech_chuan, 2)   AS z_score
FROM transactions t
JOIN stat s ON s.account_id = t.account_id
WHERE s.do_lech_chuan > 0
  AND ABS(t.amount - s.trung_binh) > 3 * s.do_lech_chuan
ORDER BY ABS(t.amount - s.trung_binh) DESC
LIMIT 20;

Mọi dòng trả về là một giao dịch "lệch chuẩn" đáng soi. Đây là luật cơ sở (baseline) — hệ thống AML thật kết hợp nhiều luật và mô hình (mẫu chuyển tiền lòng vòng, tốc độ, danh sách đen) — nhưng nó cho thấy cách biến nghiệp vụ AML thành phép tính chạy được trên dữ liệu Open Banking.

Lộ trình NCB & tổng kết series

Từ góc dữ liệu, hành trình Open Banking của NCB nên đi theo bốn giai đoạn, mỗi giai đoạn xây trên nền của giai đoạn trước:

• GĐ1 — Mở API cơ bản. Developer portal, sandbox, OAuth2, consent tối thiểu, log API. Mục tiêu dữ liệu: dựng tầng thu thập event và log ngay từ đầu — kể cả khi lưu lượng còn nhỏ.
• GĐ2 — AIS/PIS. Tổng hợp tài khoản và khởi tạo thanh toán. Đây là lúc tầng chuẩn hoá + enrichment và consent ledger phải trưởng thành; bắt đầu có dữ liệu đủ cho scoring và fraud.
• GĐ3 — BaaS / embedded finance. NCB cung cấp năng lực ngân hàng cho bên thứ ba nhúng vào sản phẩm của họ (hệ sinh thái fintech). API trở thành dòng doanh thu; KPI nền tảng trở nên trọng yếu.
• GĐ4 — Open Finance. Mở rộng khỏi tài khoản thanh toán sang bảo hiểm, đầu tư, tín dụng — bức tranh tài chính toàn diện của khách.

Nền dữ liệu & tuân thủ cần chuẩn bị trước, không đợi: streaming ingestion, chuẩn hoá giao dịch, lakehouse phân lớp, consent ledger + audit log, kiểm soát truy cập theo mục đích, khung chất lượng & lineage, và bộ KPI nền tảng. Những thứ này mất thời gian xây, nên bắt đầu từ GĐ1 mới kịp cho GĐ2–3.

Tổng kết series. Open Banking không phải một dự án API — nó là chuyển dịch trong cách ngân hàng nghĩ về dữ liệu khách hàng: từ "tài sản độc quyền của ta" sang "tài nguyên khách sở hữu, ta giữ hộ và được phép khai thác trong giới hạn consent". Ngân hàng thắng cuộc là ngân hàng biến niềm tin đó thành sản phẩm an toàn, minh bạch, hữu ích, và có nền dữ liệu đủ mạnh để làm ở quy mô. Đó là lý do bài kết của series lại là một bài về dữ liệu.

Ghi nhớ

• Open Banking vừa tạo ra vừa cần dữ liệu: tổng hợp tài khoản đa ngân hàng, lịch sử giao dịch, dữ liệu consent, log API — bốn nguồn giá trị cho phân tích.
• Sáu bài toán chủ lực: phân loại/enrichment giao dịch, 360 view, chấm điểm tín dụng từ dòng tiền, fraud/AML realtime, cá nhân hoá & dự báo, đo hiệu quả API.
• Kiến trúc: streaming ingestion → chuẩn hoá theo chuẩn giao dịch → lakehouse bronze/silver/gold → ML & BI, với tầng quản trị consent xuyên suốt mọi tầng khai thác.
• Tầng chuẩn hoá + enrichment là nơi tạo giá trị — thiếu nó, dữ liệu đa nguồn chỉ là rác có tổ chức. Chất lượng & lineage là rủi ro thường trực phải kiểm soát tự động.
• Quản trị = chỉ dùng đúng mục đích consent: gán nhãn mục đích cho feature, kiểm soát truy cập theo mục đích chứ không chỉ theo vai trò, audit đầy đủ (Nghị định 13/2023/NĐ-CP).
• Đo nền tảng như sản phẩm: số TPP, lượng gọi, tỷ lệ thành công, độ trễ p95, doanh thu API, sức khoẻ consent.
• Lộ trình NCB bốn giai đoạn: API cơ bản → AIS/PIS → BaaS/embedded → Open Finance; nền dữ liệu và tuân thủ phải chuẩn bị từ giai đoạn đầu.
• Fraud/AML và scoring dùng chung một luồng dữ liệu giao dịch — z-score baseline và đặc trưng dòng tiền là điểm khởi đầu chạy được, mô hình thật xây thêm từ đó.

Nguồn tham khảo

• Open Banking Limited (UK) — Open Banking Standard & Read/Write API Specifications (standards.openbanking.org.uk)
• ISO 20022 — Universal financial industry message scheme (bao gồm External Code Sets: Purpose Codes, Category Purpose Codes dùng để phân loại giao dịch) — iso20022.org
• The Berlin Group — NextGenPSD2 XS2A Framework (API tổng hợp tài khoản & khởi tạo thanh toán) — berlin-group.org
• European Union — Directive (EU) 2015/2366 (PSD2) về dịch vụ thanh toán, nền tảng pháp lý của Open Banking tại EU
• Nghị định 13/2023/NĐ-CP về bảo vệ dữ liệu cá nhân (Chính phủ Việt Nam)
• Basel Committee on Banking Supervision (BIS) — "Report on open banking and application programming interfaces" (2019) </content>