Huy động vốn 8 — Dữ liệu & Phân tích huy động

Đây là bài khép lại series Nghiệp vụ Tiền gửi & Huy động vốn chuyên sâu, nhìn toàn bộ hoạt động huy động qua con mắt của Data Analyst / Data Engineer. Sau khi đã hiểu bản chất tiền gửi không kỳ hạn (CASA), tiền gửi có kỳ hạn & tiết kiệm (dep-03), cơ chế lãi suất & cách tính lãi (dep-04), giấy tờ có giá (dep-05), FTP & quản lý thanh khoản (dep-06) và sản phẩm số & cá nhân hoá (dep-07), giờ ta trả lời câu hỏi thực chiến: dữ liệu tiền gửi nằm ở đâu, mô hình hóa thế nào, đo cái gì, dự báo ra sao, và báo cáo cho ai.

Mô hình tinh thần của bài: nguồn dữ liệu core banking → batch EOD → kho dữ liệu (fact/dim) → chỉ số → báo cáo & dự báo. Nguồn vốn huy động là "nguyên liệu đầu vào" rẻ nhất của ngân hàng, nên đo lường và dự báo chính xác dòng tiền gửi là bài toán vừa mang tính kinh doanh (chi phí vốn) vừa mang tính an toàn (thanh khoản, LCR).

Dữ liệu tiền gửi đến từ đâu?

Khác với thẻ hay thanh toán vốn giàu sự kiện realtime, dữ liệu huy động có đặc thù riêng: số dư là trạng thái, không phải sự kiện. Ta phải phân biệt rõ hai loại dữ liệu:

• Dữ liệu giao dịch (event): mỗi lần nộp/rút/chuyển khoản/ghi lãi là một dòng trong sổ giao dịch. Cộng dồn các giao dịch ra số dư.
• Dữ liệu số dư (snapshot): ảnh chụp số dư cuối ngày (EOD — end of day) của từng tài khoản. Đây là "trái tim" của phân tích huy động vì hầu hết chỉ số (số dư bình quân, CASA, chi phí vốn) đều tính trên số dư cuối ngày, không phải trên luồng giao dịch.

Các nguồn cốt lõi trong core banking mà Data team phải hợp nhất:

Điểm mấu chốt cho Analyst: một tài khoản CKH có thể gồm nhiều sổ/khế ước (mỗi lần gửi mở một sổ với kỳ hạn và lãi suất riêng), nên grain của dữ liệu tiết kiệm là sổ, còn grain của số dư huy động là (tài khoản, ngày).

Mô hình dữ liệu tiền gửi trong kho

Ta mô hình theo lược đồ sao, nhưng điểm khác biệt so với thẻ là có hai bảng fact: một fact snapshot số dư (grain = tài khoản × ngày, dùng cho hầu hết chỉ số) và một fact giao dịch (grain = 1 giao dịch, dùng cho dòng tiền inflow/outflow).

Vài nguyên tắc thiết kế:

• Grain của FACT_DEPOSIT_BALANCE = (account × ngày): đây là periodic snapshot fact kinh điển. Mỗi ngày batch EOD nạp một dòng cho mỗi tài khoản còn hiệu lực. Đây là bảng lớn nhất nhưng cho phép tính mọi chỉ số số dư theo thời gian.
• deposit_type phân biệt KKH (không kỳ hạn — CASA), CKH (có kỳ hạn) và TK (tiết kiệm). Đây là chiều lọc quan trọng nhất của phân tích huy động.
• accrued_interest (lãi dự chi) tính bởi batch EOD, liên quan chặt tới kế toán — xem Kế toán 4 — Lãi dự thu/dự chi.
• DIM_INTEREST_RATE là bảng biến động theo thời gian (SCD): mỗi lần NHNN/ngân hàng đổi biểu lãi suất tạo một dòng effective_date mới.

Từ dữ liệu tới chỉ số & báo cáo

Luồng tổng thể từ nguồn tới đầu ra:

Vai trò của Data Engineering hiện rõ ở khâu batch EOD: sau giờ cut-off, hệ thống chạy job cuối ngày để (1) chốt số dư từng tài khoản, (2) tính lãi dự chi cộng dồn, (3) đáo hạn/tự động tái tục sổ CKH, (4) đẩy snapshot vào kho. Đây là job batch trọng yếu, phải chạy đúng thứ tự phụ thuộc và đúng hạn trước khi mở cửa ngày hôm sau. Cách dựng và điều phối các job này xem Data Engineering — Pipelines & Airflow và series Airflow.

Bộ chỉ số huy động cốt lõi

Lưu ý về bình quân: "số dư bình quân" trong nghiệp vụ huy động luôn là bình quân số dư cuối ngày trong kỳ (average daily balance), không phải trung bình cộng của số đầu kỳ và cuối kỳ. Đây là lý do fact snapshot theo ngày là bắt buộc.

Dự báo dòng tiền & phân tích ổn định số dư

Hai bài toán phân tích giá trị nhất của huy động:

1) Dự báo dòng tiền tiền gửi (inflow/outflow). Từ FACT_DEPOSIT_TXN, ta tách dòng tiền vào (nộp, tiền lương về, tiền gửi mới) và dòng tiền ra (rút, tất toán, chuyển đi). Với tiền gửi CKH, lịch đáo hạn đã biết trước (từ maturity_date) nên outflow theo hợp đồng gần như xác định; phần bất định là tỷ lệ tái tục. Với CASA, dòng tiền mang tính hành vi và mùa vụ (Tết, kỳ lương, cuối quý) — phải mô hình bằng chuỗi thời gian.

2) Phân tích ổn định số dư — core vs volatile deposits. Đây là đầu vào trực tiếp cho LCR (Liquidity Coverage Ratio) theo Basel III / Thông tư 41/2016/TT-NHNN. Ý tưởng: nhìn chuỗi số dư cuối ngày của mỗi tài khoản/nhóm, phần luôn hiện diện qua thời gian là core deposit (ổn định, run-off rate thấp), phần dao động là volatile deposit (dễ rút, run-off rate cao). Kỹ thuật thường dùng:

• Lấy mức tối thiểu (hoặc phân vị thấp, ví dụ P5) của số dư theo ngày trong 12 tháng → xấp xỉ phần core.
• Đo độ lệch chuẩn số dư theo ngày → phần volatile.
• Phân tầng theo loại khách (bán lẻ ổn định hơn tổ chức), theo deposit_type, theo mức bảo hiểm tiền gửi (khoản dưới hạn mức chi trả — hiện 125 triệu VND theo quy định bảo hiểm tiền gửi — được xem là "dính" hơn).

Thực hành SQL trên sandbox

Sandbox không có bảng tiền gửi chuyên biệt, nên ta mô phỏng bằng schema có sẵn:

• customers(id, full_name, city, created_at)
• accounts(id, customer_id, account_no, balance, currency) — khóa chính là id
• transactions(id, account_id, amount, kind ['credit'|'debit'], created_at)

Quy ước mô phỏng: coi mỗi accounts là một tài khoản tiền gửi, balance là số dư hiện tại; một tài khoản giao dịch nhiều (nhiều dòng transactions) được xem như CASA (không kỳ hạn, hay biến động), còn tài khoản ít giao dịch xem như tiền gửi có kỳ hạn (gửi rồi để yên). Đây chỉ là mô phỏng để luyện tư duy; schema huy động thật có deposit_type, maturity_date, snapshot số dư theo ngày như mô hình phía trên.

Số dư bình quân theo loại tiền tệ

Nền tảng của "số dư huy động bình quân" — lưu ý ép ::numeric để ROUND hai tham số chạy được trên Postgres.

-- ▶ Chạy được trong SQL Builder
SELECT
  currency,
  COUNT(*)                        AS so_tai_khoan,
  ROUND(AVG(balance)::numeric, 2) AS so_du_binh_quan,
  SUM(balance)                    AS tong_so_du
FROM accounts
GROUP BY currency
ORDER BY tong_so_du DESC;

Tỷ lệ CASA (mô phỏng theo mức độ hoạt động)

Phân loại tài khoản: từ 5 giao dịch trở lên coi là CASA (không kỳ hạn), dưới ngưỡng coi là có kỳ hạn; rồi tính tỷ lệ CASA = số dư CASA / tổng số dư.

-- ▶ Chạy được trong SQL Builder
WITH acct_activity AS (
  SELECT
    a.id,
    a.balance,
    COUNT(t.id) AS so_giao_dich
  FROM accounts a
  LEFT JOIN transactions t ON t.account_id = a.id
  GROUP BY a.id, a.balance
),
phan_loai AS (
  SELECT
    balance,
    CASE WHEN so_giao_dich >= 5 THEN 'CASA' ELSE 'CO_KY_HAN' END AS loai_tien_gui
  FROM acct_activity
)
SELECT
  SUM(CASE WHEN loai_tien_gui = 'CASA' THEN balance ELSE 0 END) AS so_du_casa,
  SUM(balance)                                                  AS tong_huy_dong,
  ROUND(
    (100.0 * SUM(CASE WHEN loai_tien_gui = 'CASA' THEN balance ELSE 0 END)
     / NULLIF(SUM(balance), 0))::numeric,
    2
  )                                                             AS ty_le_casa_pct
FROM phan_loai;

Cơ cấu số dư theo dải giá trị (mô phỏng cơ cấu kỳ hạn)

Phân tầng số dư huy động theo nhóm — cùng tư duy với phân bổ theo dải kỳ hạn.

-- ▶ Chạy được trong SQL Builder
SELECT
  CASE
    WHEN balance >= 100000 THEN 'Lon (>=100k)'
    WHEN balance >= 20000  THEN 'Trung binh'
    ELSE 'Nho (<20k)'
  END                              AS nhom_so_du,
  COUNT(*)                         AS so_tai_khoan,
  SUM(balance)                     AS tong_so_du,
  ROUND(AVG(balance)::numeric, 2)  AS so_du_tb
FROM accounts
GROUP BY 1
ORDER BY tong_so_du DESC;

Dòng tiền ròng (inflow − outflow) theo tháng

Mô phỏng dự báo dòng tiền: credit là tiền vào (inflow), debit là tiền ra (outflow), số ròng theo tháng.

-- ▶ Chạy được trong SQL Builder
SELECT
  date_trunc('month', created_at)                              AS thang,
  SUM(CASE WHEN kind = 'credit' THEN amount ELSE 0 END)        AS inflow,
  SUM(CASE WHEN kind = 'debit'  THEN amount ELSE 0 END)        AS outflow,
  SUM(CASE WHEN kind = 'credit' THEN amount ELSE -amount END)  AS dong_tien_rong
FROM transactions
GROUP BY date_trunc('month', created_at)
ORDER BY thang;

Tập trung tiền gửi — top khách theo số dư

Rủi ro thanh khoản khi khách lớn rút: đo mức độ tập trung nguồn vốn.

-- ▶ Chạy được trong SQL Builder
SELECT
  c.id,
  c.full_name,
  c.city,
  ROUND(SUM(a.balance)::numeric, 2) AS tong_so_du,
  COUNT(a.id)                       AS so_tai_khoan
FROM customers c
JOIN accounts a ON a.customer_id = c.id
GROUP BY c.id, c.full_name, c.city
ORDER BY tong_so_du DESC
LIMIT 10;

Ước lượng phần số dư "core" (ổn định)

Mô phỏng ý tưởng core deposit bằng cách so số dư hiện tại với tổng tiền ra của tài khoản — tài khoản giữ được số dư cao dù có rút được coi là ổn định hơn.

-- ▶ Chạy được trong SQL Builder
WITH out_flow AS (
  SELECT
    account_id,
    SUM(CASE WHEN kind = 'debit' THEN amount ELSE 0 END) AS tong_rut
  FROM transactions
  GROUP BY account_id
)
SELECT
  a.id,
  a.account_no,
  a.balance,
  COALESCE(o.tong_rut, 0)                                  AS tong_rut,
  CASE
    WHEN a.balance >= COALESCE(o.tong_rut, 0) THEN 'Core (on dinh)'
    ELSE 'Volatile (bien dong)'
  END                                                      AS phan_loai_on_dinh
FROM accounts a
LEFT JOIN out_flow o ON o.account_id = a.id
ORDER BY a.balance DESC;

Báo cáo huy động cho NHNN & quản trị

Đầu ra của phân tích huy động phục vụ hai nhóm người đọc rất khác nhau:

Báo cáo tuân thủ cho NHNN (định kỳ, khuôn mẫu cố định, phải khớp kế toán):

• Số dư huy động theo loại tiền gửi & kỳ hạn — phục vụ thống kê tiền tệ.
• Dự trữ bắt buộc — tính trên số dư huy động bình quân theo quy định NHNN.
• Tỷ lệ an toàn thanh khoản (LCR) theo Thông tư 41/2016/TT-NHNN, dùng phân tầng core/volatile ở trên; tỷ lệ nguồn vốn ngắn hạn cho vay trung–dài hạn và các tỷ lệ theo Thông tư 22/2019/TT-NHNN.
• Bảo hiểm tiền gửi — số dư thuộc diện được bảo hiểm và phí phải nộp cho tổ chức bảo hiểm tiền gửi.

Báo cáo quản trị cho HĐQT/ALCO (linh hoạt, thiên xu hướng & quyết định):

• Trang tổng quan một màn hình: tổng huy động, tỷ lệ CASA, chi phí vốn, tăng trưởng MoM/YoY, so với kế hoạch.
• Cơ cấu kỳ hạn & lịch đáo hạn CKH 3–6–12 tháng tới (gap thanh khoản).
• Cảnh báo ngoại lệ: CASA giảm dưới ngưỡng, tập trung top khách vượt hạn mức, chi phí vốn tăng.

Nguyên tắc: báo cáo NHNN cần đúng khớp kế toán tuyệt đối (đối chiếu với sổ cái — xem Kế toán 4), còn báo cáo quản trị cần xu hướng + ngoại lệ + drill-down. Cùng một kho fact snapshot phục vụ được cả hai vì đã chốt số cuối ngày nhất quán.

Bức tranh thanh khoản tổng thể (LCR/NSFR, ALM) được đặt trong bối cảnh rộng hơn ở Treasury & ALM và dep-06 — FTP & Quản lý thanh khoản.

Use case thực tế

Bối cảnh (minh hoạ): ALCO của NCB nhận thấy chi phí vốn quý này tăng trong khi mặt bằng lãi suất thị trường đi ngang. Ban lãnh đạo yêu cầu Data team truy nguyên trong 48 giờ và đề xuất hành động.

Cách Data team xử lý:

1. Chốt số trên fact snapshot EOD: tính chi phí vốn = chi phí lãi / số dư huy động bình quân ngày, tránh dùng số cuối kỳ vốn dễ méo do một khoản lớn về cuối tháng.
2. Bóc theo deposit_type: phát hiện tỷ lệ CASA giảm từ ~22% xuống ~18% — vốn giá rẻ co lại, tỷ trọng dịch sang CKH lãi cao, kéo chi phí vốn bình quân lên dù từng mức lãi suất không đổi. Đúng logic "CASA cao → chi phí vốn thấp" trong bảng chỉ số.
3. Drill-down theo phân khúc & kỳ hạn: phần CASA sụt tập trung ở nhóm khách doanh nghiệp chuyển số dư sang CKH 6 tháng của đối thủ chào lãi suất tốt hơn.
4. Phân tích ổn định số dư: mô hình core/volatile cho thấy phần vốn dịch chuyển thuộc nhóm volatile (khách lớn, nhạy lãi suất), nên rủi ro không chỉ là chi phí mà cả thanh khoản nếu tiếp diễn.

Kết quả (ước lượng): đề xuất chương trình giữ CASA cho nhóm doanh nghiệp (gói dịch vụ thanh toán + ưu đãi phí) thay vì chạy đua lãi suất CKH; mô phỏng cho thấy đưa CASA về ~21% giúp chặn phần lớn mức tăng chi phí vốn. Bài học: chi phí vốn tăng không phải lúc nào cũng do lãi suất — cơ cấu nguồn (CASA vs CKH) mới là biến số Data team phải soi đầu tiên.

Ghi nhớ

• Dữ liệu huy động có hai loại: giao dịch (event) và số dư (snapshot EOD); hầu hết chỉ số tính trên số dư cuối ngày, nên fact snapshot theo (tài khoản × ngày) là bắt buộc.
• Mô hình kho gồm hai fact: FACT_DEPOSIT_BALANCE (snapshot số dư) và FACT_DEPOSIT_TXN (dòng tiền); grain của tiết kiệm là sổ/khế ước, không phải tài khoản.
• Batch EOD (Data Engineering) chốt số dư, tính lãi dự chi, đáo hạn/tái tục CKH và đẩy snapshot — job trọng yếu phải xong trước ngày làm việc kế tiếp.
• Bộ chỉ số cốt lõi: tỷ lệ CASA, số dư bình quân (ngày), chi phí vốn, cơ cấu kỳ hạn, tỷ lệ tái tục, tập trung tiền gửi.
• Số dư bình quân là bình quân số dư cuối ngày (average daily balance), không phải trung bình đầu–cuối kỳ.
• Phân tích core vs volatile deposit (mức tối thiểu/P5 vs độ lệch chuẩn số dư) là đầu vào trực tiếp cho LCR theo Thông tư 41/2016/TT-NHNN.
• Báo cáo NHNN cần khớp kế toán tuyệt đối; báo cáo quản trị/ALCO cần xu hướng + ngoại lệ + drill-down — cùng dùng một kho fact snapshot.
• Trên Postgres, ROUND(AVG(...)::numeric, 2) phải ép ::numeric vì double precision không có ROUND hai tham số.

Nguồn tham khảo

• Luật các Tổ chức tín dụng 2024 (Luật số 32/2024/QH15) — khung pháp lý hoạt động nhận tiền gửi của TCTD.
• Ngân hàng Nhà nước Việt Nam — sbv.gov.vn — quy định về tiền gửi, dự trữ bắt buộc và chế độ báo cáo thống kê.
• Thông tư 41/2016/TT-NHNN (tỷ lệ an toàn vốn, Basel II) và Thông tư 22/2019/TT-NHNN (các giới hạn, tỷ lệ bảo đảm an toàn) — bối cảnh LCR và tỷ lệ thanh khoản.
• Basel Committee on Banking Supervision (BIS) — bis.org — Basel III LCR/NSFR và khái niệm run-off rate cho tiền gửi ổn định/kém ổn định.
• Quy định bảo hiểm tiền gửi (Luật Bảo hiểm tiền gửi; hạn mức chi trả hiện hành 125 triệu VND).
• The Data Warehouse Toolkit (Ralph Kimball & Margy Ross) — periodic snapshot fact và dimensional modeling.
• PostgreSQL Documentation — Aggregate & Date/Time Functions — nền tảng cho SQL tổng hợp số dư và dòng tiền.