「वित्तीय डेटा साइंस की बुनियाद」 श्रृंखला शुरू कर रहा हूँ। यह लेख इसकी पहली कड़ी (Part 0) है। मैं Part 0 से किताब की तरह क्रमवार समझाना चाहता हूँ कि क्रेडिट अंडरराइटिंग के मैदान में डेटा साइंस सामान्य ML से अलग तरीके से क्यों काम करता है। इसमें reject inference, causal inference, calibration, validation, fairness और regulation जैसे विषय शामिल हैं。
मूल लेख पहले मेरे ब्लॉग पर प्रकाशित किया गया था → https://han-co.com/ko/blog/part0-finance-ds-7-differences
मैं इस क्षेत्र में बहुत लंबे समय से काम करने वाला कोई दिग्गज नहीं हूँ। मैन्युफैक्चरिंग इंजीनियर के रूप में काम करने के बाद मैं वित्त क्षेत्र में आया, और अब क्रेडिट अंडरराइटिंग से जुड़े डेटा साइंटिस्ट के रूप में काम कर रहा हूँ। इसलिए इस लेख को भी "यही सही जवाब है" की तरह नहीं, बल्कि इस क्षेत्र में आने के बाद जिन बातों में मैं उलझा, और जिन पलों में लगा, 'अरे, किताब के मुताबिक किया था, फिर बार-बार गलत क्यों हो रहा है?' — उनका एक संकलन समझें।
दिलचस्प बात यह है कि यह सिर्फ मेरे साथ नहीं हुआ। सामान्य ML मॉडल बनाना और उसका मूल्यांकन अच्छी तरह करने वाला व्यक्ति भी जब क्रेडिट अंडरराइटिंग में आता है, तो वह अक्सर इसी तरह की गलतियाँ एक बार ज़रूर करता है। validation metric अच्छे होते हैं, लेकिन असली काम में मॉडल अपनी क्षमता नहीं दिखाता; accuracy 99% है, फिर भी कोई खुश नहीं होता; performance में 0.01 और निकाल लिया, तो risk department deployment रोक देता है…
यह सिर्फ कौशल की समस्या नहीं है, बल्कि इसलिए है कि वित्त (खासतौर पर क्रेडिट अंडरराइटिंग) 'वित्तीय डेटा पर ML लागू करना' भर नहीं है, बल्कि यह अपने अलग नियमों वाला क्षेत्र है। और आगे इस श्रृंखला में जिन लगभग सभी चीज़ों पर बात होगी — यानी reject inference, causal inference, calibration, validation, fairness — वे अंततः इन्हीं नियमों पर आधारित हैं।
1. selection bias डिफॉल्ट है
हमारे पास जो training data है, उसमें असल में एक बड़ा छेद है। हमें केवल उन्हीं ग्राहकों के repayment outcomes दिखते हैं जिन्हें approve किया गया था। जिन ग्राहकों को reject किया गया, उन्होंने वास्तव में भुगतान किया होता या default किया होता — यह हम कभी नहीं जान सकते। क्योंकि उन्हें शुरू से कार्ड जारी ही नहीं किया गया था।
सामान्य ML आमतौर पर यह मानता है कि "डेटा पूरी population का प्रतिनिधित्व करता है"। लेकिन क्रेडिट अंडरराइटिंग में यह मान्यता शुरुआत से ही टूट चुकी होती है। training data उन ग्राहकों का होता है जिन्हें अतीत में approve किया गया था, जबकि मॉडल को जिन लोगों पर निर्णय देना है वे अभी तक approve न किए गए सभी applicants हैं। ये दोनों अलग populations हैं।
पूरे applicants
├─ Approved (outcome observed)
│ ├─ Repayment → सामान्य भुगतान
│ └─ Default → delinquency·default
└─ Rejected (outcome not observed) → ??? भुगतान किया होता या default किया होता, पता नहीं
मॉडल केवल 'approved customers' से सीखता है। rejected customers के वास्तविक outcomes डेटा में बचते ही नहीं हैं।
यह एक बात जितना लगता है उससे कहीं अधिक समस्याएँ पैदा करती है। "जिन ग्राहकों को reject किया गया था" उनके reject होने के बाद का डेटा ही नहीं होता, इसलिए मॉडल उस हिस्से को सीख ही नहीं पाता जिसे उसने स्वयं reject किया था, और वह पिछली underwriting policy के bias को ज्यों-का-त्यों विरासत में ले लेता है। इसलिए इस क्षेत्र में reject inference और causal inference कोई खास तकनीक नहीं, बल्कि बुनियादी ज़रूरत हैं। (इन दोनों पर आगे अलग-अलग विस्तार से चर्चा करूँगा।)
2. समय एक ही दिशा में बहता है, और मॉडल बूढ़े होते हैं
अगर आपने डेटा को random shuffle करके K-fold चलाया, तो असल में आपने भविष्य की थोड़ी cheating कर ली। क्योंकि validation data में अतीत और भविष्य का डेटा मिला-जुला होता है।
क्रेडिट डेटा समय के साथ बहता है। 2024 के subscriber data पर train किया गया मॉडल 2026 के ग्राहकों का मूल्यांकन करता है। इस बीच अर्थव्यवस्था बदलती है, interest rates बढ़ते हैं, ग्राहक व्यवहार और products बदलते हैं। यानी distribution drift करती है। random K-fold अतीत और भविष्य को एक साथ मिला देता है, और validation में चुपके से ऐसी जानकारी घुसा देता है जो production में कभी उपलब्ध नहीं होगी।
इसलिए वित्त में बुनियादी validation OOT(out-of-time) होता है, यानी training period के बाद के समय पर evaluation। deployment के बाद भी यह लगातार monitor करना पड़ता है कि distribution कितना बदला है और समय के साथ ग्राहक कैसे बदल रहे हैं। मॉडल deployment के क्षण से ही बूढ़ा होना शुरू कर देता है।
3. सिर्फ "कौन ज्यादा risky है" काफी नहीं, "ठीक कितने % है" भी चाहिए
सामान्य classification problems में अक्सर ranking सही होना ही काफी होता है। कौन अधिक risky है, बस उसे सही क्रम में रखना होता है, और AUC उसी क्षमता को मापता है।
लेकिन क्रेडिट में बात वहीं खत्म नहीं होती। absolute probability, यानी calibrated PD की ज़रूरत होती है। "इस ग्राहक के default की probability ठीक 3.2% है" — ऐसा नंबर होना चाहिए, तभी pricing(risk-based pricing), provisioning, और expected loss की गणना की जा सकती है। सिर्फ ranking से इनमें से कुछ भी नहीं किया जा सकता।
इसलिए क्रेडिट में यह स्थिति काफी आम है: AUC शानदार है, लेकिन PD गलत है। discrimination और calibration दो अलग अक्ष हैं, इसलिए दोनों का ध्यान रखना पड़ता है। (सिर्फ calibration पर एक अलग लेख तैयार किया है। हैरानी की बात है कि लोग इसे अक्सर छोड़ देते हैं।)
4. लागत asymmetric होती है, बहुत देर से आती है, और रकम की इकाई में होती है
accuracy सभी errors को एक जैसा गिनती है। लेकिन क्रेडिट में errors का वजन बिल्कुल एक जैसा नहीं होता।
एक अच्छे ग्राहक को approve करके होने वाली कमाई margin होती है (कुछ हज़ार yen), जबकि एक default की लागत LGD × EAD होती है (कई लाख yen)। एक तरफ का वजन दूसरी तरफ से कई गुना भारी है। इसलिए हमें accuracy नहीं, बल्कि expected profit और expected loss को optimize करना चाहिए।
Expected Profit = (1 − PD) × Margin − PD × LGD × EAD
default होने पर expected loss (EL) फिर तीन घटकों के गुणनफल में टूटता है।
EL = PD × LGD × EAD
- PD: default probability
- LGD: default होने पर loss rate
- EAD: default के समय exposure balance
ये तीनों अलग-अलग modeling problems हैं। scoring का केंद्र PD है।
इसके अलावा सही label बहुत देर से आता है। आज approve किया गया ग्राहक default करेगा या नहीं, यह 12–24 महीने बाद जाकर तय होता है। labels का इस तरह देर से आना, तेज feedback के आदी ML mindset से काफी टकराता है। क्योंकि हमें परिणाम जाने बिना ही लगातार निर्णय जमा करते रहना पड़ता है।
5. stability, extreme performance से ज्यादा महत्वपूर्ण है
अगर यह ML competition हो, तो AUC में 0.001 भी और निकाल लेना एक गुण माना जाएगा। Kaggle जैसी प्रतियोगिताओं में तो खासकर। लेकिन वास्तविक क्रेडिट मॉडलिंग में यह अक्सर नुकसानदेह होता है।
थोड़ी-सी और performance पाने की कोशिश में unstable हो गया मॉडल, operations में जल्दी ही लागत बन जाता है। ऐसा मॉडल जिसमें inputs थोड़े से हिलें तो score उछलने लगे, reproducibility न हो, या "आय जितनी अधिक, score उतना कम" जैसी अजीब range बन जाए। operational stability, reproducibility, और monotonicity अक्सर decimal-level performance से अधिक महत्वपूर्ण होती हैं। GBM के युग में भी logistic regression का scoring standard के रूप में टिके रहने का एक कारण यह भी है।
6. interpretability विकल्प नहीं, ज़िम्मेदारी है
दूसरे क्षेत्रों में "यह prediction क्यों आया?" समझा पाना अच्छा bonus होता है। लेकिन क्रेडिट में कई बार अगर यह नहीं हो सके, तो या तो वह गैरकानूनी है या deployment ही संभव नहीं होता।
adverse action notice(अस्वीकृति कारण), regulators को explanation, और internal governance — सभी यह माँगते हैं कि "यह score क्यों आया" समझाया जाए। इसलिए black box कोई आकर्षक चीज़ नहीं, बल्कि अपने आप में risk है। इसी वजह से वास्तविक काम में WOE या scorecard जैसी ऐसी संरचनाएँ पसंद की जाती हैं जिनसे कारण स्वाभाविक रूप से निकलते हैं, और boosting इस्तेमाल करने पर भी SHAP से कारण निकालने की व्यवस्था साथ में रखी जाती है।
7. regulation और governance का overhead हमेशा मौजूद रहता है
अंत में, मॉडल को मनचाहे तरीके से deploy नहीं किया जा सकता।
मॉडल बन जाने से काम खत्म नहीं होता। model risk management(MRM), independent validation, documentation, और audit trail — ये सब development process का हिस्सा हैं। developers और validators अलग होते हैं, और नया मॉडल आमतौर पर लंबे समय तक shadow mode में साथ-साथ observe करने के बाद ही वास्तविक decision-making में जाता है। "अच्छा performance वाला मॉडल जल्दी deploy कर दो" — startup वाली यह सहज समझ यहाँ अक्सर काम नहीं करती। धीमापन बेवजह नहीं है। क्योंकि एक मॉडल से provisioning और capital calculation तक सब प्रभावित होता है।
(जापान में काम करते हुए यह बात और भी ज्यादा महसूस होती है। कार्ड issuance और limit पर Installment Sales Act(割賦販売法) के तहत भुगतान-क्षमता अनुमान राशि(支払可能見込額) की गणना का कानूनी दायित्व होता है, इसलिए मॉडल सीधे कानूनी आधार बन जाता है। इस बारे में regulation वाले भाग में अलग से बात करूँगा।)
क्या यह सब AI अपने आप नहीं कर देगा?
आजकल मुझसे यह सवाल अक्सर पूछा जाता है। generative AI और agents इतनी तेजी से आगे बढ़ रहे हैं, तो क्या ऐसी modeling knowledge को अलग से सीखने की ज़रूरत सच में है? मेरा ईमानदार जवाब है: उल्टा, इसकी ज़रूरत और बढ़ गई है (कम-से-कम अभी तक तो)।
अब तक जिन 7 बातों को देखा, वे किसी खास algorithm की नहीं, बल्कि इस क्षेत्र की समस्या-संरचना की बातें हैं। unobserved counterfactuals, समय-क्रम में बहता डेटा, asymmetric cost, absolute probability, stability, explanation की बाध्यता, regulation। LLM जोड़ देने से ये समस्याएँ गायब नहीं हो जातीं। बल्कि यह समझने वाला कोई होना चाहिए कि ये समस्याएँ मौजूद हैं, ताकि auto-generated मॉडल आत्मविश्वास के साथ गलत न साबित हो जाए।
खासतौर पर 6 और 7 सबसे अहम हैं। rejection के कारण समझाने होते हैं, मॉडल का independent validation करना होता है, और उसके परिणाम provisioning व capital calculation का आधार बनते हैं। black box मॉडल इन आवश्यकताओं के सामने संरचनात्मक रूप से अटक जाते हैं। इसलिए generative AI क्रेडिट अंडरराइटिंग को पूरी तरह अपने हाथ में नहीं ले पा रहा; बल्कि "explainability क्यों ज़रूरी है और validation कैसे होता है" यह जानने वाला व्यक्ति उस AI के आउटपुट का अंतिम निर्णय लेने वाली जगह पर बना रहता है।
बेशक, कुछ चीज़ें बदल रही हैं। दोहराव वाला coding work या बुनियादी analysis धीरे-धीरे AI की भूमिका बन रहे हैं। इसलिए व्यावहारिक काम का केंद्र हाथ से मॉडल लिखने की क्षमता से हटकर, समस्या को सही ढंग से परिभाषित करने, validate करने, और review करने की judgement पर जा रहा है। यह श्रृंखला उसी दूसरे हिस्से पर केंद्रित है।
तो इस क्षेत्र में असली कौशल क्या है
अगर इन 7 बातों को एक पंक्ति में बाँधें, तो वह यह है।
वित्तीय डेटा साइंस "prediction accuracy की प्रतियोगिता" नहीं है, बल्कि unobserved counterfactuals को, समय के साथ बदलते और asymmetric cost वाले वातावरण में, explainable और stable तरीके से estimate करने का काम है।
evaluation metrics और scorecards सिर्फ प्रवेश-पत्र की तरह हैं। असली कौशल का फर्क selection bias, causality, validation, और governance में दिखाई देता है।
इस श्रृंखला में मैं इन 7 बातों को एक-एक करके धीरे-धीरे खोलूँगा। reject inference को कैसे हल किया जाता है, calibration में लोग बार-बार क्यों चूकते हैं, causal inference underwriting के केंद्र में क्यों है, validation कैसे किया जाए ताकि मॉडल production में टिक सके। अगली कड़ी से साथ चलते हैं।
यह लेख पहली बार han-co.com पर प्रकाशित हुआ था, और इसे कोरियाई व जापानी में साथ-साथ श्रृंखला के रूप में जारी किया जा रहा है। hand-drawn diagrams वाले मूल लेख और email subscription यहाँ उपलब्ध हैं → https://han-co.com/ko/blog/part0-finance-ds-7-differences
अभी कोई टिप्पणी नहीं है.