The Nine-Month Digital Bank on a 2009 Core
Shree Janata Sahakari Bank, a 71-branch urban co-operative bank with ₹9,400 crore in deposits, runs a 2009-vintage core banking system (CBS) with no published APIs. 82% of customer-initiated transactions still happen at the counter. The board has committed to a 'digital bank inside the bank' - a mobile-first sub-brand targeting 200,000 customers under 35 - to launch before the next financial year, about nine months away. Two options are on the table: (i) a consortium vendor's cloud-native core, full replacement in 14 months at ₹48 crore; (ii) an API/middleware layer over the existing CBS, live in 5 months at ₹11 crore, but with batch-only access to deposit balances and therefore no real-time ledger. Marketing has already run a pre-launch campaign. The IT head notes the bank has no security operations centre, one DBA who understands the CBS, and no tested disaster recovery site. The regulator has asked for the outsourcing and exit-management plan.
1. Advise the board which of the two options to take. Justify the recommendation against the nine-month deadline, the bank's capability gaps, and its regulatory obligations.
Read the worked answer
Recommendation: option (ii), but scoped and conditional - not option (ii) as sold.
The reasoning turns on what actually constrains the bank. It is not features; it is capability and continuity. One CBS-literate DBA and no tested DR site mean a full core replacement with parallel runs and customer-level data migration is the largest operational risk this bank can take in a year, let alone nine months. A 14-month replacement cannot even finish before the deadline, so it fails the board's own commitment.
Middleware gets to market in five months, but the batch-only balance feed breaks the two things customers judge a digital bank on: real-time available balance and instant confirmation of UPI credits. Fix that with a real-time balance-and-limit cache synchronised to the CBS ledger, backed by a written tolerance and reconciliation policy, and by restricting the sub-brand at launch to products the batch feed can genuinely support - savings, recurring deposits, pre-approved consumer loans within cached limits. Do not put high-value IMPS or anything requiring real-time debit through the batch path.
Sequence it: DR site and managed security monitoring in months 1–6 (preconditions under either option), middleware go-live in month 5, core-replacement business case revisited in month 10 with real API-layer migration experience. Pre-consult the regulator on the CBS roadmap and file the outsourcing plan before signing.
2. The regulator asks for the outsourcing and exit-management plan for the middleware vendor and its cloud provider. What minimum contractual clauses and controls must be in place?
Read the worked answer
Anchor the plan on the principle that outsourcing transfers the activity, not the accountability - the bank remains answerable for the service and for customer data.
Clauses to insist on:
- Data stored and processed only in India, with the primary and backup sites named; no cross-border processing without written approval.
- Right to audit and to on-site inspection, including of sub-contractors, with the bank's auditor or regulator granted access.
- Prior written consent for sub-contracting, with a named list and no silent substitution.
- Security baselines as a contractual obligation, not an annexure of good intentions: MFA on all administrative access, encryption at rest and in transit, patch timelines, log retention and log handover on exit.
- Incident notification to the bank within a defined short window (not 'reasonable time'), with the bank controlling what is reported to CERT-In and RBI.
- Service levels with financial remedies, and liability that is not capped at one month's fee for data-breach or negligence.
- Exit: full data return in a machine-readable format, verified deletion, transition assistance for a defined period, and escrow of configuration.
Controls: vendor risk tiering, annual independent assurance, a named relationship owner, and a register of all who touch the CBS. RBI's 2023 Master Direction on Outsourcing of IT Services expects exactly this - due diligence before signing, continuous monitoring, and a documented exit strategy for material arrangements.
3. Marketing has pre-committed to a launch campaign. What evidence should the board demand before permitting go-live?
Read the worked answer
The board should treat the campaign date as irrelevant and ask for evidence, not assurances. Minimum pack:
- Reconciliation proof - at least 30 consecutive days of parallel running between the cache and CBS, with every mismatch explained, and the tolerance policy signed by the CFO.
- Closed VAPT - external and internal penetration test of the app, APIs and the middleware, with no open high or critical findings; retest evidence, not a plan.
- DR drill - a live failover with documented RTO/RPO actually achieved, not designed, and a rollback rehearsal.
- Detection - security monitoring actively ingesting middleware and API logs, with an alert-to-triage runbook.
- Incident runbook with clock - who calls CERT-In within 6 hours and RBI within the framework's 2–6 hour window, and who can authorise it in the CISO's absence.
- Capacity - load test at three times projected peak, including month-end salary-credit spikes.
- Customer-facing hygiene - grievance escalation path, and a tested kill switch that disables the sub-brand without taking down the CBS.
If any of 1, 2 or 3 is missing, the correct decision is a limited pilot to staff and 5,000 customers, not a public launch. Marketing cost is recoverable; a failed go-live on an untested DR site is not.