An Unauthenticated API, 1.2 Lakh Borrowers, and an LSP-Controlled Pool Account
A bank's digital lending product is sourced through a lending service provider (LSP). The LSP's mobile app calls the bank's API using a static key embedded in the app. A security researcher reports an endpoint that returns, without authentication, customer name, PAN, masked Aadhaar, loan amount and bank account number for about 1.2 lakh borrowers; a sample of 200 records is verified as genuine. The LSP says the endpoint belongs to the bank; the bank says it belongs to the LSP. The contract names no data controller or processor, has no audit rights, no data-localisation clause and no breach-notification obligation. Loan disbursements currently credit an LSP-controlled pool account, and EMIs are collected into the same account. Discovery was 14 hours ago and the LSP has taken the endpoint down. The board asks whether the bank must report, to whom, and whether the lending arrangement itself is compliant.
1. Assess the compliance position of the funds flow and the data handling, and state what must change.
Read the worked answer
Funds flow - non-compliant as described. Under RBI's digital-lending framework, the loan must be disbursed directly into the borrower's bank account, and repayment must be collected into the borrower's account and then routed to the lender's account; the LSP must never hold or pool customer funds. An LSP-controlled pool account used both for disbursal and EMI collection is a pass-through arrangement, and the bank cannot cure it by labelling the LSP a 'service provider' - the bank remains accountable for the conduct of the LSP, including the digital lending app.
Data handling - non-compliant on three counts. (i) Ownership and consent: with no controller/processor designation, nobody is answerable for 1.2 lakh records; consent for the specified data items and the privacy notice must sit with the bank, not the LSP. (ii) Localisation: personal data must be stored in India. (iii) Access control: a static API key shipped inside a mobile app, on an endpoint that returns PAN and account numbers without per-user authorisation, fails the basic requirement of authenticated, least-privilege API access. Also confirm the app does not access contacts, media or camera by default.
What must change, with dates. Immediately: revoke the static key, move to short-lived tokens with per-user authorisation and rate limiting, and inventory every endpoint the app can reach. Within 30 days: a tripartite agreement naming the bank as data fiduciary, granting audit and inspection rights, mandating India-only storage, imposing a breach-notification SLA in hours and requiring a deletion certificate at exit. Within 90 days: migrate disbursal and repayment to direct account-to-account flows. Until then, suspend new onboarding through this LSP - onboarding more borrowers while the flow is non-compliant compounds the breach.
2. Set out the breach-response obligations and timeline, and state what each audience must be told.
Read the worked answer
The clock started at discovery - 14 hours are already gone. (1) CERT-In: report within 6 hours in the prescribed format, covering the nature of the breach, the endpoint, the data fields exposed and containment status. (2) RBI: report under the cyber-incident reporting requirement; a personal-data breach at a lending partner is a supervisory event, not a vendor matter. (3) Data-protection law: under the DPDP Act, 2023, a personal data breach must be intimated to the Data Protection Board and to affected data principals; the bank, as the entity deciding the purpose of processing, cannot push this to the LSP. (4) Affected customers: a factual advisory stating what was exposed (name, PAN, masked Aadhaar, loan amount, account number), what was not (no passwords, no full Aadhaar), and what to watch for - loan-offer phishing, PAN-based impersonation, KYC-update calls.
Investigate in parallel. Treat the endpoint as an authorisation flaw: pull access logs to establish how many requests came from which addresses over what period, test whether the 200 sample records are a slice of the full 1.2 lakh, look for other unauthenticated endpoints, and preserve logs before the LSP's retention lapses.
Judgement point. 'The LSP took it down' is containment, not compliance. Every report above must come from the bank, on time, with the bank's own scope assessment. The ambiguity about who owns the endpoint is itself the finding: it proves the outsourcing arrangement was never risk-assessed.
3. The board asks whether to terminate the LSP. Set out the decision framework and a 30-day action plan.
Read the worked answer
Reframe the question. It is not 'terminate or continue' but 'continue on what terms'. Immediate termination would strand 1.2 lakh borrowers mid-loan with repayments flowing into a pool account - a worse outcome than controlled remediation. The test is whether the LSP can meet three conditions within 30 days: (a) an independent, CERT-In-empanelled audit of its systems and API estate, shared in full with the bank; (b) a re-papered agreement - bank as data fiduciary, India-only storage, audit and inspection rights, breach notification in hours, indemnity for regulatory penalties, and data deletion/portability at exit; (c) migration of disbursal and collection out of the pool account to direct account-to-account flows.
30-day plan. Week 1: halt new onboarding, freeze new API credentials, serve a preserve-evidence notice, and obtain the LSP's written incident report. Week 2: scope and appoint the forensic audit; take a legal opinion on fiduciary and processor roles. Week 3: renegotiate, or serve notice with a cure period; prepare customer communications and a complaint-handling script for affected borrowers. Week 4: board note with a go/no-go recommendation and a named exit route - data escrow, borrower migration plan, sunset date.
Governance lesson for the board. The failure was the outsourcing lifecycle, not the vendor's ethics: no due diligence, no audit rights, no breach SLA, no localisation clause. A replacement vendor will fail identically unless the bank builds a vendor-risk template containing those four clauses and a tiering rule placing any vendor that touches customer PAN on the highest tier, with annual on-site review.