API banking और open banking: संपूर्ण CAIIB ITDB गाइड

API banking और open banking — ये दो ऐसी अवधारणाएँ हैं जो बताती हैं कि एक आधुनिक बैंक बंद व्यवस्था होना कैसे छोड़ता है और एक platform की तरह काम करने लगता है। CAIIB के Information Technology and Digital Banking elective में परीक्षक यह अपेक्षा रखते हैं कि आपको पता हो कि API असल में है क्या, बैंक gateway और sandbox के ज़रिए उसे सुरक्षित रूप से बाहर कैसे खोलता है, consent और authentication कैसे काम करते हैं, और भारत का Account Aggregator framework इस पूरे ढाँचे में कहाँ बैठता है। यह गाइड पूरी शृंखला को — एक REST call से लेकर corporate host-to-host file के विकल्प तक — उसी सीधी, परीक्षा-केंद्रित भाषा में समझाती है जिस पर पेपर में अंक मिलते हैं।

🔌 API Banking और Open Banking का व्यावहारिक अर्थ

API (Application Programming Interface) एक प्रकाशित अनुबंध है, जिसके सहारे एक सॉफ़्टवेयर दूसरे सॉफ़्टवेयर से एक तय, मशीन-पठनीय तरीके से कुछ माँग सकता है। API banking इसी अनुबंध का बैंक वाला पक्ष है: ग्राहक net banking में लॉगिन करने के बजाय, एक partner application बैंक के endpoint को call करती है और बदले में balance, payment status या payment confirmation प्राप्त कर लेती है। ग्राहक बैंक की स्क्रीन देखता ही नहीं — banking सुविधा partner के ऐप के भीतर ही समाहित (embedded) हो जाती है।

Open banking इसके ऊपर बैठा हुआ व्यापक नीतिगत विचार है: ग्राहक का वित्तीय data ग्राहक का ही है, और उसकी स्पष्ट सहमति (consent) से वह उसकी चुनी हुई किसी तीसरी संस्था के साथ साझा किया जा सकता है। यहाँ वह अंतर ध्यान से देखिए जो परीक्षक को बहुत पसंद है। API banking एक तकनीकी व्यवस्था है; open banking सहमति और अधिकारों की व्यवस्था है, जो स्वयं को पहुँचाने के लिए प्रायः APIs का प्रयोग करती है। कोई बैंक केवल एक corporate ग्राहक के साथ API banking चला सकता है और उसमें open banking जैसा कुछ भी न हो।

भारत ने यूरोप का mandated-access मॉडल आयात नहीं किया। इसके बजाय देश ने open finance को परतों में खड़ा किया — भुगतान के लिए UPI, और data के लिए RBI-विनियमित Account Aggregator framework — जबकि bank-to-partner APIs द्विपक्षीय अनुबंधों और outsourcing नियमों से ही नियंत्रित होते रहे। इस परतदार तस्वीर को समझना तब आसान होता है जब बुनियादी software अवधारणाएँ स्पष्ट हों, इसलिए integration पर numerical या scenario प्रश्न हल करने से पहले introduction to software अध्याय दोहरा लीजिए।

💡 परीक्षा टिप: यदि प्रश्न "API banking" और "open banking" का अंतर पूछे, तो सबसे सुरक्षित एक-पंक्ति उत्तर यह है: API banking पहुँचाने का तरीका है, open banking उस पर खड़ा consent-आधारित data-sharing मॉडल है।

🧱 REST APIs, Sandbox और API Gateway

परीक्षा में आने वाला लगभग हर banking API एक REST API होता है। REST (Representational State Transfer) एक architectural style है, कोई उत्पाद नहीं। यह HTTPS पर चलता है, हर resource को एक URL मानता है, और मानक HTTP verbs का प्रयोग करता है: पढ़ने के लिए GET, बनाने के लिए POST, बदलने के लिए PUT या PATCH, और हटाने के लिए DELETE। Data JSON में आदान-प्रदान होता है, जो पुरानी SOAP/XML शैली की तुलना में हल्का है और parse करने में आसान — यद्यपि SOAP/XML आज भी legacy interfaces में मिलता है। हर call stateless होता है — server को पिछली request याद नहीं रहती, इसलिए हर call को अपने credentials और context स्वयं साथ लाने पड़ते हैं।

Production से जुड़ने से पहले बैंक partner को एक sandbox देता है: dummy खातों और नकली (simulated) responses वाला हूबहू जैसा वातावरण। Sandbox में developer error codes, timeouts और edge cases बिना एक रुपया हिलाए जाँच सकता है। Sandbox में certification सामान्यतः production keys मिलने की पूर्व-शर्त होती है, और नियंत्रण-बिंदु का यही स्वरूप दो अंक वाले प्रश्न में पूछा जाता है।

असली core banking system के आगे खड़ा रहता है API gateway। यही एकमात्र मुख्य द्वार है और यह एक साथ कई काम करता है: caller को authenticate करता है, request के प्रारूप की जाँच करता है, rate limits और quotas लागू करता है, call को सही आंतरिक service तक पहुँचाता है, audit के लिए सब कुछ log करता है, और responses को रूपांतरित करता है। चूँकि connection gateway पर ही समाप्त हो जाता है, core banking application कभी सीधे इंटरनेट के सामने नहीं आती। Gateways बहुत हद तक routing, load balancing और protocol व्यवहार पर टिके होते हैं, इसलिए इसे networking systems अध्याय के साथ पढ़िए, और देखिए कि वही परतदार सोच बैंकों में enterprise architecture में कैसे दिखाई देती है।

🔐 OAuth 2.0, Tokens और Webhooks

Authentication इस प्रश्न का उत्तर देता है कि "call कौन कर रहा है?" और authorisation इसका कि "वह क्या-क्या कर सकता है?"। API banking और open banking दोनों में ये दोनों काम प्रायः OAuth 2.0 सँभालता है। सबसे बड़ी बात — और यही OAuth के होने का कारण है — यह है कि ग्राहक तीसरे पक्ष की application को अपना net banking password कभी नहीं देता। इसके बजाय ग्राहक को बैंक के अपने login पृष्ठ पर भेजा जाता है, वह वहीं authenticate होता है, पहुँच का एक निश्चित scope स्वीकृत करता है, और बैंक तीसरे पक्ष को एक access token जारी करता है।

यह token अल्पजीवी, scope तक सीमित और वापस लिया जा सकने वाला होता है। Scope का महत्व समझिए: "read account balance" के लिए जारी token से भुगतान आरंभ नहीं किया जा सकता। अधिक अवधि वाला refresh token application को यह सुविधा देता है कि वह ग्राहक को दोबारा login कराए बिना नया access token ले ले। जहाँ कोई मनुष्य मौजूद नहीं होता, ऐसे machine-to-machine integrations में सामान्यतः client ID और secret के साथ client-credentials flow प्रयोग होता है, जिसे प्रायः mutual TLS certificates से और मज़बूत किया जाता है ताकि दोनों पक्ष अपनी पहचान सिद्ध करें।

दो और तंत्र इस चित्र को पूरा करते हैं। Webhooks बातचीत की दिशा उलट देते हैं: partner हर कुछ सेकंड में "क्या भुगतान settle हुआ?" पूछता रहे, इसके बजाय घटना घटते ही बैंक स्वयं partner द्वारा पंजीकृत URL पर एक HTTPS callback भेज देता है। Webhooks पर हस्ताक्षर होना चाहिए — प्रायः payload पर HMAC के रूप में — ताकि प्राप्तकर्ता सिद्ध कर सके कि संदेश वास्तव में बैंक से ही आया है; और वे idempotent होने चाहिए, क्योंकि दोबारा भेजी गई delivery दो बार process नहीं होनी चाहिए। Digital certificates और message signing payload की अखंडता की रक्षा आद्योपांत करते हैं। Tokens, keys और consent records सबको सही ढंग से संग्रहीत करना और समय पर expire करना होता है, इसीलिए database management systems अध्याय दोबारा पढ़ना सार्थक है।

⚠️ आम गलती: अभ्यर्थी लिख देते हैं कि OAuth "password को encrypt करता है"। ऐसा नहीं है। OAuth password साझा करने की ज़रूरत ही समाप्त कर देता है और उसकी जगह scope तक सीमित, समय पर समाप्त होने वाला token दे देता है — transit में encryption TLS का काम है, OAuth का नहीं।

🏦 Open Banking APIs बनाम Account Aggregator Framework

यह तुलना इस विषय का सबसे अधिक परीक्षा-योग्य हिस्सा है, क्योंकि अभ्यर्थी अक्सर दोनों को एक ही मान बैठते हैं। द्विपक्षीय bank API बैंक और एक partner के बीच का व्यावसायिक करार है। Account Aggregator (AA) framework एक विनियमित, consent-आधारित data-sharing रेल है: RBI अपनी Master Direction for Account Aggregators के अंतर्गत NBFC-AAs को लाइसेंस देता है, और वे Financial Information Provider (FIP, जैसे आपका बैंक) तथा Financial Information User (FIU, जैसे कोई ऋणदाता) के बीच बैठते हैं। AA स्वयं जानबूझकर data-blind रखा गया है — वह encrypted data को केवल आगे बढ़ाता है, न उसे पढ़ता है और न संग्रहीत करता है।

यह भी याद रखिए कि AA जगत में consent granular और समयबद्ध होती है: उसमें प्रयोजन, data के प्रकार, fetch की आवृत्ति और समाप्ति तिथि सब लिखी होती है। यही बारीकी उसे थोक data dump के बजाय एक वास्तविक open-banking संरचना बनाती है। संबंधित अवसंरचना विषयों के लिए देखिए कि deployment models जोखिम की तस्वीर कैसे बदल देते हैं — बैंकों में cloud computing अपनाना।

🏢 API-आधारित Corporate Banking, Rate Limits और RBI का रुख

Corporate पक्ष पर API banking एक बहुत पुरानी आदत की जगह ले रहा है: host-to-host file exchange। पारंपरिक मॉडल में कंपनी का ERP एक batch payment file बनाता, उसे cut-off समय पर SFTP से भेजता, और status वाली return file का इंतज़ार करता। यह चलता तो था, पर धीमा और batch-बद्ध था, और हर विफलता घंटों बाद सामने आती थी। API-आधारित corporate banking इस चक्र को समेट देता है — ERP सीधे payment-initiation API को call करता है, तत्काल acknowledgement पाता है, और payment settle होते ही webhook प्राप्त कर लेता है। इसके बाद real-time balance और statement APIs treasury टीम को दिन में एक बार के बजाय लगातार सभी बैंकों की positions दिखाते रहते हैं। लेकिन यह न मान लीजिए कि files समाप्त हो गईं: अधिक मात्रा वाले bulk salary और vendor भुगतान आज भी प्रायः files के रूप में अधिक कुशल रहते हैं, और अधिकांश बड़े corporates दोनों चैनल साथ चलाते हैं।

चूँकि खुला हुआ API एक खुला हुआ attack surface भी है, नियंत्रण वैकल्पिक नहीं हैं। Rate limiting तय करता है कि कोई client प्रति सेकंड या प्रति दिन कितनी calls कर सकता है, जिससे core किसी बेकाबू loop या denial-of-service प्रयास से बचा रहता है; throttling अचानक आए उछाल को समतल करता है; quotas क्षमता का व्यावसायिक आवंटन करते हैं। इनके साथ IP whitelisting, mutual TLS, injection हमलों को रोकने के लिए payload schema validation, transit तथा rest दोनों में encryption, और हर call का पूरा audit trail जोड़िए। किसी partner को उसकी अपनी अलग tier में रखने का अर्थ है कि एक बिगड़ा हुआ client बाकी सबकी क्षमता नहीं खा सकता।

RBI का दृष्टिकोण निर्देशात्मक होने के बजाय सक्षमकारी रहा है। उसने यूरोप जैसी अनिवार्य access व्यवस्था लागू नहीं की; इसके बजाय उसने सार्वजनिक डिजिटल अवसंरचना खड़ी की, AA ecosystem को लाइसेंस दिया, नवप्रवर्तकों के लिए regulatory sandbox चलाया, और outsourcing of IT services तथा digital lending पर निर्देशों के ज़रिए जवाबदेही कड़ी की — जिनके अनुसार partner के आचरण के लिए बैंक ही उत्तरदायी रहता है और ग्राहक data केवल विनियमित संस्थाओं तक ही जाना चाहिए। इससे बनने वाले exposure जोखिम को उसी अनुशासन से मापा और प्रबंधित किया जाता है जिस अनुशासन से बैंकों में asset liability management किया जाता है। चूँकि API संबंधी मार्गदर्शन बदलता रहता है, किसी विशेष circular का उल्लेख करने से पहले नवीनतम RBI master directions से वर्तमान स्थिति अवश्य जाँच लीजिए। पूरे पाठ्यक्रम की तस्वीर के लिए Information Technology and Digital Banking elective tag hub देखिए, और device-स्तरीय integration के लिए पढ़िए banking में internet of things।

📌 याद रखें: Gateway = traffic नियंत्रण और नीति-पालन। Sandbox = सुरक्षित परीक्षण। OAuth = कौन और क्या। Webhook = बैंक का आपको वापस call करना। चार शब्द, चार अंक।

🧠 अभ्यास MCQs: API Banking और Open Banking

अध्यायवार mock tests 100+ MCQs के साथ चाहिए? मुफ़्त अभ्यास शुरू करें →

अक्सर पूछे जाने वाले प्रश्न

निष्कर्ष

API banking बैंक को call की जा सकने वाली सेवाओं के समूह में बदल देता है; open banking यह तय करता है कि ग्राहक की सहमति से उन्हें call करने की अनुमति किसे है। इस पूरी शृंखला पर पकड़ बना लीजिए — REST verbs, sandbox certification, gateway की नीति-पालन भूमिका, OAuth के scopes और tokens, हस्ताक्षरित webhooks, rate limits, और FIP–AA–FIU की भूमिकाएँ — फिर इस भाग से पेपर जो भी पूछे, आप उत्तर दे सकेंगे। पुराने नोट्स पर निर्भर रहने के बजाय RBI के नवीनतम master directions देखकर तथ्य ताज़ा रखिए। इसके बाद स्वयं को परखिए: CAIIB course पृष्ठ पर पूरा elective पढ़िए और iibf.store mock tests पर एक समयबद्ध chapter test दीजिए, ताकि यह पढ़ाई अंकों में बदल सके।

स्रोत और अतिरिक्त अध्ययन: Reserve Bank of India और Indian Institute of Banking & Finance।