Nhãn Rủi Ro Tín Dụng: Trước Khi Train Model, Hãy Thống Nhất “Bad” Là Gì

Điểm cần nhớ

• Hãy xem nhãn rủi ro tín dụng như một thỏa thuận nghiệp vụ, không phải chỉ là một cột bad_flag.
• Một label tốt luôn cần bốn phần: điểm quan sát, sự kiện bad, outcome window và quy tắc maturity.
• Không dùng chung một khoảng thời gian quan sát cho mọi sản phẩm. BNPL, cash loan, thẻ tín dụng và behavior scorecard có nhịp rủi ro rất khác nhau.
• Kiểm tra cohort đã đủ mature, tức đã đủ thời gian để rủi ro xuất hiện, trước khi chia train/test.
• Gian lận, tất toán thỏa thuận, xóa nợ và tái cơ cấu cần rule riêng; nhét tất cả vào một flag “bad” sẽ gây khó khi theo dõi và review chính sách.

Sơ đồ dưới đây là cách nhìn tối thiểu về một label tín dụng. Điểm cần chú ý là label không xuất hiện ngay lúc giải ngân; bạn phải chờ đủ outcome window để rủi ro có cơ hội bộc lộ.

Outcome window — từ origination (T₀) đến label maturity

Loading diagram…

Hình 1. Outcome window nối thời điểm quan sát với thời điểm label đủ mature; nếu chốt label quá sớm, dữ liệu huấn luyện sẽ thiếu bad thật.

---

1. Tổng quan: Label là hợp đồng rủi ro

Một credit model không bắt đầu từ XGBoost, feature store hay hyperparameter tuning. Nó bắt đầu từ một hợp đồng nghiệp vụ: rủi ro nào đang được model hóa, quan sát từ đâu, trong bao lâu, và khi nào đủ chắc để gọi một hồ sơ là good hoặc bad.

Nếu hợp đồng này mơ hồ, model vẫn có thể có AUC đẹp nhưng trả lời sai câu hỏi decisioning. Risk có thể đang review 60+ DPD within 12 months, Product quan tâm early delinquency, còn DS lại train 30+ DPD within 6 months. Khi đó vấn đề không nằm ở thuật toán; vấn đề là tổ chức chưa thống nhất rủi ro nào cần được đưa vào quyết định.

Bài này đi qua các khái niệm cần chốt trước khi modeling: DPD, bad flag, outcome window, label maturity, các họ label như Ever-90/FPD/MOB/roll-rate, và những lỗi khiến mô hình nhìn ổn trong notebook nhưng sai khi đưa vào cutoff, pricing, limit hoặc monitoring.

2. Vấn đề thường gặp: Data Science và Risk không dùng cùng một định nghĩa

Một tình huống tôi gặp khá nhiều là Data Science train model bằng một định nghĩa, còn Risk hoặc Product lại ra quyết định bằng một định nghĩa khác. Ví dụ, team model dùng DPD >= 30 trong 6 tháng, nhưng policy review lại quan tâm DPD >= 60 trong 12 tháng. Hai thứ này không tương đương.

Vấn đề không nằm ở thuật toán. Vấn đề là mô hình đang học một câu hỏi khác với câu hỏi mà business thật sự cần trả lời. Khi đó, dù AUC đẹp, model vẫn có thể khó dùng trong phê duyệt, pricing, limit hoặc collection.

3. Khái niệm cốt lõi: DPD, bad flag, outcome window và label maturity

3.1. DPD là gì?

DPD (Days Past Due - số ngày quá hạn) đo số ngày khách hàng trễ thanh toán so với ngày đến hạn. Đây là ngôn ngữ nền tảng của rất nhiều credit label.

DPD = Ngày hiện tại − Ngày đến hạn thanh toán gần nhất bị trễ

Ví dụ: due date là 1/3, đến 15/3 vẫn chưa thanh toán → DPD = 14.

Bảng dưới đây không nói label nào “đúng nhất”. Nó cho thấy mỗi ngưỡng DPD đại diện cho một mức độ rủi ro khác nhau.

Label	Định nghĩa DPD	Ghi chú
Bad-30	DPD ≥ 30 bất kỳ lúc nào trong window	Nhạy hơn, bad rate cao hơn
Bad-60	DPD ≥ 60	Thường cân bằng hơn giữa signal và sample
Bad-90	DPD ≥ 90	Nặng hơn, gần với write-off/charge-off policy
Ever-90	Từng đạt DPD 90+ trong window	Không yêu cầu liên tục

Không có định nghĩa nào đúng trong chân không. Một label chỉ đúng khi nó khớp với risk appetite, product mechanics, và decision mà model sẽ phục vụ.

3.2. Bad flag là gì?

Bad flag là cột target mà mô hình học, thường có giá trị 1 nếu hồ sơ trở thành bad và 0 nếu không. Nhưng đừng để cái tên đơn giản này đánh lừa bạn. Đằng sau một bad_flag tốt phải có đủ bốn phần:

• Observation point: bạn bắt đầu quan sát từ đâu? Origination, approval date, statement date hay MOB cụ thể?
• Bad event: sự kiện nào được xem là bad? DPD 30, DPD 60, charge-off hay restructuring?
• Outcome window: bạn chờ bao lâu để rủi ro xuất hiện?
• Maturity rule: cohort nào đã đủ thời gian để kết luận good/bad?

Nếu thiếu một trong bốn phần này, label spec chưa đủ để train model một cách nghiêm túc.

3.3. Outcome window là gì?

Outcome window là khoảng thời gian từ điểm quan sát đến khi bạn gắn label. Ví dụ với window 12 tháng: khách vay tháng 1/2023, bạn nhìn hành vi đến tháng 1/2024. Nếu trong period đó có DPD ≥ 60, label = bad.

Hình dưới đây mô tả cách outcome window hoạt động trong một bài toán application score. Khi đọc hình, hãy để ý rằng feature được lấy tại thời điểm quan sát, còn label chỉ biết sau khi window kết thúc.

Từ origination (quan sát) tới ngày gắn nhãn

Loading diagram…

Hình 2. Feature và label không đến từ cùng một thời điểm; feature nhìn tại lúc ra quyết định, còn label cần thời gian để mature.

Window là một trade-off thật sự, không phải tham số chọn đại:

• Window ngắn (3-6 tháng): dữ liệu mature nhanh hơn, nhưng có thể bỏ sót default muộn. Phù hợp hơn với BNPL hoặc khoản vay ngắn.
• Window dài (12-24 tháng): tín hiệu đầy đủ hơn, nhưng phải chờ lâu hơn. Phù hợp hơn với cash loan, personal loan hoặc mortgage.

3.4. Label maturity là gì?

Một cohort được gọi là mature khi phần lớn hồ sơ đã có đủ thời gian để thể hiện hành vi bad nếu họ sẽ bad. Nếu cohort chưa mature, bad rate thường vẫn tiếp tục tăng theo tháng quan sát.

Đây là lỗi rất dễ gặp: lấy cohort quá mới, gắn những hồ sơ chưa đủ thời gian là good, rồi train model. Khi đó, mô hình học từ outcome chưa hoàn chỉnh.

4. Ví dụ thực tế: Ever-30, Ever-60, FPD và MOB khác nhau thế nào?

Trong thực tế, “bad” thường được đặt tên theo ba trục: mức độ quá hạn, window, và điểm quan sát. Bảng dưới đây giúp bạn đọc nhanh ý nghĩa của từng họ label.

Họ label	Cách hiểu	Khi nào dùng	Cần cẩn thận
Ever-30/60/90 in 12M	Trong 12 tháng, khách từng đạt DPD 30/60/90	Application score, phê duyệt hồ sơ	Window phải đủ dài so với tenor
FPD / EPD	Khách trễ ngay kỳ đầu hoặc rất sớm sau giải ngân	Early warning, fraud/quality check channel	Dễ lẫn credit risk với fraud hoặc onboarding issue
MOB3 / MOB6 / MOB12	Gắn label theo hành vi trong k tháng đầu sau booking	Sản phẩm ngắn hạn, feedback loop nhanh	Cần định nghĩa cumulative hay point-in-time
Roll-rate	Tài khoản chuyển từ bucket DPD này sang bucket xấu hơn	Card, revolving, collection	Phù hợp behavior score hơn application score

Điểm quan trọng không phải thuộc tên label. Điểm quan trọng là đọc được câu hỏi nghiệp vụ phía sau label đó.

5. Cách làm trong dự án thật: Viết label spec trước khi EDA

Trước khi EDA, tôi muốn có một label spec ngắn. Không cần dài, nhưng phải đủ rõ để Risk, Product, Data và DS cùng hiểu một nghĩa.

Một label spec tối thiểu nên trả lời:

• Observation point là ngày nào?
• Bad event là DPD bao nhiêu, charge-off hay event khác?
• Outcome window dài bao lâu?
• Cohort nào được xem là mature?
• Fraud, settlement, restructuring, write-off xử lý thế nào?
• Train set và monitoring có dùng cùng định nghĩa không?

Để kiểm tra maturity, đoạn code dưới đây vẽ vintage bad rate. Đây thường là chart đầu tiên tôi muốn xem trước khi tin một label.

pythonCopy
import matplotlib.pyplot as plt

def plot_vintage_bad_rate(df, origination_col, mob_col, bad_col):
    """
    Vẽ bad rate tích lũy theo từng vintage.

    Input:
    - df: dữ liệu loan theo từng month-on-book
    - origination_col: tháng giải ngân hoặc tháng mở tài khoản
    - mob_col: MOB (Month on Book), ví dụ 1, 2, 3...
    - bad_col: cờ bad tích lũy tại từng MOB

    Output:
    - Biểu đồ bad rate tích lũy theo vintage
    """
    pivot = df.pivot_table(
        index=mob_col,
        columns=origination_col,
        values=bad_col,
        aggfunc="mean",
    )

    pivot.plot(figsize=(12, 5), alpha=0.7)
    plt.title("Vintage Cumulative Bad Rate by MOB")
    plt.xlabel("Month on Book")
    plt.ylabel("Cumulative Bad Rate")
    plt.legend(title="Origination Cohort", bbox_to_anchor=(1.05, 1))
    plt.tight_layout()

Nếu các đường vintage vẫn tăng mạnh ở cuối trục MOB, cohort chưa mature. Khi đó, split train/test ngay sẽ làm mô hình học từ dữ liệu chưa đủ thời gian phát triển bad.

6. Lỗi thường gặp khi gắn nhãn rủi ro

Lỗi	Dấu hiệu	Hệ quả	Cách tránh
Dùng window quá ngắn	Bad rate vẫn tăng sau cutoff	Gắn nhầm good cho hồ sơ chưa đủ thời gian bad	Kiểm vintage maturity
Không thống nhất DPD threshold	Risk nói Bad-60, DS train Bad-30	Model trả lời sai câu hỏi nghiệp vụ	Sign-off label spec trước EDA
Gộp fraud vào credit bad	Bad sớm bất thường theo channel	Model học fraud/onboarding thay vì credit risk	Exclude hoặc tách fraud label
Dùng cùng label cho mọi sản phẩm	BNPL, card, cash loan có curve khác nhau	Monitoring lệch theo product	Chọn window theo tenor và product mechanics

7. Gợi ý cho người mới

Nếu bạn mới làm credit scoring, hãy tập thói quen viết label spec trước khi viết notebook. Chỉ cần một trang cũng được, miễn là đủ rõ: bad là gì, quan sát từ đâu, chờ bao lâu, case nào exclude, và cohort nào đủ mature.

Khi ngồi với Risk hoặc Product, đừng hỏi “anh/chị muốn AUC bao nhiêu?”. Hãy hỏi trước: “Decision này đang cần dự báo rủi ro nào, và sau bao lâu thì mình đủ chắc để đo rủi ro đó?”.

Stakeholder-ready answer:

Trước khi model performance có ý nghĩa, mình cần sign off label definition. Nếu Risk, Product và DS đang dùng các bad definition khác nhau, model có thể rank tốt nhưng vẫn không phục vụ đúng policy decision.

8. Hỏi đáp nhanh

DPD 30 hay DPD 60 tốt hơn?
Không có câu trả lời chung. DPD 30 nhạy hơn nhưng noisy hơn; DPD 60 thường nghiêm hơn nhưng bad rate thấp hơn.

Outcome window có nên dùng 12 tháng cho mọi sản phẩm không?
Không nên. Window phải đi theo tenor, sản phẩm và quyết định mà model phục vụ.

Cohort chưa mature có dùng để train được không?
Không nên dùng như dữ liệu đã hoàn chỉnh. Nếu bắt buộc dùng, cần xử lý censoring hoặc thiết kế bài toán khác.

Fraud có nên tính là bad không?
Thông thường không nên gộp trực tiếp vào credit bad. Fraud nên có rule hoặc model riêng.

9. Tài liệu tham khảo

Các tài liệu tham khảo chi tiết nằm ở phần cuối bài.

---