Nhân quả 8 — Ứng dụng & thực hành ngân hàng

Ghép mọi thứ lại: causal inference trong ngân hàng

Bảy bài trước dạy từng công cụ: potential outcomes & confounder, RCT, DAG, matching/propensity, DiD, IV & RDD, uplift. Bài cuối là bài thực hành tổng kết: đặt tất cả vào bối cảnh một ngân hàng thật (NCB) và trả lời hai câu hỏi vận hành — "khi nào tôi bắt buộc phải suy luận nhân quả, và với tình huống trước mặt thì chọn phương pháp nào?"

Điểm mấu chốt xuyên suốt: quyết định của ngân hàng phần lớn là câu hỏi nhân quả ("đổi phí này làm khách giao dịch nhiều hơn bao nhiêu?"), nhưng phần lớn lại không thể A/B test được. Đó là lý do bộ công cụ quan sát (matching, DiD, IV, RDD) không phải "học cho biết" mà là kỹ năng bắt buộc của một team dữ liệu ngân hàng nghiêm túc.

Vì sao ngân hàng đặc biệt cần causal (và không A/B được)

Trong sản phẩm số thuần (app tin tức, e-commerce), A/B test là mặc định: chia traffic 50/50, đổi nút, đo click. Ngân hàng khác về bản chất — rất nhiều can thiệp không thể ngẫu nhiên hoá:

Trong các tình huống này, ngân hàng vẫn buộc phải biết tác động THẬT — để (1) ra quyết định tiếp theo (nhân rộng hay dừng?), (2) tính ROI đúng (chương trình 8 tỷ/năm có đáng?), và (3) giải trình trước ban lãnh đạo, kiểm toán, cơ quan quản lý. Một con số "tăng 24 giao dịch/khách" lấy từ so sánh ngây thơ giữa nhóm tham gia và không tham gia sẽ không sống sót qua một buổi chất vấn của kiểm toán nội bộ — vì nó không tách được phần do chương trình gây ra khỏi phần self-selection (khách tự đăng ký vốn đã tích cực).

Thêm nữa, ngân hàng có dữ liệu dọc (panel) rất giàu: mỗi khách có lịch sử giao dịch nhiều năm, nhiều cột/ngưỡng chính sách (cutoff điểm tín dụng, hạn mức), nhiều thay đổi theo vùng/thời điểm. Đây chính là "nguyên liệu" lý tưởng cho DiD, RDD, IV. Không tận dụng thì lãng phí.

Khung chọn phương pháp — cây quyết định tổng hợp cả series

Đây là bản đồ gộp toàn bộ 8 bài thành một quy trình chọn phương pháp. Khi đứng trước một câu hỏi tác động, đi từ trên xuống:

Đọc cây theo thứ tự ưu tiên: ngẫu nhiên hoá được thì luôn ưu tiên RCT (bài 2) — mọi phương pháp quan sát chỉ là "phương án B" khi không thể thí nghiệm. Khi rơi vào nhánh quan sát, thứ tự các câu hỏi phản ánh độ mạnh của thiết kế: RDD và IV khai thác cơ chế "gần như ngẫu nhiên" (quasi-experiment) nên đáng tin hơn matching thuần — vốn dựa hoàn toàn vào giả định "đã đo hết confounder" (unconfoundedness), một giả định không kiểm chứng được. Uplift đứng riêng: nó không phải để đo tác động trung bình mà để nhắm can thiệp cá nhân, và cần dữ liệu từ một RCT/DiD trước đó làm nền.

Use case ngân hàng theo phương pháp

Ánh xạ trực tiếp từng bài toán NCB thường gặp vào phương pháp:

Quy tắc chọn nhanh: có cutoff → nghĩ ngay RDD; có mốc thời gian rõ + nhóm không ảnh hưởng → DiD; chỉ có ảnh chụp một thời điểm → matching (và phải rất khiêm tốn về kết luận); cần chọn khách để nhắm → uplift.

SQL minh hoạ: DiD 2×2 trên dữ liệu giao dịch

Dưới đây là ước lượng DiD (difference-in-differences) dạng 2×2 đơn giản nhất, minh hoạ trên sandbox. Bối cảnh giả định: một can thiệp (ví dụ chương trình miễn phí chuyển khoản) bắt đầu giữa năm 2024; nhóm treated là khách ở TP.HCM (city = 'Ho Chi Minh'), nhóm control là khách ở nơi khác. Ta so mức thay đổi tổng giá trị giao dịch/khách giữa hai giai đoạn (trước vs sau mốc), rồi lấy hiệu của hai hiệu — đó chính là ước lượng DiD.

-- ▶ Chạy được
WITH tx_flag AS (
  SELECT c.id AS customer_id,
         CASE WHEN c.city = 'Ho Chi Minh' THEN 'treated' ELSE 'control' END AS grp,
         CASE WHEN t.created_at < TIMESTAMP '2024-07-01' THEN 'pre' ELSE 'post' END AS period,
         t.amount
  FROM transactions t
  JOIN accounts  a ON t.account_id = a.id
  JOIN customers c ON a.customer_id = c.id
),
cell AS (
  SELECT grp, period,
         COUNT(DISTINCT customer_id)               AS so_khach,
         ROUND(AVG(amount)::numeric, 2)            AS tb_gia_tri_gd
  FROM tx_flag
  GROUP BY grp, period
)
SELECT grp, period, so_khach, tb_gia_tri_gd
FROM cell
ORDER BY grp, period;

Kết quả trả về 4 ô (2 nhóm × 2 giai đoạn). Ước lượng DiD tính bằng tay từ 4 con số này:

DiD = (treated_post − treated_pre) − (control_post − control_pre)

Nếu nhóm control cũng tăng giữa hai giai đoạn (do mùa vụ, lạm phát, xu hướng chung), phần tăng đó bị trừ đi khỏi nhóm treated — đó chính là điều làm DiD mạnh hơn so sánh trước–sau ngây thơ (vốn nhầm xu hướng chung thành tác động). Muốn ra thẳng một con số DiD trong một truy vấn, có thể pivot bằng biểu thức điều kiện:

-- ▶ Chạy được
WITH tx_flag AS (
  SELECT c.id AS customer_id,
         CASE WHEN c.city = 'Ho Chi Minh' THEN 1 ELSE 0 END AS treated,
         CASE WHEN t.created_at >= TIMESTAMP '2024-07-01' THEN 1 ELSE 0 END AS post,
         t.amount
  FROM transactions t
  JOIN accounts  a ON t.account_id = a.id
  JOIN customers c ON a.customer_id = c.id
)
SELECT
  ROUND(AVG(amount) FILTER (WHERE treated=1 AND post=1)::numeric, 2) AS treated_post,
  ROUND(AVG(amount) FILTER (WHERE treated=1 AND post=0)::numeric, 2) AS treated_pre,
  ROUND(AVG(amount) FILTER (WHERE treated=0 AND post=1)::numeric, 2) AS control_post,
  ROUND(AVG(amount) FILTER (WHERE treated=0 AND post=0)::numeric, 2) AS control_pre,
  ROUND((
      AVG(amount) FILTER (WHERE treated=1 AND post=1)
    - AVG(amount) FILTER (WHERE treated=1 AND post=0)
    - AVG(amount) FILTER (WHERE treated=0 AND post=1)
    + AVG(amount) FILTER (WHERE treated=0 AND post=0)
  )::numeric, 2) AS did_uoc_luong
FROM tx_flag;

Cảnh báo diễn giải: đây là minh hoạ cơ chế tính, KHÔNG phải một đánh giá tác động hợp lệ. Việc gán "TP.HCM = treated" chỉ để có nhóm; trong thực tế phải là nhóm thực sự nhận can thiệp. Quan trọng nhất: DiD chỉ đáng tin khi giả định parallel trends đúng — nếu trước can thiệp hai nhóm vốn đã có xu hướng khác nhau thì con số DiD sai. Luôn vẽ đường xu hướng pre-period của hai nhóm để kiểm tra (xem bài 5). SQL trên chỉ tính được một con số điểm, chưa có sai số chuẩn / khoảng tin cậy — muốn đầy đủ phải chạy hồi quy có treated * post trong Python/R.

Quy trình thực hành 6 bước

Một đánh giá tác động trong ngân hàng nên đi theo quy trình chuẩn, không nhảy thẳng vào tính toán:

1. Bắt đầu từ câu hỏi nhân quả rõ ràng. Nêu chính xác T (can thiệp), Y (kết quả đo, kèm cửa sổ thời gian), dân số, và đang ước lượng ATE hay ATT. "Chương trình có hiệu quả không" quá mơ hồ; "miễn phí chuyển khoản có làm tăng số giao dịch/khách trong 90 ngày, trên nhóm đã tham gia (ATT), bao nhiêu?" mới dùng được.
2. Vẽ DAG và nêu giả định minh bạch. DAG (bài 3) giúp quyết định biến nào phải kiểm soát (confounder), biến nào không được (mediator, collider). Viết ra giả định định danh (identification) — để người khác phản biện được.
3. Chọn phương pháp theo cây quyết định ở trên.
4. Kiểm tra giả định trước khi tin kết quả: parallel trends (DiD), overlap/common support và balance sau matching (propensity), liên tục quanh cutoff (RDD), relevance & exclusion (IV).
5. Ước lượng kèm khoảng tin cậy — một con số điểm không có CI thì không dùng để ra quyết định. Nhớ hiệu ứng thật thường nhỏ hơn nhiều con số ngây thơ.
6. Robustness & sensitivity. Đổi cửa sổ thời gian, đổi tập biến kiểm soát, thử placebo test (giả vờ can thiệp ở thời điểm không có gì xảy ra — nếu ra hiệu ứng "dương" thì thiết kế có vấn đề). Sensitivity analysis trả lời "confounder ẩn phải mạnh cỡ nào mới lật ngược kết luận?".

Cạm bẫy thường gặp

• Confounder ẩn (unobserved confounding). Kẻ thù số một của mọi phương pháp quan sát. Matching/propensity chỉ khử được confounder đã đo; luôn hỏi "biến nào tôi không có trong dữ liệu vừa ảnh hưởng ai nhận can thiệp vừa ảnh hưởng kết quả?" (ví dụ: động lực tài chính, hoàn cảnh cá nhân của khách).
• Nhầm dự báo với nhân quả. Một mô hình ML dự báo churn chính xác 90% không trả lời "gọi thì bao nhiêu người ở lại". Predict ≠ intervene — dùng uplift (bài 7) cho câu hỏi nhắm can thiệp. Model AUC cao không có nghĩa hệ số của nó là tác động nhân quả.
• Đưa hết biến vào hồi quy "cho chắc". Kiểm soát mediator làm mất chính hiệu ứng muốn đo; kiểm soát collider tạo ra thiên lệch. Chọn biến kiểm soát từ DAG, không từ "có sẵn thì cho vào".
• Bỏ qua kiểm tra giả định. DiD mà không xem parallel trends, matching mà không xem balance/overlap — là báo cáo một con số vô nghĩa với vẻ ngoài đáng tin.
• Lẫn ATT và ATE khi giải trình. "Chương trình đã hiệu quả trên nhóm tham gia" (ATT) khác "nếu nhân rộng toàn hàng thì tác động" (ATE). Nói nhầm dẫn tới quyết định nhân rộng sai.
• Quên kết hợp thí nghiệm khi có thể. Nếu chương trình chưa triển khai, đừng vội chọn DiD — thử thiết kế RCT/pilot ngẫu nhiên cho một nhóm nhỏ trước. Một RCT nhỏ đáng tin hơn một quan sát lớn.

Văn hoá "đo tác động thật" & đạo đức

Suy luận nhân quả không chỉ là kỹ thuật, mà là văn hoá ra quyết định. Một team dữ liệu ngân hàng trưởng thành sẽ mặc định hỏi "làm sao biết cái này thực sự tạo ra khác biệt?" thay vì hài lòng với một biểu đồ đi lên. Điều này cần:

• Phối hợp liên phòng: người phân tích (thiết kế), đội rủi ro (biến confounder về hành vi tín dụng, giả định vỡ nợ), đội tuân thủ/pháp chế (được phép tạo nhóm đối chứng không, có phân biệt đối xử không). Một RDD quanh cutoff điểm tín dụng chạm cả ba.
• Khiêm tốn về kết luận: kết quả từ dữ liệu quan sát luôn kèm chữ "với giả định X". Đừng biến "ước lượng có điều kiện" thành "sự thật".

Về đạo đức, ngân hàng làm việc với tiền và tín dụng của người dân — không được thí nghiệm bừa lên khách:

• Không gây hại: không ngẫu nhiên từ chối dịch vụ hay áp phí cao hơn cho một nhóm chỉ để "đo tác động". Chuẩn RCT phải qua rà soát (chỉ thí nghiệm cái vô hại như thứ tự hiển thị, nội dung thông báo).
• Công bằng (fairness): kiểm tra can thiệp không tạo tác động chênh lệch bất lợi theo giới, vùng, nhóm thu nhập. Một chương trình "hiệu quả trung bình" có thể gây hại cho một phân khúc — luôn tách hiệu ứng theo nhóm (heterogeneous effects).
• Bảo mật & minh bạch: dữ liệu dùng cho đánh giá tác động vẫn chịu ràng buộc Nghị định 13/2023 về bảo vệ dữ liệu cá nhân — tối thiểu hoá, ẩn danh khi có thể (liên hệ gov-07-privacy-compliance).

Tổng kết series — bản đồ 8 bài

Series này nối tiếp nền thống kê A/B testing và các cạm bẫy thống kê, và bổ trợ cho thực hành thí nghiệm & tăng trưởng sản phẩm. Nhiều bài toán ở đây chạm trực tiếp chấm điểm tín dụng — nơi cutoff điểm là mảnh đất màu mỡ cho RDD.

Use case thực tế

Bối cảnh: NCB muốn đánh giá hai can thiệp và phải chọn phương pháp cho từng cái.

Can thiệp A — Chương trình miễn phí chuyển khoản (đã chạy Q2/2024, chi ~8 tỷ/năm). Câu hỏi: có tăng số giao dịch/khách trên nhóm tham gia (ATT) không?

• Đi cây quyết định: không ngẫu nhiên hoá được (đã chạy xong) → không có cutoff → không có instrument rõ → có nhóm (tham gia / không) và dữ liệu trước–sau → DiD.
• Thực hiện: lấy tổng giao dịch/khách 90 ngày trước và 90 ngày sau mốc phát ưu đãi cho cả hai nhóm. Kiểm tra parallel trends bằng cách vẽ xu hướng 6 tháng trước can thiệp — hai nhóm phải song song.
• Kết quả điển hình: so sánh ngây thơ cho +24 giao dịch/khách; sau DiD (trừ đi xu hướng chung mà nhóm control cũng có) chỉ còn ATT ≈ +5. ROI tính lại trên +5 mới là căn cứ giải trình cho ban lãnh đạo — chênh 24 vs 5 là khoản suýt "trả cho hiệu ứng không có thật".

Can thiệp B — Cấp thẻ tín dụng cho khách đạt điểm ≥ 600. Câu hỏi: được cấp thẻ làm tăng chi tiêu và có làm tăng tỷ lệ nợ xấu không?

• Đi cây quyết định: không ngẫu nhiên hoá được (quy định nội bộ theo điểm) → có cutoff = 600 → RDD.
• Thực hiện: so nhóm khách điểm 595–599 (bị từ chối) với 600–604 (được cấp). Hai nhóm gần như tương đương về hồ sơ (chỉ cách nhau vài điểm gần như ngẫu nhiên), nên chênh lệch chi tiêu & nợ xấu giữa họ quy được cho việc được cấp thẻ — không cần giả định "đã đo hết confounder". Cần đội rủi ro tham gia định nghĩa nợ xấu và đội tuân thủ xác nhận việc so sánh không vi phạm nguyên tắc đối xử.
• Lưu ý: RDD chỉ cho tác động tại vùng quanh ngưỡng (local effect) — không suy ra được cho khách điểm 800. Nói rõ khi giải trình.

Hai can thiệp, hai phương pháp khác nhau, cùng một quy trình: câu hỏi rõ → DAG/giả định → chọn theo cây → kiểm tra giả định → ước lượng có CI → robustness.

Ghi nhớ

• Ngân hàng đặc biệt cần causal quan sát vì phần lớn quyết định (chính sách toàn hàng, đổi lãi/phí, quy định, chương trình đã chạy) không A/B được — nhưng vẫn phải biết tác động thật để quyết định & giải trình.
• Cây quyết định chọn phương pháp: ngẫu nhiên được → RCT; có cutoff → RDD; có instrument → IV; có nhóm & trước/sau → DiD; chỉ cross-section & tin đã đo hết confounder → matching/propensity; cần nhắm can thiệp → uplift.
• Ánh xạ use case: ưu đãi đã chạy → DiD/matching; cấp tín dụng quanh cutoff → RDD; giữ chân → uplift; đổi phí/lãi → DiD; rollout theo vùng → DiD staggered.
• Quy trình 6 bước: câu hỏi rõ (T,Y,ATE/ATT) → DAG & giả định → chọn phương pháp → kiểm tra giả định (trends/overlap/balance) → ước lượng có CI → robustness/sensitivity.
• Cạm bẫy: confounder ẩn, nhầm predict với nhân quả (ML dự báo giỏi ≠ trả lời nhân quả), đưa hết biến vào hồi quy, bỏ qua kiểm tra giả định, lẫn ATT/ATE.
• DiD 2×2 = (treated_post − treated_pre) − (control_post − control_pre); chỉ đúng khi parallel trends thoả.
• Văn hoá & đạo đức: đo tác động thật, phối hợp data/rủi ro/tuân thủ, khiêm tốn về giả định; không thí nghiệm bừa lên khách, kiểm tra công bằng, tuân thủ NĐ13.