Modeling nâng cao 8 — Mô hình hoá dữ liệu Ngân hàng

Mô hình tinh thần: ngân hàng là một cỗ máy "hợp đồng"

Sau bảy bài của series Data Modeling nâng cao — dimensional nâng cao, SCD nâng cao, Data Vault, semantic/metrics layer — bài này là buổi tổng kết: đặt toàn bộ kỹ thuật vào một ngành cụ thể, khắc nghiệt nhất về dữ liệu và tuân thủ: ngân hàng.

Trước khi vẽ bảng, hãy nắm một mô hình tinh thần chung mà mọi kiến trúc tham chiếu ngân hàng đều chia sẻ. Ngân hàng, về bản chất dữ liệu, là một cỗ máy quản lý hợp đồng (arrangement) giữa các bên (party): một tài khoản tiền gửi là hợp đồng giữa khách hàng và ngân hàng; một khoản vay là hợp đồng tín dụng; một thẻ, một hạn mức, một hợp đồng phái sinh — tất cả đều là arrangement. Mỗi hợp đồng gắn với một sản phẩm (product), sinh ra giao dịch (transaction) và sự kiện (event), và cuối cùng mọi thứ phải khớp về sổ cái kế toán (General Ledger).

Sáu khái niệm lõi — party / customer, account, arrangement, transaction, product, GL — là "danh từ" của mọi ngân hàng. Điểm mấu chốt: các mô hình tham chiếu ngành (BIAN, IBM FSDM, Teradata FSLDM) khác nhau ở cách đóng gói, nhưng đều xoay quanh đúng những danh từ này.

Toàn bộ DDL/SQL trong bài là (minh hoạ) cho sandbox PostgreSQL, nhằm cho thấy cấu trúc và ý tưởng, không phải schema production của một core cụ thể. Con số dùng để minh hoạ.

Mô hình dữ liệu lõi ngân hàng

Vài quyết định thiết kế đáng lưu ý, đều rút ra từ các bài trước:

• Party tách khỏi Customer role. Một party (con người/tổ chức) có thể đóng nhiều vai cùng lúc: chủ tài khoản, người bảo lãnh, người thụ hưởng, đối tác. Nếu gộp "customer" và "party" làm một, bạn sẽ không mô hình hoá nổi tình huống một cá nhân vừa là khách vay vừa là người bảo lãnh cho khoản vay khác. Tách PARTY + PARTY_ROLE là chuẩn mực chung của cả BIAN lẫn FSDM.
• Arrangement là trục trung tâm, không phải Account. Account là cách hiện thực hoá một arrangement (một hợp đồng tín dụng hạn mức có thể sinh nhiều tài khoản giải ngân). Đặt arrangement làm trục giúp gắn đúng sản phẩm, điều khoản, và trạng thái pháp lý.
• Transaction luôn phải khớp GL. Mọi giao dịch nghiệp vụ đều có bút toán kế toán tương ứng (GL_ENTRY) theo hệ thống tài khoản (chart of accounts). Đây là ràng buộc đối chiếu (reconciliation) sống còn: tổng số dư tài khoản khách phải khớp số dư GL cuối ngày.

Ba mô hình tham chiếu ngành (giới thiệu, định tính)

Bạn hiếm khi thiết kế mô hình ngân hàng từ số 0 — thường sẽ mượn khung của một mô hình tham chiếu ngành rồi tuỳ biến. Ba khung phổ biến nhất:

BIAN (Banking Industry Architecture Network) là một tổ chức phi lợi nhuận xây dựng kiến trúc tham chiếu hướng dịch vụ cho ngành ngân hàng. Đơn vị cốt lõi của BIAN không phải là bảng, mà là Service Domain — một đơn vị năng lực nghiệp vụ nguyên tử (ví dụ "Current Account", "Customer Relationship Management", "Payment Order", "Credit Facility"). Mỗi service domain quản lý một loại "Control Record" và phơi ra các "Service Operation". BIAN mô tả ngân hàng làm gì (capability map) hơn là dữ liệu lưu ra sao, nên nó bổ trợ — chứ không thay thế — một mô hình dữ liệu vật lý. Giá trị lớn nhất: dùng làm từ điển chung để đặt tên miền nghiệp vụ nhất quán khi tích hợp nhiều hệ thống.

IBM Banking & Financial Markets Data Warehouse (BDW) — tiền thân là Financial Services Data Model (FSDM) — tổ chức toàn bộ dữ liệu ngân hàng quanh 9 khái niệm dữ liệu cấp cao: Involved Party, Arrangement, Product, Event, Location, Resource Item, Condition, Classification, Business Direction Item. Đây là cách phân loại "mọi thứ trong ngân hàng đều rơi vào 1 trong 9 nhóm này", rất hữu ích để chuẩn hoá lớp logic của warehouse.

Teradata Financial Services Logical Data Model (FSLDM) là một mô hình logic chuẩn hoá (3NF) chia ngân hàng thành các subject area như Party, Account, Agreement, Product, Event, Channel, Location, Campaign, Asset, Financial Management (GL). FSLDM thiên về nền tảng EDW tích hợp ở dạng chuẩn hoá cao, rồi dựng lớp dimensional phía trên.

Định hướng thực dụng: không "cài" nguyên một mô hình tham chiếu. Hãy dùng chúng làm checklist khái niệm (đã phủ hết party-role chưa? arrangement vs account đã tách chưa? đã có subject area cho GL chưa?) và mượn cách đặt tên, rồi tự dựng lõi bằng kỹ thuật của series này.

Mô hình hoá cho báo cáo tuân thủ

Đây là phần "khắc nghiệt" khiến dữ liệu ngân hàng khác mọi ngành: cùng một khoản vay phải hiện lên đồng thời trong nhiều khung tuân thủ khác nhau, mỗi khung có định nghĩa và mốc thời gian riêng.

IFRS 9 — phân loại & tổn thất tín dụng dự kiến (ECL)

IFRS 9 yêu cầu ghi nhận Expected Credit Loss (ECL) theo mô hình ba giai đoạn (staging) dựa trên mức độ tăng rủi ro tín dụng kể từ thời điểm ghi nhận ban đầu:

• Stage 1 — khoản vay còn tốt (performing): trích ECL 12 tháng.
• Stage 2 — rủi ro tín dụng tăng đáng kể (SICR — Significant Increase in Credit Risk) so với ban đầu: chuyển sang ECL toàn vòng đời (lifetime).
• Stage 3 — khoản vay suy giảm giá trị (credit-impaired): lifetime ECL, và lãi được tính trên giá trị ghi sổ ròng (sau dự phòng).

Công thức ECL nền tảng gắn với ba tham số rủi ro: ECL ≈ PD × LGD × EAD (có chiết khấu về hiện giá), trong đó PD = xác suất vỡ nợ, LGD = tổn thất khi vỡ nợ, EAD = dư nợ tại thời điểm vỡ nợ. Ngoài đo lường tổn thất, IFRS 9 còn yêu cầu phân loại công cụ tài chính (amortised cost / FVOCI / FVTPL) dựa trên mô hình kinh doanh và bài kiểm tra dòng tiền SPPI.

Hệ quả cho mô hình dữ liệu: bạn cần lưu stage tại từng kỳ báo cáo (đây chính là một trường SCD/snapshot theo thời gian), cùng các đầu vào PD/LGD/EAD và lịch sử chuyển stage. Việc theo dõi "khoản vay này Stage 1 hôm qua, Stage 2 hôm nay vì lý do gì" là bài toán temporal kinh điển đã bàn ở SCD nâng cao.

Phân loại nợ theo Thông tư 11/2021/TT-NHNN

Song song với IFRS 9 (chuẩn kế toán quốc tế), NHNN yêu cầu phân loại nợ và trích lập dự phòng rủi ro theo Thông tư 11/2021/TT-NHNN (thay Thông tư 02/2013). Nợ chia 5 nhóm, chủ yếu theo số ngày quá hạn (và đánh giá định tính khả năng trả nợ):

Ngoài dự phòng cụ thể (specific) theo bảng trên, ngân hàng trích dự phòng chung (general) bằng 0,75% tổng dư nợ từ nhóm 1 đến nhóm 4. Nhóm 3–4–5 gộp thành nợ xấu (NPL). Một quy tắc quan trọng: nhóm nợ của một khách hàng phải lấy theo nhóm cao nhất mà khách đó bị phân loại tại bất kỳ TCTD nào (đối chiếu qua CIC) — nên mô hình phải lưu được cả nhóm nội bộ lẫn nhóm điều chỉnh theo CIC.

Ở tầng dữ liệu, phân loại nợ là một snapshot ngày của trạng thái khoản vay: mỗi ngày EOD tính lại số ngày quá hạn → nhóm nợ → dự phòng. Đây là fact snapshot định kỳ, không phải bảng cập nhật tại chỗ.

-- (minh hoạ) Phân loại nợ EOD theo số ngày quá hạn — TT 11/2021
-- Chạy trong batch cuối ngày (xem thêm /article/dep-08-data-analytics)
WITH qua_han AS (
    SELECT
        arr_id,
        party_id,
        du_no_goc + du_no_lai            AS du_no,
        GREATEST(0, ngay_bao_cao - ngay_den_han_gan_nhat) AS so_ngay_qua_han
    FROM fact_khoan_vay_snapshot
    WHERE ngay_bao_cao = DATE '2026-06-30'
)
SELECT
    arr_id,
    party_id,
    du_no,
    so_ngay_qua_han,
    CASE
        WHEN so_ngay_qua_han <  10 THEN 1
        WHEN so_ngay_qua_han <= 90 THEN 2
        WHEN so_ngay_qua_han <= 180 THEN 3
        WHEN so_ngay_qua_han <= 360 THEN 4
        ELSE 5
    END AS nhom_no,
    du_no * CASE
        WHEN so_ngay_qua_han <  10 THEN 0.00
        WHEN so_ngay_qua_han <= 90 THEN 0.05
        WHEN so_ngay_qua_han <= 180 THEN 0.20
        WHEN so_ngay_qua_han <= 360 THEN 0.50
        ELSE 1.00
    END AS du_phong_cu_the   -- chưa trừ giá trị TSBĐ khấu trừ (minh hoạ)
FROM qua_han;

Lưu ý nghiệp vụ: dự phòng cụ thể thực tế tính trên (dư nợ − giá trị khấu trừ của tài sản bảo đảm); ví dụ trên lược bỏ phần TSBĐ để tập trung vào cấu trúc phân nhóm.

Báo cáo NHNN & các khung khác

Cùng bộ dữ liệu lõi còn phải phục vụ: báo cáo thống kê định kỳ cho NHNN (bảng cân đối, cơ cấu tín dụng theo ngành/kỳ hạn/loại tiền), tỷ lệ an toàn vốn (CAR) theo chuẩn Basel (Thông tư 41/2016/TT-NHNN), tỷ lệ LDR, dự trữ bắt buộc, và báo cáo phòng chống rửa tiền (AML). Bài học mô hình hoá: đừng dựng mỗi báo cáo một pipeline riêng. Hãy nuôi tất cả từ một lớp fact/snapshot chuẩn hoá chung rồi tổng hợp theo từng khung — nếu không, con số giữa các báo cáo sẽ lệch nhau và không ai đối chiếu nổi. Đây chính là lý lẽ cho một semantic/metrics layer tập trung.

Dimensional cho phân tích ngân hàng

Song song với lớp lõi/tuân thủ (thiên chuẩn hoá), lớp phân tích dùng mô hình chiều Kimball để phục vụ BI, MIS và mô hình rủi ro. Ba loại fact xương sống:

• Fact giao dịch (transaction grain) — mỗi bút toán/giao dịch là một dòng. Grain mịn nhất, phục vụ phân tích hành vi, kênh, phát hiện gian lận. Là fact bất biến, append-only.
• Fact snapshot số dư ngày (periodic snapshot) — mỗi tài khoản × mỗi ngày một dòng số dư cuối ngày. Không thể suy ra rẻ từ fact giao dịch (phải cộng dồn từ đầu), nên phải vật chất hoá. Đây là nền của mọi báo cáo số dư bình quân, CASA, huy động/dư nợ theo thời gian.
• Fact accumulating snapshot — cho vòng đời một khoản vay (nộp hồ sơ → phê duyệt → giải ngân → tất toán), mỗi cột là một mốc thời gian, dòng được cập nhật khi khoản vay tiến qua các bước.

Các conformed dimension dùng chung cho mọi fact: dim_khach_hang, dim_san_pham, dim_tai_khoan, dim_kenh, dim_ngay, dim_chi_nhanh. "Conformed" nghĩa là cùng một khoá và cùng nghĩa ở khắp các data mart (xem dimensional nâng cao) — nhờ đó bộ phận Huy động (dep), Nguồn vốn/Treasury (tres) và Tín dụng (credit) đều gọi "khách hàng" theo đúng một định nghĩa, dùng chung customer_key.

-- (minh hoạ) Snapshot số dư ngày: nền của CASA, số dư bình quân...
CREATE TABLE fact_so_du_ngay (
    ngay_key      INT     NOT NULL REFERENCES dim_ngay(ngay_key),
    account_key   BIGINT  NOT NULL REFERENCES dim_tai_khoan(account_key),
    customer_key  BIGINT  NOT NULL REFERENCES dim_khach_hang(customer_key), -- conformed
    product_key   BIGINT  NOT NULL REFERENCES dim_san_pham(product_key),
    so_du_cuoi_ngay   NUMERIC(18,2),
    so_du_binh_quan   NUMERIC(18,2),
    loai_so_du        VARCHAR(10),   -- CASA | TERM | LOAN
    PRIMARY KEY (ngay_key, account_key)
);

-- Tỷ lệ CASA = (số dư không kỳ hạn) / (tổng huy động) tại một ngày
SELECT
    d.thang,
    SUM(f.so_du_cuoi_ngay) FILTER (WHERE f.loai_so_du = 'CASA')
      / NULLIF(SUM(f.so_du_cuoi_ngay) FILTER (WHERE f.loai_so_du IN ('CASA','TERM')), 0)
      AS ty_le_casa
FROM fact_so_du_ngay f
JOIN dim_ngay d ON d.ngay_key = f.ngay_key
WHERE d.la_cuoi_thang
GROUP BY d.thang
ORDER BY d.thang;

Vận dụng các kỹ thuật của series

Đây là mấu chốt của "bài tổng kết": không kỹ thuật đơn lẻ nào đủ cho ngân hàng — chúng phối hợp theo tầng.

SCD2 cho khách hàng

Thuộc tính khách hàng (phân khúc, xếp hạng tín dụng nội bộ, địa chỉ, tình trạng KYC) thay đổi theo thời gian, và báo cáo lịch sử phải thấy đúng giá trị tại thời điểm quá khứ. Ví dụ: khi tính ECL/nhóm nợ cho kỳ 30/06, phải lấy xếp hạng khách tại 30/06, không phải giá trị hôm nay. Đó là lý do dim_khach_hang phải là SCD Type 2 (mỗi thay đổi mở một version với hieu_luc_tu/hieu_luc_den), thậm chí bi-temporal khi cần tách "thời điểm sự việc xảy ra" khỏi "thời điểm ngân hàng biết". Chi tiết ở SCD nâng cao.

Data Vault để tích hợp nhiều core

Ngân hàng thường có nhiều core cùng lúc (core cũ + core mới sau chuyển đổi, core thẻ riêng, hệ thống sau M&A). Mỗi nguồn định danh khách theo cách riêng, đổi schema theo lịch riêng. Data Vault là lớp tích hợp lý tưởng: hub giữ khoá nghiệp vụ bất biến (CIF, số tài khoản), link giữ quan hệ n–n, satellite giữ thuộc tính + lịch sử theo từng nguồn — thêm một core mới chỉ là thêm satellite/link, không đập vỡ lõi.

Điểm tinh tế: quy tắc nghiệp vụ tuân thủ (phân nhóm nợ, gán IFRS 9 stage, tính ECL) đặt ở business vault — một chỗ duy nhất, có kiểm soát version — rồi mới đẩy xuống star/semantic. Nhờ đó mọi báo cáo dùng cùng một định nghĩa nhóm nợ, tránh cảnh mỗi phòng ban tự tính một kiểu.

Semantic layer cho metric ngân hàng

Cuối cùng, các metric cấp lãnh đạo — NIM (biên lãi ròng), CASA ratio, NPL ratio, LDR, CAR, cost of risk — phải được định nghĩa một lần trong semantic/metrics layer, có mô tả, có owner, có công thức chuẩn. Khi Tổng giám đốc, khối Treasury và khối Tín dụng cùng hỏi "tỷ lệ nợ xấu tháng này", tất cả nhận đúng một con số. Đây cũng là điểm giao với quản trị & chất lượng dữ liệu: metric quan trọng thì phải được kiểm thử, giám sát freshness và gắn trách nhiệm.

Use case thực tế

Bối cảnh (minh hoạ): NCB triển khai một báo cáo nợ xấu và dự phòng hợp nhất dùng chung cho ba khối — Huy động (dep), Treasury (tres) và Tín dụng (credit) — thay cho ba bản tính Excel lệch nhau trước đây.

Kiến trúc dữ liệu:

1. Raw vault hợp nhất khách hàng từ core cũ, core mới và hệ thống thẻ: 1 hub CIF (hash key theo số CIF), các satellite theo nguồn nạp append-only mỗi đêm.
2. Business vault chạy quy tắc Thông tư 11/2021 (phân 5 nhóm theo ngày quá hạn) và gán IFRS 9 stage + ước lượng ECL = PD×LGD×EAD cho từng khoản vay, tại mỗi kỳ EOD.
3. Star schema: fact_khoan_vay_snapshot (grain: khoản vay × ngày) join dim_khach_hang SCD2 (lấy đúng xếp hạng tại kỳ báo cáo), dim_san_pham, dim_ngay.
4. Semantic layer định nghĩa ty_le_npl, du_phong_cu_the, du_phong_chung, coverage_ratio.

Kết quả minh hoạ: với danh mục 12.000 tỷ đồng dư nợ, giả sử 3,1% rơi nhóm 3–5. Dự phòng cụ thể (sau khấu trừ TSBĐ) và dự phòng chung 0,75% trên nhóm 1–4 được tính cùng một chỗ ở business vault, nên con số NPL trên báo cáo NHNN, báo cáo IFRS 9 và dashboard nội bộ khớp tuyệt đối. Khi kiểm toán hỏi "vì sao khoản vay X nhảy từ Stage 1 lên Stage 2 ngày 12/06", lineage của Data Vault + SCD2 trả lời được ngay: nguồn nào, giá trị nào, thời điểm nào.

Ghi nhớ

• Ngân hàng, về dữ liệu, xoay quanh sáu danh từ lõi: party/customer, account, arrangement, transaction, product, GL — tách arrangement khỏi account và tách party khỏi role là hai quyết định nền tảng.
• BIAN là kiến trúc dịch vụ/năng lực (từ điển nghiệp vụ, ~300+ Service Domain), IBM FSDM phân loại quanh 9 khái niệm, Teradata FSLDM là EDW 3NF theo subject area — dùng làm checklist khái niệm, đừng cài nguyên khối.
• IFRS 9: ba stage theo mức tăng rủi ro, ECL ≈ PD×LGD×EAD (có chiết khấu); phải lưu stage theo từng kỳ báo cáo.
• Thông tư 11/2021: 5 nhóm nợ theo ngày quá hạn, dự phòng cụ thể 0/5/20/50/100%, dự phòng chung 0,75% nhóm 1–4; nhóm nợ lấy theo nhóm cao nhất qua CIC.
• Phân tích ngân hàng cần ba loại fact: giao dịch (mịn, bất biến), snapshot số dư ngày (phải vật chất hoá), accumulating snapshot (vòng đời khoản vay) — trên nền conformed dimension.
• Ghép kỹ thuật: SCD2 cho khách hàng, Data Vault để tích hợp nhiều core, business vault giữ quy tắc tuân thủ một chỗ, semantic layer chuẩn hoá NIM/CASA/NPL/CAR.
• Nuôi mọi báo cáo (NHNN, IFRS 9, nội bộ) từ một lớp fact/snapshot chung để các con số luôn đối chiếu khớp nhau.

Nguồn tham khảo

• Ralph Kimball & Margy Ross — The Data Warehouse Toolkit (3rd Edition, Kimball Group / Wiley) — mô hình chiều, snapshot fact, conformed dimension.
• Daniel Linstedt & Michael Olschimke — Building a Scalable Data Warehouse with Data Vault 2.0 (Morgan Kaufmann) — hub/link/satellite, raw vs business vault, PIT/bridge.
• BIAN — Banking Industry Architecture Network — Service Landscape & Service Domain, kiến trúc tham chiếu hướng dịch vụ cho ngân hàng.
• IFRS 9 Financial Instruments — IFRS Foundation — phân loại công cụ tài chính, mô hình tổn thất tín dụng dự kiến (ECL) ba giai đoạn.
• Thông tư 11/2021/TT-NHNN — Ngân hàng Nhà nước Việt Nam — quy định phân loại tài sản có và trích lập dự phòng rủi ro (5 nhóm nợ, tỷ lệ dự phòng).
• Thông tư 41/2016/TT-NHNN — quy định tỷ lệ an toàn vốn (CAR) theo chuẩn Basel II đối với ngân hàng.
• IBM — Banking and Financial Markets Data Warehouse (BDW) / Financial Services Data Model — mô hình dữ liệu ngành với 9 khái niệm dữ liệu cấp cao.
• Teradata — Financial Services Logical Data Model (FSLDM) — mô hình dữ liệu logic 3NF theo subject area cho ngân hàng.