Open Banking in India: IIBF Digital Banking Exam Guide

Open banking in India is a consent-led model in which a customer, not the bank, decides who may see their financial data and for how long. It is built on regulated rails — the RBI-licensed Account Aggregator for data, a common credit-API layer for lending, and the bank's own published APIs for products and servicing.

For IIBF candidates, the paper rarely asks "what is an API". It asks who is accountable when a partner mis-sells, which entity may store data, and what a consent artefact must contain. This guide covers the framework the way the examiner tests it.

🏦 What Open Banking in India Actually Means

Open banking is not a single product or a single regulation. It is an architecture in which a regulated entity exposes data and functionality through secure, standardised interfaces so that a third party can build a service on top of it — always with the customer's permission and always with the bank remaining answerable to the regulator.

Three layers matter. The data layer lets a customer share statements, holdings and repayment history. The transaction layer lets a partner initiate payments or mandates. The product layer lets a partner originate a deposit, a card or a loan that ultimately sits on a licensed balance sheet.

India took a deliberately different route from the United Kingdom or the European Union. There is no single "open banking mandate" forcing every bank to publish a fixed API list. Instead the country built public digital infrastructure — identity, payments and consent — and let market participants plug into it. That is why the exam framing is always regulatory rather than technical.

The practical consequence for a branch banker is simple. A partner application may sit in front of the customer, but the deposit, the loan and the grievance all belong to the bank. Every syllabus treatment of developments in digital technology and business returns to that single point of accountability, and so do most case-style questions.

💡 Exam Tip: When a question names a fintech, a platform or an app, first ask "who holds the licence?" The regulated entity is almost always the correct answer for accountability, grievance redress and data protection.

🔐 The Consent Layer: Account Aggregators and DEPA

The data spine of open banking in India is the Account Aggregator (AA), an NBFC licensed by the Reserve Bank under its 2016 Non-Banking Financial Company – Account Aggregator Directions. The AA is deliberately data-blind: it moves encrypted data from a provider to a user and can neither read nor store the contents.

Three roles must be memorised. A Financial Information Provider (FIP) holds the data — a bank, an NBFC, an insurer, a depository or a pension repository. A Financial Information User (FIU) consumes it for a stated purpose, typically underwriting or advice. The AA sits between them and manages nothing but consent.

That consent is not a tick-box. Under the Data Empowerment and Protection Architecture (DEPA), it is a machine-readable consent artefact that records the identity of the requester, the purpose, the exact data types, the frequency and validity period, and the customer's right to revoke at any moment. Purpose limitation is the examinable idea: data pulled for a loan assessment may not be recycled for cross-selling.

The Digital Personal Data Protection Act, 2023 reinforces the same direction of travel — notice, purpose limitation, and the right to withdraw. Candidates should be able to distinguish the RBI's sectoral consent architecture from the general data-protection statute rather than treat them as one rule.

Revocation is the trap. Once consent is withdrawn, further pulls must stop, but data already lawfully received and used in a sanctioned credit decision does not disappear from the lender's records. Say that precisely in a descriptive answer.

🔌 Credit Rails, Payment Rails and the Bank's Own APIs

Above the consent layer sits the credit-API layer, usually discussed under the open credit stack. Its purpose is to let a small borrower — a kirana shop, a gig worker, a farmer — receive a small, short-tenor loan through a platform they already use, while the underwriting and the balance sheet stay with a licensed lender. The APIs standardise the loan request, the offer, the disbursal instruction and the collection schedule.

The payment rails are the part every banker already touches daily. Instant retail transfers, mandates and collect requests are all API-driven, and the chapter on developments in payment systems in India is the standard reference for how these systems interlock with settlement. Where a question involves a policy rate or a charge that changes periodically, check the current position on the RBI rates and limits page rather than trusting a printed figure.

The third rail is the bank's own API estate — balance enquiry, account opening, card controls, standing instructions — exposed to partners under contract. This is where banking-as-a-service arrangements live, and where supervisory attention is heaviest, because a thin partner interface can hide a very large book.

Security is not a footnote here. Token-based authentication, mutual TLS, rate limiting and disciplined certificate handling decide whether an open API is an asset or an incident. The IT-security treatment of cryptographic key management in banks is the natural companion reading, because open banking multiplies the number of keys, tokens and endpoints a bank must control.

📊 Comparing the Building Blocks Side by Side

Examiners like a matching question: given a description, name the layer. The table below separates the three core blocks by what actually moves across them, who carries the licence, and whether a formal, revocable consent artefact is required before anything can flow.

Read the last column carefully. A payment instruction authorises one movement of money; a consent artefact authorises a stream of information. Candidates who blur the two lose marks on exactly the questions that look easiest.

The same distinction explains why a lender may not treat an aggregator pull as a marketing list, and why the design of marketing of digital banking products has to respect purpose limitation from the first screen onwards.

Pair the table with the wider syllabus. The class notes on developments in digital technology supply the vocabulary, the currency-side reading on wholesale CBDC in India shows how the same consent-and-accountability logic extends to settlement innovation, and further explainers for this paper sit under the digital banking tag hub.

⚖️ Regulation, Risk and the Bank's Non-Delegable Duties

Open banking widens the perimeter, so supervisory expectations tighten around four themes: accountability, disclosure, data handling and grievance redress. Every one of them appears in past papers as a short note or a case question.

Accountability. Outsourcing an activity never outsources the responsibility. If a partner application originates a loan, the regulated entity owns the conduct, the recovery practice and the customer complaint.

Disclosure. The borrower must know who the actual lender is before agreeing to anything, and must receive a standardised statement of cost, tenor, penalties and cooling-off terms. The requirements set out in the RBI digital lending guidelines are the reference point, including the principle that loan flows move directly between the borrower and the regulated entity without resting in a partner's pool account.

Data handling. Partner applications should collect only what the service needs, store data in India as required, and avoid harvesting contacts, media or location without a defensible purpose.

Grievance redress. A digitally originated complaint follows the same escalation path as a branch complaint, and an unresolved case can travel to the RBI Ombudsman. Since 1 July 2026 the RB-IOS 2026 scheme applies, with a ninety-day filing window from the bank's reply, an award ceiling of Rs 30 lakh and up to Rs 3 lakh for consequential loss.

For primary text on any of these, go to the source rather than a summary — master directions and circulars are published on the Reserve Bank of India website, and the wording there is what the examiner paraphrases.

⚠️ Common Mistake: Writing that the Account Aggregator "stores" customer data. It does not. It transports encrypted data on consent and is barred from reading or retaining the payload — a one-word error that costs the whole mark.

🧠 Practice MCQs: Open Banking in India

Want chapter-wise mock tests with 100+ MCQs? Start practising free →

❓ Frequently Asked Questions

🎯 Key Takeaway Before Your Exam

Open banking rewards candidates who think in terms of licence, consent and accountability rather than technology. Learn the three roles, the contents of a consent artefact and the non-delegable duties of the regulated entity, and most questions on this topic answer themselves.

Carry four phrases into the hall — data-blind aggregator, purpose-limited consent, non-delegable accountability, direct borrower flows — and structure every descriptive answer as entity, consent basis, accountable party, redress route.

Test the recall while it is fresh: attempt a free chapter-wise mock test and check whether you can name the accountable party in every scenario without hesitating.