बैंकिंग में Big Data Analytics: आर्किटेक्चर और उपयोग (CAIIB ITDB)
हर swipe, UPI collect request, छूटी हुई EMI, IVR कॉल और geo-tagged ATM withdrawal आपके बैंक के भीतर एक निशान छोड़ जाती है। बैंकिंग में big data analytics वह अनुशासन है जो इस डेटा-कचरे को निर्णयों में बदलता है — किसे लोन देना है, कौन-सा transaction रोकना है, कौन-सा ग्राहक छोड़कर जाने वाला है। CAIIB ITDB elective में आपसे pipeline कोड करने की अपेक्षा नहीं है; अपेक्षा यह है कि आप dimensions, architecture, analytics ladder, use cases और governance दायित्वों को परीक्षा-स्तर की सटीकता के साथ समझा सकें। यह गाइड इन पाँचों को क्रम से खोलती है।
📊 पाँच V जो बैंकिंग में Big Data Analytics को परिभाषित करते हैं
क्लासिक परिभाषा पाँच dimensions पर टिकी है। Volume यानी विशुद्ध आकार — एक मध्यम आकार का भारतीय बैंक CBS, cards, UPI, internet और mobile चैनलों पर रोज़ करोड़ों transaction records बनाता है। Velocity यानी आने की रफ़्तार: UPI और card authorisation ट्रैफ़िक एक निरंतर stream के रूप में आता है जिसे रातभर में नहीं, milliseconds में score करना होता है। अकेले retail payment rails एक बड़े बैंक में एक घंटे में उतने events भेज देते हैं जितने दो दशक पहले उसका पूरा शाखा नेटवर्क एक सप्ताह में बनाता था।
Variety यानी फ़ॉर्मैट का मिश्रण — core banking system की सुव्यवस्थित पंक्तियों के बगल में call-centre रिकॉर्डिंग, e-mail के मजमून, स्कैन किए गए लोन दस्तावेज़, chatbot logs, सोशल मीडिया mentions और geospatial निर्देशांक। Veracity यानी भरोसेमंदी: डुप्लिकेट customer ID, खाली PIN code, पुराने पते और ग़लत टाइप किए occupation फ़ील्ड — ये सब आगे चलकर models को बिगाड़ देते हैं। Value असली कसौटी है — जो डेटा कभी किसी निर्णय को नहीं बदलता, वह परिसंपत्ति नहीं, बस storage का बिल है।
परीक्षक इस भेद को पसंद करते हैं कि किसी बैंक का डेटा "big" इसलिए नहीं होता कि कोई एक स्रोत विशाल है, बल्कि इसलिए कि volume, velocity और variety एक साथ आते हैं। अकेला शाखा ledger केवल बड़ा है। वही ledger जब clickstream, call transcripts, bureau pulls और location डेटा से जुड़ जाए और लगातार ताज़ा होता रहे, तब वह सचमुच big data की समस्या बनता है।
💡 Exam Tip: यदि प्रश्न पूछे कि कौन-सा V डेटा की अनिश्चितता या भरोसेमंदी से जुड़ा है, तो उत्तर veracity है — variety नहीं। Variety फ़ॉर्मैट की बात है; veracity गुणवत्ता की।
🗄️ Structured Core Banking डेटा बनाम Unstructured कॉल और दस्तावेज़
Structured डेटा वह है जो पहले से तय schema में बैठ जाता है — खाता संख्या, IFSC, transaction राशि, value date, product code, delinquency bucket. यह core banking system की relational tables में रहता है, ACID गुणों का पालन करता है और SQL से query होता है। इसकी बुनियादी अवधारणाएँ Database Management Systems चैप्टर से दोहरा लें, क्योंकि normalisation, keys और indexing ही वे चीज़ें हैं जो CBS डेटा को विश्वसनीय पर कठोर बनाती हैं।
Unstructured डेटा का ऐसा कोई schema नहीं होता। Call-centre रिकॉर्डिंग, शिकायत e-mail, KYC दस्तावेज़ों के स्कैन, शाखा की CCTV फ़ुटेज, relationship-manager के नोट्स और सोशल पोस्ट — मिलकर ये उस सामग्री का बड़ा हिस्सा बनाते हैं जो बैंक वास्तव में रखता है। इसे primary key से index नहीं किया जा सकता, इसलिए किसी model के इस्तेमाल लायक बनने से पहले इसे speech-to-text, optical character recognition, natural language processing और embedding तकनीकों से गुज़रना पड़ता है।
इन दोनों के बीच में आता है semi-structured डेटा — JSON API payloads, XML regulatory returns, log files, SWIFT messages. ये अपनी सामग्री का वर्णन करने वाले tags तो रखते हैं, पर तय columns में नहीं बैठते। API banking और open banking के उभार ने इसे अधिकांश बैंकों में सबसे तेज़ी से बढ़ने वाली श्रेणी बना दिया है।
बैंक के लिए इसका व्यावहारिक नतीजा यह है कि कोई एक storage तकनीक सब कुछ नहीं संभाल सकती। Relational warehouse ledger को शानदार ढंग से संभालता है पर दो घंटे की audio फ़ाइल पर अटक जाता है; object store audio संभाल लेता है पर foreign key लागू नहीं कर सकता। यही बेमेल है जिसकी वजह से नीचे दिया reference architecture अस्तित्व में आता है।
🏗️ Reference Architecture: Ingestion, Data Lake, Warehouse, Hadoop और Spark
बैंकिंग में big data analytics के लिए एक व्यावहारिक architecture की चार परतें होती हैं। Ingestion डेटा खींचकर लाता है — रात में CBS और card switch से batch extracts, साथ ही UPI, ATM और internet-banking चैनलों से message broker के ज़रिए streaming feeds. Storage दो हिस्सों में बँटता है: data lake और data warehouse. Processing distributed jobs चलाता है। Consumption कारोबारी उपयोगकर्ताओं तक dashboards, scores और APIs पहुँचाता है।
Hadoop के पीछे का distributed विचार सरल है और उत्तर में साफ़ शब्दों में लिखने लायक है: टेराबाइट्स को एक ताक़तवर मशीन तक ले जाने के बजाय आप फ़ाइल को commodity nodes के cluster पर बाँट देते हैं (HDFS), fault tolerance के लिए हर block की प्रतिलिपि रखते हैं, और गणना को वहीं भेज देते हैं जहाँ block पहले से पड़ा है (MapReduce, जिसे YARN शेड्यूल करता है)। Apache Spark वही cluster विचार रखता है पर working sets को memory में रखता है और एक समृद्ध API देता है, जिससे iterative machine-learning और near-real-time streaming काम क्लासिक MapReduce से कहीं तेज़ हो जाते हैं। इसे hardware और parallelism की बुनियाद के लिए Introduction to Computing के साथ पढ़ें, और यह समझने के लिए कि वे cluster nodes वास्तव में कैसे प्रबंधित होते हैं, बैंकिंग IT infrastructure में operating systems के साथ।
| आयाम | Data Lake | Data Warehouse |
|---|---|---|
| क्या संग्रहित करता है | कच्चा डेटा, जैसा मिला वैसा | साफ़ किया, modelled, कारोबार के लिए तैयार डेटा |
| Schema कब लगता है | पढ़ते समय (on read) | लिखते समय (on write) |
| Audio, images, e-mail रखता है | ✅ हाँ | ❌ नहीं |
| Regulatory returns के लिए तुरंत उपयुक्त | ❌ curation चाहिए | ✅ हाँ |
| मुख्य उपयोगकर्ता | Data scientists, engineers | MIS, वित्त, अनुपालन, कारोबारी प्रमुख |
| Processing की शैली | Batch और stream | अधिकतर batch, निर्धारित समय पर |
Batch processing end-of-day provisioning, NPA वर्गीकरण और MIS के लिए ठीक बैठती है। Stream processing fraud scoring, limit checks और real-time offers के लिए। अधिकांश बैंक दोनों चलाते हैं — यही तथाकथित dual pipeline है — और उनका मिलान करते हैं ताकि किसी ग्राहक का real-time score और रातभर की रिपोर्ट एक-दूसरे को न काटें।
🏦 Analytics Ladder और बैंक इसे कहाँ वास्तव में इस्तेमाल करते हैं
चार पायदान, और परीक्षा आपसे इन्हें क्रम से नाम लेने की अपेक्षा करती है। Descriptive analytics बताता है "क्या हुआ" — CASA वृद्धि, शाखावार slippage, चैनल मिश्रण। Diagnostic बताता है "क्यों हुआ" — किस उत्पाद, vintage या sourcing चैनल ने slippage बढ़ाई, इसमें गहराई तक जाना। Predictive बताता है "आगे क्या होने की संभावना है" — probability of default, खरीदने की प्रवृत्ति, ग्राहक छोड़ने की आशंका। Prescriptive बताता है "अब हमें करना क्या चाहिए" — अनुशंसित limit, मूल्य या वसूली कार्रवाई, अक्सर बाध्यताओं के भीतर optimisation के साथ।
Use cases इसी ladder का अनुसरण करते हैं। नए-से-credit ग्राहकों के लिए credit scoring में alternate data — UPI inflow के पैटर्न, बिजली-पानी के भुगतान, GST filings, device और app संकेत — पतली bureau फ़ाइल की भरपाई करते हैं। Real-time fraud और anomaly detection में एक streaming model हर transaction की तुलना उसी ग्राहक की व्यवहारगत baseline से करता है: असामान्य beneficiary, असामान्य समय, असामान्य भूगोल, कोशिशों की रफ़्तार। Next-best-offer और cross-sell इंजन सबको एक ही अभियान भेजने के बजाय हर ग्राहक के लिए उत्पादों की रैंकिंग करते हैं। Churn prediction गिरते बैलेंस और बंद पड़े logins को इतनी जल्दी पकड़ लेता है कि RM हस्तक्षेप कर सके।
Collections prioritisation बकाया खातों को वसूली की संभावना के अनुसार क्रमबद्ध करता है ताकि सीमित field क्षमता उन्हीं मामलों के पीछे जाए जो जीते जा सकते हैं। AML transaction monitoring तय नियमों से आगे बढ़कर network और behavioural analytics तक जाता है, जो structuring, mule खाते और layering को STR दाखिल करने के लिए सामने लाती है। शाखा और ATM स्थल चयन geospatial डेटा — पैदल आवाजाही, प्रतिस्पर्धी घनत्व, जनसांख्यिकी — के आधार पर परिसंपत्तियाँ लगाता है। जहाँ ये निर्णय बड़े पैमाने पर लागू होते हैं, वहाँ इन्हें तेज़ी से bots को सौंपा जा रहा है; उस हस्तांतरण के लिए बैंकों में robotic process automation देखें।
⚠️ Common Mistake: उम्मीदवार fraud detection को "descriptive" कह देते हैं। पिछले महीने की धोखाधड़ियों का dashboard descriptive है; settle होने से पहले किसी live transaction को score करना predictive है, और rules-plus-model नीति के तहत उसे अपने-आप ब्लॉक कर देना prescriptive है।
🛡️ Governance, DPDP सहमति, Account Aggregator और Model Risk
ख़राब बुनियाद पर कोई model टिकता नहीं, इसलिए governance ही वह परत है जो बैंकिंग में big data analytics को बचाव-योग्य बनाती है। Data quality प्रबंधन स्रोत पर ही पूर्णता, शुद्धता और समयबद्धता के मानक तय करता है। Metadata बताता है कि किसी फ़ील्ड का अर्थ क्या है; lineage बताता है कि बोर्ड रिपोर्ट का कोई आँकड़ा कहाँ से आया और रास्ते में उस पर क्या-क्या transformation हुए। Single customer view एक ही व्यक्ति को अलग-अलग CIF नंबरों, खातों और चैनलों में जोड़कर पहचानता है — इसके बिना churn और cross-sell models सीधे-सीधे ग़लत होते हैं। रिज़र्व बैंक के IT governance, जोखिम और नियंत्रण पर Master Directions इसी data governance ढाँचे की ज़िम्मेदारी बोर्ड और वरिष्ठ प्रबंधन पर डालते हैं।
गोपनीयता के मोर्चे पर, Digital Personal Data Protection Act, 2023 बैंक को Data Fiduciary बनाता है। आपको स्पष्ट notice, बताए गए प्रयोजन के लिए वैध सहमति, purpose limitation, data minimisation, सुरक्षा उपाय, breach notification और सुधार व मिटाने के अनुरोधों को पूरा करने की क्षमता चाहिए। जिस प्रयोजन के लिए ग्राहक ने कभी सहमति दी ही नहीं, उसके लिए analytics डेटा दोबारा इस्तेमाल करना क्लासिक अनुपालन चूक है।
Account Aggregator ढाँचा, जो RBI के NBFC-AA निर्देशों के तहत चलता है, दूसरी संस्थाओं से ग्राहक-अनुमति वाला डेटा लेने का मान्य रास्ता है। AA जानबूझकर data-blind रखा गया है: यह digitally signed consent artefact के बदले Financial Information Provider और Financial Information User के बीच encrypted डेटा को आगे बढ़ाता है, और ख़ुद कुछ भी संग्रहित नहीं करता।
अंत में, model risk। विनियमित निर्णय — मंज़ूरी, अस्वीकृति, मूल्य-निर्धारण, कोई AML alert — explainable, प्रलेखित, स्वतंत्र रूप से validated, drift के लिए निगरानी में और proxy भेदभाव से मुक्त होने चाहिए। किसी model को दबाव-परिदृश्यों पर परखने का यही अनुशासन आपने भारतीय बैंकों में credit default swaps में derivative exposures पर लागू होते देखा था। संगठनात्मक स्तर पर बैंक नीति, गुणवत्ता और stewardship की ज़िम्मेदारी के लिए Chief Data Officer नियुक्त करते हैं और डेटा-साक्षर कारोबारी टीम में निवेश करते हैं — क्योंकि जिस analytics इकाई का नतीजा शाखा में कोई समझ ही नहीं पाता, वह रिपोर्ट बनाती है, मूल्य नहीं।
📌 Remember: Account aggregator उस डेटा को कभी पढ़ता नहीं जिसे वह ढोता है, और सहमति प्रयोजन-बद्ध तथा समय-बद्ध होती है। इसी एक वाक्य पर हर बार दो अंक बनते और बिगड़ते हैं।
🧠 अभ्यास MCQs: बैंकिंग में Big Data Analytics
Q1. Big data के पाँच V में से कौन-सा विशेष रूप से बैंक द्वारा एकत्र डेटा की अनिश्चितता, असंगति और भरोसेमंदी से जुड़ा है? (a) Variety (b) Velocity (c) Veracity (d) Volume
उत्तर: (c) — Veracity का संबंध डेटा की गुणवत्ता और विश्वसनीयता से है; variety का संबंध फ़ॉर्मैट के मिश्रण से।
Q2. एक बैंक कच्ची call recordings, JSON API logs और CBS extracts को बिना कोई model लगाए संग्रहित करता है और संरचना तभी तय करता है जब query चलाई जाए। इसे सबसे सही ढंग से क्या कहेंगे? (a) schema-on-write वाला data warehouse (b) schema-on-read वाला data lake (c) operational data store (d) data mart
उत्तर: (b) — कच्चे बहु-फ़ॉर्मैट डेटा को रखना और संरचना query के समय लागू करना ही data lake की परिभाषक विशेषता है, यानी schema-on-read।
Q3. Account Aggregator ढाँचे के अंतर्गत कौन-सा कथन सही है? (a) AA ग्राहक डेटा का विश्लेषण कर credit scores बनाता है (b) AA ग्राहक का वित्तीय डेटा सात साल तक रखता है (c) AA data-blind है और केवल consent artefact के बदले encrypted डेटा स्थानांतरित करता है (d) यदि FIU अनुसूचित बैंक हो तो AA बिना ग्राहक सहमति के डेटा साझा कर सकता है
उत्तर: (c) — AA एक consent intermediary है; जो डेटा वह FIP से FIU तक ले जाता है, उसे न तो पढ़ता है और न ही रखता है।
Q4. एक model बकाया खातों की रैंकिंग करता है और collections टीम को उपलब्ध field क्षमता के हिसाब से ठीक-ठीक बताता है कि किन 500 उधारकर्ताओं के पास पहले जाना है। यह analytics ladder के किस पायदान पर है? (a) Descriptive (b) Diagnostic (c) Predictive (d) Prescriptive
उत्तर: (d) — संसाधन-बाध्यताओं के भीतर कोई ठोस कार्रवाई सुझाना prescriptive analytics है; केवल वसूली की संभावना आँकना predictive होता।
Q5. बैंक के real-time fraud scoring कार्यभार के लिए क्लासिक Hadoop MapReduce की तुलना में Apache Spark को आम तौर पर वरीयता क्यों दी जाती है? (a) Spark distributed storage की ज़रूरत ही ख़त्म कर देता है (b) Spark काम का डेटा memory में process करता है और stream processing सहारा देता है, जिससे iterative jobs की latency घटती है (c) Spark पूर्ण ACID गारंटी वाला relational database है (d) Spark data governance की ज़रूरत हटा देता है
उत्तर: (b) — In-memory गणना और native streaming, iterative तथा कम-latency कार्यभारों के लिए Spark को disk-आधारित MapReduce से कहीं तेज़ बनाते हैं।
100+ MCQs वाले चैप्टरवार mock tests चाहिए? मुफ़्त अभ्यास शुरू करें →
❓ अक्सर पूछे जाने वाले प्रश्न
क्या बैंक में data lake, data warehouse का विकल्प है?
नहीं। Lake खोजबीन और model बनाने के लिए कच्चा, बहु-फ़ॉर्मैट डेटा रखता है; warehouse MIS और regulatory reporting के लिए संवारा हुआ, modelled डेटा रखता है। अधिकांश बैंक दोनों चलाते हैं, जहाँ lake से warehouse को डेटा मिलता है।
क्या DPDP Act बैंक को analytics के लिए ग्राहक डेटा इस्तेमाल करने से रोकता है?
यह analytics पर रोक नहीं लगाता। यह notice, निर्दिष्ट प्रयोजन के लिए वैध सहमति, data minimisation, सुरक्षा उपाय और सुधार व मिटाने के अधिकारों को पूरा करने की क्षमता माँगता है। चूक तब होती है जब बिना सहमति वाले प्रयोजन के लिए डेटा दोबारा इस्तेमाल कर लिया जाए।
Batch और stream processing में क्या अंतर है?
Batch एक निश्चित समय पर सीमित रिकॉर्ड-समूह को process करती है — जैसे end-of-day NPA वर्गीकरण या MIS। Stream हर event को आते ही process करती है, और real-time fraud scoring तथा limit checks के लिए यही चाहिए।
CAIIB ITDB पेपर Hadoop और Spark पर कितनी तकनीकी गहराई की अपेक्षा करता है?
अवधारणात्मक गहराई, coding नहीं। प्रतिलिपि के साथ distributed storage, गणना को डेटा तक ले जाना, in-memory processing की भूमिका, और बैंक के architecture में हर एक की जगह — इतना जानिए। संख्यात्मक या syntax वाले प्रश्न नहीं पूछे जाते।
🎯 निष्कर्ष: इस चैप्टर को अंकों में बदलें
अपनी पुनरावृत्ति उसी क्रम में करें जिस क्रम में पाठ्यक्रम चलता है: पाँच V परिभाषित करें, structured को unstructured से अलग करें, ingestion-से-consumption तक का architecture बनाएँ और उसमें lake बनाम warehouse का अंतर दिखाएँ, descriptive से prescriptive तक की ladder चढ़ें, फिर हर पायदान से एक ठोस use case जोड़ें। अंत governance से करें — गुणवत्ता, metadata, lineage, single customer view, DPDP सहमति, account aggregator, model explainability और Chief Data Officer का दायित्व। इसी क्रम में उत्तर लिखेंगे तो परीक्षक बैंकिंग में big data analytics को जिस भी तरह पूछे, आप लगभग हर रूप को कवर कर लेंगे।
इसे जुड़े हुए चैप्टरों से पक्का करें — बुनियाद के लिए Essentials of Information Technology से शुरू करें — और Information Technology and Digital Banking elective hub पर और नोट्स देखें। फिर ख़ुद को परखें: CAIIB कोर्स पेज पर पूरा mock दें और देखें कि समयबद्ध पेपर में बैंकिंग में big data analytics की आपकी याददाश्त कितनी टिकती है।
Quick quiz on this topic
5 exam-style questions from our free test bank — check yourself before you move on.
Practice this topic
मुफ़्त मॉक टेस्ट दें, चैप्टर PDF डाउनलोड करें या वीडियो क्लास देखें — सब iibf.store पर मुफ़्त है।
पढ़ना जारी रखें
