बड़े पैमाने पर AML नियामकीय रिपोर्टिंग की आर्किटेक्चर तैयार करना

AML रिपोर्टिंग बैंक की सबसे कठिन डेटा समस्या क्यों है

ऊपर से देखें तो AML नियामकीय रिपोर्टिंग एक डेटा समस्या लगती है। नियामक — कनाडा में FINTRAC, अमेरिका में FinCEN — चाहता है कि आप कुछ लेनदेन पैटर्न की रिपोर्ट करें: निर्धारित सीमा से अधिक इलेक्ट्रॉनिक धन हस्तांतरण (EFTR), सीमा से अधिक नकद लेनदेन (CTR), संदिग्ध व्यवहार (STR) और असामान्य लेनदेन (UTR)। डेटा लें, उसका प्रारूप बनाएँ, भेज दें।

व्यवहार में कठिनाई यह है कि नियामक चाहता है आपस में जुड़ी पूरी कहानी: धन किसने भेजा, किसे मिला, खाते पर किसका नियंत्रण है, संबंधित पक्ष किस KYC स्तर पर हैं, FX का कौन-सा चरण किस मध्यस्थ से गुज़रा, सत्र के दौरान कौन-से साइबर संकेत मिले। यह संदर्भ बिखरा हुआ है सैकड़ों स्रोत सिस्टमों में — रिटेल कोर बैंकिंग, पूँजी बाज़ार, वाणिज्यिक ऋण, वायर हस्तांतरण, FX, ट्रेज़री, ग्राहक हब, पहचान सिस्टम — प्रत्येक की अपनी स्कीमा, अद्यतन आवृत्ति और ज़िम्मेदारी है।

दूसरे FINTRAC नियामकीय पैकेज ने इसे स्पष्ट किया: लगभग 30 अलग-अलग उपयोग परिदृश्य, जिनमें से प्रत्येक निजी, रिटेल, पूँजी बाज़ार और वाणिज्यिक व्यवसायों में वित्तीय लेनदेन को FX, ग्राहक/खाता और साइबर डेटा से जोड़ता है। आर्किटेक्चर की दृष्टि से यह रिपोर्टिंग परियोजना नहीं है। यह एक एंटरप्राइज़ एकीकरण प्लेटफ़ॉर्म है।

शुरू से अंत तक संदर्भ आर्किटेक्चर

Tier-1 बैंकों के लिए हमारे डिज़ाइन किए प्लेटफ़ॉर्मों की संरचना समान है — पाँच तार्किक परतें, जिनमें से प्रत्येक स्वतंत्र रूप से स्केल और ऑडिट की जा सकती है:

• स्रोत से डेटा ग्रहण। कोर बैंकिंग, Workday HR, ग्राहक हब, FX इंजन और साइबर संकेतों से बदले हुए डेटा का कैप्चर। कुछ सिस्टम इवेंट प्रकाशित करते हैं; पुराने सिस्टम बैच एक्सट्रैक्ट उपलब्ध कराते हैं, जिन्हें हम स्कीमा सत्यापन वाले लोडर में लपेटते हैं।
• स्ट्रीमिंग की मुख्य धुरी। Kafka जैसी इवेंट स्ट्रीम वित्तीय लेनदेन, KYC अपडेट, प्रतिबंध सूची के मिलान और खाते के जीवनचक्र संबंधी इवेंट ले जाती हैं। टॉपिक ग्राहक या खाते के अनुसार विभाजित होते हैं, ताकि प्रत्येक इकाई का क्रम बना रहे।
• जोड़ना और समृद्ध करना। स्ट्रीम-प्रोसेसिंग कार्य लेनदेन इवेंट को ग्राहक के मुख्य डेटा, खाता पदानुक्रम, FX चरणों, KYC प्रोफ़ाइल और पिछले व्यवहार से जोड़ते हैं। परिणाम एक पूरी तरह जुड़ा, रिपोर्ट योग्य रिकॉर्ड होता है, जिसका स्वरूप नियामक की आवश्यकताओं के अनुरूप है।
• पहचान और नियम। Actimize STR/UTR के लिए AML पहचान परिदृश्य होस्ट करता है; निश्चित सीमा वाले नियम और संदर्भ डेटा EFTR/CTR को संचालित करते हैं। परिणाम संभावित प्रस्तुतियों और उनके साक्ष्यों की एक स्ट्रीम है।
• प्रस्तुति और डेटा वंशावली। एक प्रस्तुति सेवा EFTR/STR/CTR/UTR पेलोड को FINTRAC की स्कीमा के अनुसार स्वरूपित करती है, उन पर हस्ताक्षर करती है और सुरक्षित चैनल से भेजती है। हर रिकॉर्ड में एक वंशावली ID होती है जो उसके स्रोत इवेंट तक पहुँचाती है।

प्लेटफ़ॉर्म आधारित है Azure पर — कंटेनरीकृत सेवाओं के लिए AKS, PostgreSQL नियामकीय प्रस्तुति भंडार के लिए, कच्चे इवेंट के लिए Azure Storage और सुरक्षा व निगरानी के लिए Azure Monitor / Sentinel। कनाडा के पाँच बड़े बैंकों की तैनातियों में हमने बेहतर बनाया है AKS पर Actimize को PostgreSQL के साथ, विशेष रूप से बड़े पैमाने पर CTR क्षमताओं के लिए।

रात के बैच के बजाय इवेंट स्ट्रीमिंग क्यों

पहले AML रिपोर्टिंग रात में चलने वाली बैच प्रक्रिया थी। जब रिपोर्टिंग दायित्वों की समयसीमा दिनों में होती थी, तब यह ठीक था। आज FINTRAC की अपेक्षा — और सच कहें तो बैंक की अपनी जोखिम स्वीकार करने की क्षमता — बहुत अधिक करीब है लगभग वास्तविक समय के। मूल वायर हस्तांतरण का निपटान कभी भी हो, EFTR विश्वसनीय रूप से शुरू होने चाहिए। लेनदेन के साथ व्यवहार के लाइव संकेत जोड़ने से STR बेहतर होते हैं।

इवेंट स्ट्रीमिंग हमें तीन ऐसी चीज़ें देती है जो बैच नहीं दे सकता। पहली, बैकप्रेशर को ध्यान में रखने वाला डेटा ग्रहण: अपस्ट्रीम की धीमी गति से नियामकीय पाइपलाइन ठप नहीं होती। दूसरी, रीप्ले: नियम बदलने पर हम स्रोत सिस्टमों को छुए बिना प्रभावित समयावधि को फिर से प्रोसेस कर सकते हैं। तीसरी, प्रत्येक इकाई के लिए क्रमबद्धता: ग्राहक या खाते के आधार पर विभाजन करके हम सुनिश्चित करते हैं कि किसी लेनदेन का संशोधन मूल लेनदेन के बाद प्रोसेस हो, भले ही प्रति सेकंड दस हज़ार इवेंट आ रहे हों।

लागत के लिहाज़ से AKS हमें काम की मात्रा के अनुसार बढ़ने-घटने वाली कंप्यूट क्षमता देता है — महीने के अंत, साल के अंत और FX की अस्थिरता से आने वाले उछाल के लिए स्थायी क्षमता आरक्षित करने की ज़रूरत नहीं होती।

आर्किटेक्चर के प्रमुख दस्तावेज़ के रूप में खतरा मॉडलिंग

AML रिपोर्टिंग का वातावरण जोखिमपूर्ण है। दुर्भावनापूर्ण लोग सक्रिय रूप से सीमा से नीचे रहने, लेनदेन को छोटे हिस्सों में बाँटने या KYC डेटा को दूषित करने की कोशिश करते हैं। एक अच्छा AML प्लेटफ़ॉर्म केवल अनुपालक नहीं होता — वह विरोधियों के तरीकों से भी अवगत होता है।

इस क्षेत्र में हमारी हर आर्किटेक्चर के साथ एक स्पष्ट खतरा मॉडल होता है: हर घटक सीमा पर STRIDE, प्रत्येक भंडार पर डेटा वर्गीकरण और सेवा-से-सेवा कॉल के लिए न्यूनतम अधिकार वाली पहचान। सीक्रेट Azure Key Vault में रहते हैं; सेवा पहचान स्थिर क्रेडेंशियल के बजाय प्रबंधित पहचान का उपयोग करती हैं। संवेदनशील पेलोड — KYC दस्तावेज़, ग्राहकों की PII — व्यवसाय शाखा से जुड़ी एनवेलप कुंजियों से एन्क्रिप्ट किए जाते हैं।

नियामकीय प्रस्तुति पक्ष में प्रत्येक पेलोड पर हस्ताक्षर किए जाते हैं और हस्ताक्षर कुंजी हार्डवेयर द्वारा सुरक्षित होती है। इससे छेड़छाड़ की गई या दोबारा भेजी गई प्रस्तुति का पता केवल FINTRAC ही नहीं, हमारी अपनी ऑडिट पाइपलाइन भी लगा सकती है।

KYC और धन सेवा व्यवसायों की ऑनबोर्डिंग

AML रिपोर्टिंग का आधार है KYC। यदि KYC गलत है, तो रिपोर्ट भी गलत होंगी। हमारे द्वारा किए गए दिलचस्प तात्कालिक कार्यों में से एक है ऑनबोर्डिंग प्रक्रिया धन सेवा व्यवसायों की (MSBs) — एक ऐसी ग्राहक श्रेणी जिसमें वास्तविक जोखिम अधिक है और KYC जाँच की आवश्यकताएँ व्यापक हैं।

आर्किटेक्चर पैटर्न: एक स्क्रीनिंग पाइपलाइन जो MSB पंजीकरण, प्रतिबंध सूचियाँ और लाभकारी स्वामित्व का डेटा ग्राहक संवर्धन ग्राफ़ में लाती है; AML जाँच टीम के लिए एक तात्कालिक केस-प्रबंधन UI; और एक ऑडिट ट्रेल जो हर ऑनबोर्डिंग निर्णय को उसके समर्थक साक्ष्य से जोड़ता है। यह तात्कालिक समाधान रणनीतिक ग्राहक हब के तैयार होने तक समय देता है — लेकिन इसके आउटपुट का स्वरूप समान रहता है, इसलिए रणनीतिक प्लेटफ़ॉर्म को डेटा बिना दोबारा काम किए मिल जाता है।

दो Tier-1 बैंकों में इसे लागू करने से मिली सीख

• नियामक की स्कीमा को अनुबंध मानें। पहले दिन से उसी के अनुसार बनाएँ। आंतरिक डेटा स्वरूपों को प्रस्तुति परत में आने न दें।
• डेटा जोड़ना ही मुख्य काम है। EFTR/STR नियम आसान हिस्सा हैं। ग्राहक, खाता, FX और साइबर डेटा के 30 उपयोग परिदृश्यों को सही तरीके से जोड़ने में 80% इंजीनियरिंग लगती है।
• डेटा वंशावली अनिवार्य है। जब नियामक किसी प्रस्तुति पर सवाल उठाए, तो आपको उसमें योगदान देने वाला प्रत्येक इवेंट मिनटों में दिखाना चाहिए — दिनों में नहीं।
• आर्किटेक्चर समीक्षा बोर्ड की मंज़ूरी केवल औपचारिकता नहीं है। इसे आवश्यक जाँच सुनिश्चित करने का साधन बनाएँ। जिन समीक्षाओं से हम गुज़रे, उनमें डेटा रेज़िडेंसी और कुंजी प्रबंधन की ऐसी समस्याएँ पकड़ी गईं जिन्हें बाद में ठीक करना बहुत महँगा पड़ता।
• क्लाउड-नेटिव ≠ केवल क्लाउड। कुछ अपस्ट्रीम सिस्टम वर्षों तक स्थानीय परिसर में रहेंगे। आर्किटेक्चर को हाइब्रिड एकीकरण की वास्तविकता स्वीकार करनी होगी।

क्या आपके बैंक या फिनटेक को इसकी ज़रूरत है?

SEYSO ने कनाडा और अमेरिका के कई Tier-1 बैंकों में AML और नियामकीय रिपोर्टिंग प्लेटफ़ॉर्म की आर्किटेक्चर तैयार की है — LCTR, EFTR, STR, UTR, CTR, KYC और CFT दायित्वों को शामिल करते हुए। यदि आप वित्तीय अपराध संबंधी तकनीक का आधुनिकीकरण कर रहे हैं, Actimize को नए प्लेटफ़ॉर्म पर ले जा रहे हैं या नए नियामकीय कार्यक्रम का दायरा तय कर रहे हैं, तो हम आपसे बात करना चाहेंगे। नियामकीय दायित्व और उलझे हुए स्रोत सिस्टम आप लाएँ; आर्किटेक्चर हम लाएँगे।