Decision rules और thresholds
हर check warnings पैदा करता है, और आप तय करते हैं कि हर warning क्या करे - pass, review, या decline। यही mapping है जहां आपका risk appetite असल में मौजूद रहता है।
हर step अपनी warnings को किसी action से जोड़ता है: pass, review, या decline। Decline के लिए configured कोई step workflow को रोक देता है - बाद के steps कभी नहीं चलते, और आपसे उनके लिए बिल नहीं लिया जाता। इसी वजह से rule का क्रम एक साथ risk का फैसला भी है और cost का भी।
#फैसले असल में कहां होते हैं
किसी workflow को "जो checks मैं चलाता हूं" मान लेना आसान है। Checks इसका सिर्फ आधा हिस्सा हैं। दूसरा आधा - और वही आधा जो आपकी approval rate तय करता है - यह है कि हर check की warnings क्या करने के लिए configured हैं।
- हर feature node की अपनी thresholds और अपना decision होता है।
- कोई check ज़रूरी या वैकल्पिक हो सकता है, जो खुद इस बात का फैसला है कि कौन आगे बढ़ता है।
- Workflow सेव होते ही बदला हुआ rule नए sessions तक पहुंच जाता है।
हर step के लिए, वह जो भी warning उठा सकता है वह इन तीन actions में से किसी एक से जुड़ता है:
| Action | असर |
|---|---|
| Approve (या ignore) | Warning दर्ज हो जाती है लेकिन नतीजा नहीं बदलती |
| Review | Session किसी व्यक्ति के फैसले के लिए In Review पर चला जाता है |
| Decline | Session decline हो जाता है और workflow रुक जाता है |
यह mapping ही configuration में लिखी गई आपकी policy है।
#Decline होने पर workflow रुक जाता है
यही वह व्यवहार है जो लोगों को सबसे ज़्यादा हैरान करता है, इसलिए इसे साफ़ कह देना ज़रूरी है: जब कोई step decline करता है, तो वहीं execution रुक जाता है। उसके बाद के steps कभी नहीं चलते।
दो नतीजे:
- रिज़ल्ट में वे checks नहीं होंगे जिनकी आपको उम्मीद थी। वे fail नहीं हुए - वे चले ही नहीं। ID verification पर decline हुए session में कोई liveness, कोई face match, कोई AML नहीं होगा।
- उनका बिल नहीं लगता। Billing प्रति पूरे हुए feature पर होती है, इसलिए जो step कभी चला ही नहीं उसकी कोई कीमत नहीं।
#Rule के क्रम से cost नियंत्रित करना
चूंकि decline flow को रोक देता है, इसलिए step का क्रम खर्च को नियंत्रित करने का एक तरीका है। किसी महंगे bundle से पहले सस्ता risk check रखने का मतलब है कि जो traffic वैसे भी पास नहीं होने वाला था वह महंगे हिस्से के लिए pay करने से पहले ही रुक जाता है।
$0.03 का Device और IP analysis किसी पूरे KYC flow से पहले रखना इसकी मानक मिसाल है: यह उस traffic को सस्ते में छांट देता है जिसे आप वैसे भी अस्वीकार करते।
इसका trade-off है user experience और false positives। Device और IP signals, Didit के सबसे noisy checks हैं - corporate networks, carrier NAT, और cloud browsers, असली यूज़र्स को भी shared addresses के पीछे डाल देते हैं। पूरे flow को इन पर gate करने से असली ग्राहक भी block हो जाएंगे, इसलिए जब तक आपने अपने खुद के traffic को माप न लिया हो, decline की जगह review पर route करें।
#जिन rules के लिए automation नहीं, judgement चाहिए
कुछ warnings बिल्कुल स्पष्ट होती हैं और उन्हें decline करना ही चाहिए: MRZ checksum का fail होना, कोई chip जिसका signature उसके issuer तक chain नहीं होता, आपकी blocklist पर मौजूद कोई चेहरा। ये integrity की विफलताएं हैं।
बाकी लगभग हमेशा review के रूप में बेहतर रहती हैं:
- Proof of address पर आंशिक address मेल - देश के हिसाब से formats अलग होते हैं।
- Database validation पर आंशिक नाम मेल - authoritative sources नामों को अलग-अलग तरीके से दर्ज करते हैं।
- कम-confidence वाले AML candidate hits - आम नाम इन्हें लगातार पैदा करते हैं।
- कोई borderline face match - देखें face match scores और thresholds।
- Duplicate-face flag - जो नए account के लिए fraud है और लौटने वाले ग्राहक के लिए सामान्य।
और कुछ usability की विफलताएं होती हैं जो verdict की नहीं बल्कि retry की हकदार हैं: कोई NFC chip जो पढ़ा न जा सका, धुंधली capture, कोई छूटा हुआ camera frame।
#Age policies
Minimum और maximum age हर workflow के हिसाब से configure होती हैं, और violation पर action चुनना आपका काम है। MINIMUM_AGE_NOT_MET सीधे decline कर सकता है, या अगर आपकी policy evidence के साथ अपवाद की इजाज़त देती है तो review पर route कर सकता है। दोनों सही हैं; सोच-समझकर चुनें।
#Extracted data पर custom rules
Per-warning mapping के अलावा, आप उस data पर rules लिख सकते हैं जो किसी step ने निकाला है - उदाहरण के लिए, जब कोई extracted field किसी खास value पर हो तो decline करना। दो बातें ध्यान में रखें:
- Rule सिर्फ उसी data पर काम कर सकता है जो step ने असल में produce किया। अगर OCR ने वह field निकाला ही नहीं, तो rule के पास evaluate करने के लिए कुछ नहीं है।
- Decline करने वाला rule भी वैसे ही workflow को रोक देता है, ऊपर बताए गए वही नतीजे लिए हुए।
अगर आप कोई ऐसा rule बना रहे हैं जो किसी protected characteristic पर आधारित हो, तो इसे engineering से पहले अपनी compliance team के लिए एक legal सवाल मानें।
#सिर्फ steps नहीं, rules भी टेस्ट करें
किसी workflow के steps को आंख से जांचना आसान है। इसके rules उतने आसान नहीं हैं - यह जानने का एकमात्र तरीका कि कोई warning वहीं जाता है जहां आप सोचते हैं, वह warning पैदा करना है।
Sandbox इसी के लिए है। हर scenario एक खास warning को force करता है, ताकि आप हर rule के action को end to end पुष्टि कर सकें: decline_document_expired, review_face_match_borderline, decline_aml_hit, review_poa_partial_match, वगैरह। देखें sandbox में टेस्ट करना।
Review path को उतनी ही सावधानी से टेस्ट करें जितनी decline path को। Review पर route करने वाला rule तभी उपयोगी है जब कोई असल में उस queue पर काम करे, और आपकी review process काम करती है या नहीं यह जानने का तरीका है किसी असली ग्राहक के इंतज़ार करने से पहले उसमें से एक synthetic session गुज़ार कर देखना।
#बदलाव नए sessions पर लागू होते हैं
किसी workflow को edit करने से पहले से बने sessions retroactively नहीं बदलते। कोई session वही configuration रखता है जिसके साथ वह बना था, इसलिए rule बदलने के बाद, किसी पुराने session को दोबारा जांचने के बजाय एक नए session से टेस्ट करें।