Selecting ECL software is not the same as buying a calculation engine. An institution needs to govern the full path from source data to a reviewed allowance, a posted journal and supported disclosures. A platform that produces a number but leaves staging, overlays, approvals and reconciliations in email and spreadsheets may automate only the middle of the problem.
Use this vendor-neutral checklist to compare solutions consistently. Score each capability from 0 to 3:
- 0 — Absent: not supported;
- 1 — Manual: possible only through offline workarounds;
- 2 — Partial: supported with limitations or configuration dependency; and
- 3 — Controlled: embedded, traceable and demonstrable in the live workflow.
1. Source-system ingestion
Can the platform ingest lending, receivables, collateral, rating, collection and macroeconomic data without repeated manual restructuring? Review supported formats, APIs, scheduled loads, incremental loads and handling of restatements.
Ask the vendor to demonstrate: loading a representative file with one missing column, one duplicate and one corrected record.
2. Data validation and exception management
The system should test completeness, format, logic, reconciliation and unusual movement. Exceptions need ownership, status, commentary and approval—not silent deletion from the population.
Ask the vendor to demonstrate: validation rules, an exception queue, remediation history and source-to-model control totals.
3. Portfolio scope and segmentation
Evaluate whether users can define in-scope instruments, portfolios and shared credit-risk characteristics with effective dates and approval. Segmentation changes should retain history and support impact analysis.
Ask the vendor to demonstrate: moving a product to a revised segment without rewriting prior-period results.
4. SICR and staging governance
The platform should support quantitative deterioration, delinquency backstops, internal ratings, qualitative indicators, restructuring, watchlists, low-credit-risk treatment where relevant, cure logic and controlled overrides.
Ask the vendor to demonstrate: one exposure moving from Stage 1 to Stage 2, the reason code, reviewer challenge and later cure.
5. Multiple measurement approaches
Different portfolios may need PD–LGD–EAD, provision matrices, loss rates, roll rates, discounted cash flows or individual assessment. Confirm that the platform does not force every asset into one method merely because that method is built into the product.
Ask the vendor to demonstrate: two portfolios using different methods within the same reporting run.
6. PD, LGD and EAD configuration
For lending portfolios, examine support for term structures, lifetime horizons, marginal or conditional PDs, recovery timing, collateral, prepayment, credit conversion factors and discounting. Configuration should be controlled and documented.
Ask the vendor to demonstrate: tracing a single account's ECL back to its approved PD, LGD, EAD and discount factors.
7. Forward-looking scenarios and non-linearity
The solution should handle multiple economic scenarios, weights, variable paths, portfolio linkages and probability-weighted results. It should allow sensitivity analysis and preserve the scenario set used at each reporting date.
Ask the vendor to demonstrate: changing a scenario weight, showing the incremental ECL and routing the change for approval.
8. Overlay and post-model adjustment governance
Look for an overlay register that captures rationale, population, calculation, supporting evidence, double-counting assessment, owner, approver and exit criteria. A free-form field attached to the final number is not enough.
Ask the vendor to demonstrate: creating, reviewing, approving and retiring an overlay.
9. Individual assessment and collateral recovery
Material or distressed exposures may require scenario-weighted recovery cash flows, collateral realisation assumptions, costs, timing and effective-interest-rate discounting. The workflow should accommodate case-specific evidence without losing control.
Ask the vendor to demonstrate: an individually assessed case with base, upside and downside recovery paths.
10. Maker-checker and role-based access
Confirm that preparation, review, approval and administration can be separated. Permissions should operate at meaningful levels—data load, model change, override, overlay, run approval and reporting—not only at an all-or-nothing user level.
Ask the vendor to demonstrate: an unauthorised user attempting to change a material assumption.
11. Versioning, lineage and audit trail
The platform should identify the data snapshot, model, parameters, scenarios, adjustments and approvals behind every final run. Audit logs should be exportable, readable and protected from ordinary user alteration.
Ask the vendor to demonstrate: reproducing a prior-period account result and explaining every subsequent change.
12. Reconciliations and movement analysis
Review support for source-to-model, model-to-ledger and period-on-period reconciliation. A useful movement bridge separates volume, repayment, stage transfer, model, scenario, overlay, write-off and other effects.
Ask the vendor to demonstrate: explaining a portfolio-level allowance increase from the prior quarter.
13. Reporting and disclosure support
The platform should produce account-level detail, portfolio summaries, stage tables, allowance movements, assumption reports, sensitivities and disclosure-support schedules. Reports should use approved data rather than separate manual extracts.
Ask the vendor to demonstrate: tracing a disclosure number back to the approved run and underlying accounts.
14. Integration, security and resilience
Assess API capability, identity management, encryption, backup, recovery, hosting options, monitoring and vulnerability management. Confirm data residency and subcontractor arrangements where they matter to policy or regulation.
Ask the vendor to provide: architecture diagrams, security documentation, recovery objectives, incident process and recent assurance reports where available.
15. Implementation, ownership and exit capability
Software succeeds only when methodology, data, roles and operating procedures are implemented with it. Clarify configuration ownership, model validation responsibilities, training, support, upgrade testing, data export and contract-exit arrangements.
Ask the vendor to provide: a phased implementation plan with accountable client and vendor owners, acceptance criteria and exit deliverables.
Suggested weighted scorecard
| Evaluation area | Suggested weight |
|---|---|
| Methodology and staging | 25% |
| Data and integration | 20% |
| Governance and auditability | 20% |
| Reporting and reconciliation | 15% |
| Security and resilience | 10% |
| Implementation and support | 10% |
Weights should reflect the institution's portfolio and risk profile. For example, a high-volume digital lender may place more weight on ingestion and scalability, while a smaller NBFC with material judgement may prioritise individual assessment and workflow.
Red flags during a demonstration
Treat the following as warning signs:
- the demo shows only dashboards, not an account-level trace;
- all exceptions are resolved outside the platform;
- prior-period results cannot be reproduced easily;
- model or assumption changes overwrite history;
- maker-checker approval is simulated through email;
- overlays are typed directly into the final result;
- reconciliation and disclosure packs require uncontrolled exports; or
- data cannot be exported in a usable form when the contract ends.
Frequently asked questions
Should an institution choose software before finalising methodology?
Usually no. At minimum, the institution should understand portfolio scope, measurement routes, staging principles, data sources and governance requirements. Otherwise, product constraints can start dictating accounting policy.
Does ECL software remove the need for model validation?
No. The platform can improve repeatability and evidence, but methodology, model performance and material assumptions still require appropriate validation and monitoring.
Is a proof of concept necessary?
For material portfolios, a representative proof of concept is highly valuable. Use masked or controlled sample data that includes exceptions, stage changes, overlays and reconciliation—not only clean records designed for the demo.
Compare the workflow, not only the calculation
Explore the RVSBELL Analytics Ind AS 109 ECL platform or request a platform walkthrough built around your own portfolio and review questions.
Technical references
- IFRS Foundation, IFRS 9 supporting materials
- IAASB, Auditing Accounting Estimates—ISA 540 (Revised)