ECL Software for Banks in 2026: What Late Adopters Are Risking

An ECL engine is software that calculates Expected Credit Loss using credit-risk data, models, staging rules and forward-looking economic scenarios. It works alongside the core banking system, using loan and borrower data to perform credit-loss calculations and produce risk and financial outputs.

Expected Credit Loss is becoming one of the most important software problems in banking.

Banks have always had to estimate how much money they may lose from loans. What is changing is how that estimate is made.

Under IFRS 9, banks must look forward, not only backward. They need to consider Probability of Default, Loss Given Default, Exposure at Default, credit risk migration, macroeconomic conditions and different economic scenarios.

That turns ECL from an accounting calculation into a data and technology problem.

For banks that still depend on spreadsheets, disconnected systems or manual provisioning workflows, the risk is no longer just compliance. It is speed. It is data quality. It is auditability.

And eventually, it is the cost of being behind banks that can calculate and understand credit risk faster.

Bangladesh is now moving directly into this transition.

Bangladesh Bank's roadmap requires banks to move from the existing rule-based approach toward ECL-based loan classification and provisioning under IFRS 9, with full implementation targeted for 2027.

The question is no longer whether banks need ECL. The question is whether their ECL infrastructure will be ready before the numbers start mattering.

• IFRS 9 became effective globally in 2018, replacing the incurred-loss approach with a forward-looking ECL model.
• Bangladesh Bank's roadmap requires an ECL pilot covering at least 25% of a bank's loan portfolio by September 2026, 50% by December 2026 and 75% by June 2027.
• Full ECL-based loan classification and provisioning is targeted for December 2027 on the Bangladesh Bank roadmap.
• ECL is not just a formula. It is a process: data, models, business rules, scenarios, governance, validation, reporting and an audit trail.
• Incomplete default data weakens the PD model. Inconsistent recovery data makes LGD harder to estimate. Missing restructuring history makes staging harder.
• The best time to discover an ECL data problem is during a pilot, not during an audit.

Quick notes

Expected Credit Loss (ECL)

Expected Credit Loss is the bank's estimate of how much money it expects to lose from credit exposures. Under IFRS 9, ECL is forward-looking: the bank does not simply wait for a borrower to default before recognizing a loss. It estimates possible future losses using historical data, current conditions and reasonable forecasts of future economic conditions.

A typical ECL calculation uses four major components:

• PD: Probability of Default
• LGD: Loss Given Default
• EAD: Exposure at Default
• Discounting: The time value of money

The calculation also depends on whether an exposure is in Stage 1, Stage 2 or Stage 3.

The important part is this: ECL is not just a formula. It is a process.

The bank needs reliable data, models, business rules, scenarios, governance, validation, reporting and an audit trail. That is why software matters.

What is Expected Credit Loss?

A bank lends money. Most borrowers repay. Some borrowers pay late. Some restructure their loans. Some eventually default.

The bank needs to estimate the amount it may lose from those credit exposures. That estimate is Expected Credit Loss.

Under IFRS 9, the calculation is probability-weighted and should reflect information available about past events, current conditions and future economic conditions.

This changes the mindset of credit provisioning. The old approach was more reactive. The ECL approach is more forward-looking.

A bank should be asking: What could happen to this portfolio, and what would that mean for expected losses?

That is a much bigger data problem.

Why Does a Bank Need ECL Software?

A small loan portfolio can be managed with spreadsheets. A large bank cannot comfortably run a modern ECL process that way.

Consider what the bank needs to bring together:

• Loan accounts
• Borrower information
• Outstanding balances
• Repayment history
• Days past due
• Collateral
• Recovery history
• Default history
• Restructuring information
• Credit scores
• PD models
• LGD models
• EAD assumptions
• Macroeconomic variables
• Economic scenarios
• Stage allocation
• Management overlays
• Provisioning rules

These data points may live in different systems. Core banking may hold the loan data. The credit risk system may hold risk grades. A separate database may contain recovery information. Finance may maintain provisioning reports. Risk teams may maintain statistical models.

Then someone has to bring everything together and calculate the final ECL.

That is where an ECL engine becomes important. The engine becomes the calculation layer between the bank's data and its financial reporting.

The ECL Software Problem Is Bigger Than the Calculation

It is tempting to think an ECL engine is simply: PD × LGD × EAD. It is not.

The bank also needs to decide:

• When has credit risk increased significantly?
• Which exposures belong in Stage 1?
• Which belong in Stage 2?
• Which are Stage 3?
• Which PD model applies?
• Which LGD assumption applies?
• Which macroeconomic scenarios should be used?
• How should those scenarios be weighted?
• How should collateral and recoveries affect LGD?
• How should restructuring affect staging?
• How should missing data be handled?
• How should management overlays be documented?
• Can the bank reproduce last quarter's calculation?
• Can internal audit understand how the number was produced?

These are software workflow problems as much as they are risk-model problems.

The IMF's 2026 review of IFRS 9 implementation highlights data availability, data reliability, technical expertise and legacy IT systems as major challenges for banks implementing ECL.

2027 Full implementation of ECL-based loan classification and provisioning is targeted for December 2027 on the Bangladesh Bank roadmap Bangladesh Bank, BRPD Circular Letter No. 03, January 2025

That is why an ECL engine should not be treated as a calculator. It should be treated as a credit risk infrastructure layer.

Key Numbers

What Happens If a Bank Waits?

This is where ECL becomes a technology issue. A bank can wait until the regulatory deadline. But the deadline is not when the work begins.

The bank first needs historical data. Then data cleaning. Then model development. Then validation. Then staging rules. Then scenario design. Then integration. Then testing. Then parallel runs. Then audit. Then management sign-off. Then regulatory reporting.

Each step can expose another problem. The most common problem may not even be the model. It may be the data.

A bank cannot build a reliable ECL calculation from unreliable loan history.

If default data is incomplete, the PD model becomes weaker. If recovery data is inconsistent, LGD becomes harder to estimate. If historical restructuring information is missing, staging becomes harder. If borrower-level data cannot be connected across systems, the bank may spend more time preparing data than calculating ECL.

This is why late adoption creates a form of ECL FOMO. Banks that start early have time to discover these problems while they are still fixable. Banks that start late may discover them during implementation.

What Does an ECL Engine Actually Do?

A modern ECL engine can sit between the bank's existing systems and its reporting layer. The architecture can look something like this:

The bank does not necessarily need to replace its core banking system. That is important.

An ECL engine should work with the systems the bank already has. It should ingest the relevant data, apply the bank's methodology, calculate ECL and produce traceable outputs.

Where ECL Software Saves Time

The biggest benefit is not simply faster mathematics. It is repeatability.

Imagine the bank has 2 million loan records. The bank needs to calculate ECL at every reporting period.

With a manual process, teams may spend days extracting data, cleaning spreadsheets, running calculations, checking formulas and preparing reports. An automated engine can make the process repeatable.

The same rules run against the latest data. The same model versions can be tracked. The same scenarios can be applied. The same calculation logic can be reproduced.

If the finance team asks: \u201CWhy did ECL increase this quarter?\u201D The bank should be able to answer.

Maybe Stage 2 exposures increased. Maybe PD increased. Maybe the macroeconomic scenario changed. Maybe a particular sector deteriorated. Maybe recoveries fell. Maybe a large corporate exposure moved into a higher-risk category.

Good ECL software makes those questions easier to investigate.

Why Macroeconomic Scenarios Matter

ECL is not only about what happened yesterday. It is also about what may happen tomorrow.

Banks may need to consider variables such as:

• GDP growth
• Inflation
• Interest rates
• Unemployment
• Exchange rates
• Sector performance
• Property prices

The exact variables depend on the bank and its portfolio. The bank can then create different economic scenarios. For example:

• Base case: The economy follows the expected path.
• Upside case: Economic conditions improve.
• Downside case: Economic conditions deteriorate.

The ECL calculation can then use probability-weighted outcomes.

This is one reason ECL can become difficult to manage manually. The bank is not calculating one number. It is managing a framework for calculating possible future losses under different conditions.

ECL Is Becoming a Competitive Risk Issue

There is another reason banks should care. Better credit risk infrastructure does not only help accounting. It can improve decision-making.

A bank with better risk data can understand its loan portfolio faster. It can identify deteriorating segments. It can see where Stage 2 exposures are increasing. It can monitor concentration risk. It can compare expected losses across sectors. It can test what happens under different economic scenarios.

That information can support credit strategy, portfolio management and risk appetite.

The ECL engine may start as a regulatory requirement. But it can become a risk management asset.

What Are Banks Already Doing Around the World?

Most major banking markets are no longer waiting for the idea of expected credit loss.

IFRS 9 has been in force since 2018, and the IMF notes that most advanced economies and many emerging and developing economies have already implemented IFRS 9 or are moving toward it.

The United States uses a different framework called CECL, which also requires banks to recognize expected credit losses on financial assets.

So the direction is clear. Banks are moving toward forward-looking credit loss measurement.

The software approaches differ. Some large banks build their own platforms. Some use specialist risk technology. Some use a combination of internal models, third-party systems and consulting support.

The common requirement is the same: the bank needs a reliable way to turn credit data into defensible expected-loss numbers.

Sources: IMF: IFRS 9 Implementation from the Perspective of Banking Supervisors (2026)

Bangladesh Is Now at the Important Part

Bangladesh's ECL transition makes this especially relevant.

Bangladesh Bank's roadmap requires banks to build the data foundation, prepare implementation plans, train teams, finalize automated ECL models and progressively test the framework before full implementation.

That means the conversation has moved beyond: \u201CWe will eventually need IFRS 9.\u201D It is now: \u201CCan our systems actually calculate it?\u201D

The answer depends on what is already inside the bank. Some banks will have strong data infrastructure. Some will have capable risk teams but fragmented systems. Some will still depend heavily on spreadsheets and manual workflows.

The starting point will be different. But every bank has the same clock.

What Should a Bank Do First?

Do not start by buying an ECL engine. Start by understanding the data. A practical sequence looks like this:

1. Map the loan data. Identify where borrower, facility, repayment, collateral and default information lives.
2. Check historical data. Look at missing values, inconsistent classifications and gaps in default and recovery history.
3. Define staging rules. Make the Stage 1, Stage 2 and Stage 3 logic explicit.
4. Review PD, LGD and EAD models. Identify what exists and what needs to be developed or improved.
5. Define macroeconomic scenarios. Decide what forward-looking information the bank needs.
6. Run a parallel ECL calculation. Compare the new methodology against the existing provisioning approach.
7. Automate the calculation. Remove repetitive spreadsheet work where possible.
8. Build auditability into the system. Every important result should be traceable back to the data, model, assumption and calculation.
9. Test before the deadline. Do not make the regulatory deadline the first production run.

The best time to discover an ECL data problem is during a pilot. Not during an audit.

The Banks That Start Earlier Have an Advantage

ECL implementation is often discussed as a compliance project. It should also be treated as a technology project.

The bank that starts early can test its historical data. It can find missing fields. It can compare models. It can run scenarios. It can validate staging. It can involve internal audit. It can run ECL alongside existing provisioning.

And most importantly, it can learn before the numbers become official.

The late adopter has fewer options. When the deadline gets close, every data problem becomes an implementation problem. Every implementation problem becomes a reporting problem. And every reporting problem becomes a management problem.

That is the real FOMO around ECL.

The advantage is not simply having an ECL engine. The advantage is having a working ECL process before everyone else needs one at the same time.

Banks should not wait for the ECL deadline to discover whether their data can support ECL.

Frequently Asked Questions About ECL Software

Final thought

ECL is not coming to banking. It is already here.

For banks that have already implemented IFRS 9, the focus is now on improving models, data and automation. For banks in markets moving toward ECL, the window is smaller. Bangladesh is one of those markets.

The banks that start building their ECL data, models and software infrastructure now will have time to test, learn and improve. The banks that wait may end up implementing under pressure.

And in banking, pressure is an expensive way to build a risk system.