There's something worth saying plainly at the outset: most banks are probably not as prepared for April 2027 as they think they are.
The RBI's ECL mandate has been framed by consultants, peer banks, and most of the discourse in the industry as a provisioning change and a methodology upgrade — something the finance team needs to own, with maybe some help from risk. You've probably seen a few roadmaps. Maybe commissioned one. There's likely a committee that meets monthly and a policy document somewhere that's 60% done.
That framing, understandably, has led most institutions to the wrong place.
ECL, at its core, is not an accounting instruction. It is a demand that your bank produce a continuous, auditable, model-driven view of credit risk across every loan in your book. That includes probability of default for every borrower, loss given default, and exposure at default computed at scale. All of it has to be traceable, documented, and reproducible, sitting on infrastructure that doesn't exist in most mid-size banks today.
What tends to happen when a bank starts pulling on this thread is instructive. They ask for five-year historical loan-level performance data, and discover it's sitting in four different systems that were never designed to communicate with each other. They try to build a PD model and realize the data they have is either incomplete, inconsistently labeled, or structured around a loan origination logic that predates half the products in their current book. They hand the computation to a team running something — perhaps even an Excel spreadsheet — and discover, fairly quickly, that you cannot run a model validation process in a spreadsheet. Spreadsheets are not bad tools; but the thing you're trying to validate on them has nothing to do with a formula.
On paper, ECL is a set of methodology requirements. What it actually demands is a functioning data infrastructure, a model governance framework, and a computation pipeline that can run consistently and leave a full audit trail. This is an infrastructure build that could take 12 to 18 months. It cannot be delegated to a finance team, because these are not finance problems. It needs data engineers, risk modelers, IT architecture, and the governance function working together.
When a bank starts pulling on the ECL thread operationally, they tend to run into the same sequence of discoveries. First, PD models need five to seven years of loan-level performance records: payment histories, restructuring events, write-offs, and recoveries. That data exists — but is scattered across core banking systems, collection platforms, and legacy warehouses that were never designed to communicate with each other. Cleaning it into a usable form takes longer than almost anyone anticipates.
Second, the models themselves. PD, LGD, and EAD are statistical models. They need to be trained, validated against holdout data, documented to a governance standard, and reviewed on a cycle. This requires data scientists working alongside credit risk teams, within a governance framework that most mid-size banks don't currently have.
Third, the computation infrastructure. Running ECL across a portfolio with significant MFI, personal loan, or unsecured retail exposure — the segments RBI has flagged as carrying the highest incremental provisioning impact — needs to run reproducibly, at scale, at every reporting date, with full logging. That requires engineering decisions, not just analytical ones.
The banks that understood this early are already 12 months into that build. By Q3 2026, they'll be running parallel computations, stress-testing their models, and making final adjustments. The banks that are still treating ECL as a provisioning methodology exercise will hit Q3 2026 and discover the data isn't clean, the models aren't validated, and the infrastructure can't produce a consistent number across two consecutive reporting dates.
So what does doing this well actually look like?
Start with a data audit. Map where your loan-level historical data actually lives, in what format, and with what gaps. This single exercise will tell you more about your ECL readiness than any provisioning framework document.
Then separate the model build from the infrastructure build and run them in parallel. The modelling team needs the data; the infrastructure team needs the model specs. They should not be waiting on each other sequentially.
Build the audit trail from day one, not as a retrospective layer. Every computation, every input, every validation decision needs to be logged in a system that can be inspected.
And perhaps most importantly: put your CRO in the room where infrastructure decisions are being made — as an owner, not a reviewer. ECL is a risk function problem that requires engineering solutions. The governance structure should reflect that.
If you'd like to pressure-test where your bank actually stands, FINVIJ has put together a practical ECL infrastructure readiness framework covering data audit, model governance, and computation pipeline. You can request it or book a 30-minute readiness conversation via our contact page.