CFOs and risk teams at GCC banks deciding between in-house development and vendor-built ECL tools. What actually gets you to compliance faster and at lower cost.

✓ Written by Prima Consulting’s advisory team · ✓ Serving GCC, Europe & APAC · ✓ Actuaries + CPAs + CFAs

The Decision Most GCC Banks Get Wrong on IFRS 9

Choosing IFRS 9 ECL software for banks is one of the highest-stakes technology calls a GCC institution makes, and SAMA’s tightening scrutiny has raised the cost of getting it wrong. SAMA increased its review of ECL models across Saudi banks through 2024 and 2025, with specific focus on staging documentation and macroeconomic overlay methodology. In the UAE, the CBUAE’s five-year prudential filter on IFRS 9 capital add-backs expired at end-2024. Full provisioning impact now hits balance sheets directly. There’s no buffer left.

So here’s the question your board is probably asking: do you build your own IFRS 9 ECL software or buy a vendor solution? The answer is rarely clean, but most banks get it wrong by fixating on the wrong variable. They optimise for customisation when they should be optimising for auditability. Or they rush to a vendor without checking whether the model logic can survive a SAMA review.

This article cuts through both. You’ll get a clear framework, a decision checklist, and a realistic cost comparison so you don’t spend the next 18 months building something you should’ve bought. Or paying for a black-box ECL tool your auditors can’t interrogate.

What IFRS 9 ECL Software Actually Does

Start with the entity, because the term gets thrown around loosely. IFRS 9 ECL software is the system that calculates expected credit loss under the standard and produces the provision numbers that land in your financial statements. It handles three-stage classification, SICR triggers, PD/LGD/EAD calculation, probability-weighted macro scenarios, and the audit trail a regulator can follow from a single facility up to portfolio disclosure.

Here’s the part that trips people up. An ECL engine is not the same thing as a reserving system, and it’s not your core banking module with a new report bolted on. Those produce numbers. They don’t produce a defensible audit-ready ECL model with documented staging logic and reproducible inputs. That gap is exactly what auditors flag.

So when you evaluate build or buy, you’re really asking one thing: which route gives me numbers I can defend in an examination? Hold that question. Everything below answers it.

Why This Decision Is Harder Than It Looks

You might think building in-house gives you full control. It does. But control is expensive when your quant team spends 60% of its time on data pipeline maintenance instead of actual credit modelling. That’s what happens inside the first two years at most banks that try to self-build.

Demand for IFRS 9 compliance software isn’t growing because banks suddenly love buying software. It’s growing because the alternative, building and maintaining a multi-stage ECL system from scratch, turns out to cost far more than anyone models at the start.

That said, “buy” isn’t automatically better. Plenty of vendor platforms work beautifully in European banking and then struggle with Islamic finance products, SICR thresholds set by SAMA, or the oil-price sensitivity required in UAE macro overlays. Those gaps don’t show up in the demo.

What SAMA and CBUAE Actually Require

Before you evaluate any tool, understand what GCC regulators need from your IFRS 9 system. SAMA requires at minimum a base-case, optimistic, and pessimistic ECL scenario, probability-weighted, applied consistently across retail, SME, and corporate portfolios. The CBUAE’s 2023 circulars doubled down on model validation, requiring independent validation functions and documented back-testing of staging allocation. Qatar, Oman, Kuwait, and Bahrain have followed a similar track.

What this means in practice: your ECL tool can’t be a black box. Regulators want to trace a provision figure from final disclosure all the way back to the input data. If your software produces a number without a clear audit trail, you’re heading for a difficult conversation with your examiner. Any system, built or bought, has to produce that trail. That’s the baseline.

The True Cost of Building IFRS 9 ECL Software In-House

Most banks that go the build route underestimate the real cost by a factor of two. They model developer salaries and server costs. They forget the six other things that break the budget.

Building takes 12 to 18 months on average before you have a production-ready system. That’s not a guess. The timeline is well documented across regional implementations. What’s less discussed is the 18 months after go-live, when your team patches integration breaks between your core banking system and the ECL engine every time either side pushes an update.

Where the Hidden Costs Live

• Model governance infrastructure: You need an independent validation function, documentation protocols, and a model risk management framework. That’s typically 2-3 additional FTEs, not just a consultant engagement.
• Data engineering: Most GCC banks have loan data spread across two or three core banking systems. Unifying it into a clean ECL input layer with proper data lineage is a serious engineering project on its own.
• Regulatory update cycles: Every time SAMA issues new staging guidance or the IASB clarifies a measurement question, someone on your team recodes the logic. That maintenance cost is permanent.
• Audit season overhead: External auditors will ask questions. Internal validation teams will ask questions. If your model documentation lives in four people’s heads and two GitHub repos, answering those questions costs time and carries real risk.

None of this makes building impossible. Large national banks with mature quant functions, think Al Rajhi, Emirates NBD, or QNB, have made it work. But they have the infrastructure to support it. A mid-market bank with 40 billion SAR in assets usually doesn’t.

What Actually Drives the Cost

People want a single number. There isn’t one, and any vendor who quotes you a tidy figure before seeing your portfolio is guessing. The cost of IFRS 9 ECL software, build or buy, moves with a handful of variables.

Portfolio complexity is the big one. A retail book with clean, homogeneous segments calibrates faster and cheaper than a mixed book stacked with Islamic finance structures, government-linked obligors, and POCI exposures. Data quality is the second. If your loan history is fragmented across systems, you pay for that in engineering time before a single ECL number comes out. Then comes the depth of model validation your regulator expects, the number of macro scenarios you run, and how much of the build your own team can carry versus what you outsource.

So the honest answer to “what does it cost” is: it depends on your portfolio, your data, and your regulator. Anyone selling you certainty on price is selling you something else.

What the Numbers Actually Look Like

What Vendor IFRS 9 ECL Software Gets Right, and Where It Falls Short

The best case for vendor IFRS 9 software is speed and audit-readiness. The strongest platforms are built on modern API-native architectures. Prima’s own RUST ECL engine, built by our technology arm IFRS TECH, is a GCC-specific example: pre-built PD term-structure tools, automated staging logic, and full drill-down from portfolio ECL to individual facility cash flows. What would take your team 14 months to build, a tested platform already handles across many implementations.

But here’s where I’d push back on the typical vendor pitch: most platforms were not designed with GCC portfolios in mind.

Islamic finance products like Murabaha, Ijarah, and Sukuk require specific adaptations to IFRS 9’s classification and measurement of financial instruments, including the business model assessment and SPPI test. Not every vendor handles them properly. Macro overlay calibration for a Saudi portfolio sensitive to oil prices and Vision 2030 construction cycles is fundamentally different from a European retail portfolio. If a vendor’s solution leans on generic macro variables and you operate under SAMA supervision, that’s a documentation problem waiting to become a regulatory one.

Five Questions to Ask Any IFRS 9 Software Vendor

1. Can you show me the full PD/LGD/EAD calculation at individual facility level, not just portfolio summary?
2. How does your system handle SICR reassignment when a borrower cures from Stage 2 back to Stage 1?
3. Does your macro overlay module support custom scenarios, for example a Saudi oil price stress?
4. What does your model validation documentation look like, and has it been reviewed by a Big 4 firm?
5. How are IFRS 9 standard updates, IASB amendments and SAMA circulars, pushed to users, and how fast?

If the vendor struggles on questions 1, 2, or 3, walk away. Those aren’t edge cases. They’re core IFRS 9 requirements.

The IFRS 9 ECL Software Features Checklist

Strip away the marketing and a credible ECL tool comes down to a short list of things it must do. Use this as your scorecard.

• Automated staging: Stage 1, 2, and 3 allocation driven by SICR triggers you can configure, not hardcoded thresholds.
• Full PD/LGD/EAD transparency: every parameter traceable to source, with EAD and LGD that can differ by stage for the same product.
• Forward-looking macro overlay: multiple weighted scenarios, with room for region-specific variables.
• Audit trail and reproducibility: rerun any prior period and get the same number. Auditors test this.
• IFRS 7 disclosures and back-testing: the reporting and validation outputs your examiner expects, not a CSV dump.

If a tool nails the first four and stumbles on disclosures, you can usually work around it. If it stumbles on staging or audit trail, it’s not really IFRS 9 ECL software. It’s a calculator.

How Prima’s RUST IFRS 9 Software Handles ECL

If you land on “buy,” here’s what a GCC-built option looks like instead of a generic European platform. RUST IFRS 9 software is Prima’s own ECL engine, built by our technology arm IFRS TECH, and it’s the example I keep coming back to because it was designed around the exact gaps the vendor section just flagged.

The short version: it automates expected credit loss end to end, and it shows its work. You get complete PD, LGD, and EAD transparency with drill-down to facility level, over 30 configurable SICR triggers for staging, multi-scenario macroeconomic overlays, and automated IFRS 7 disclosure generation. No black box. A validator can trace any provision figure back to its inputs, which is the whole game under SAMA and CBUAE.

Two things matter more than the feature list. First, speed: it’s a 90-day implementation with pre-built staging rules, and it’s API-first, so it connects to Temenos, Flexcube, Finacle, SAP, and Oracle instead of living on file exports. Banks running it report month-end close cycles cut by 40-60%. Second, control of your data: ISO 27001 certified, AES-256 encryption, and your choice of cloud or on-premise. That last point matters more in the GCC than most vendors admit.

I’ll be straight about the bias here, it’s our product, so weigh the claims against your own portfolio. But the reason it sits in a build-vs-buy article is that it answers the “buy” case without the usual GCC blind spots. You can see the full RUST IFRS 9 compliance software spec, and for the advisory side, Prima’s ECL modelling across financial and manufacturing portfolios pairs the engine with hands-on calibration.

IFRS 9 ECL Software vs Reserving and Core Banking Modules

This is the question that quietly derails procurement: do we even need separate IFRS 9 ECL software, or can our core banking system handle it? Worth answering before you spend on either path.

Core banking modules are built to run accounts, not to model credit risk under a standard. Some bolt on an impairment report. Almost none give you configurable SICR logic, weighted macro scenarios, or a validation-grade audit trail. A reserving system, meanwhile, solves a different problem entirely, it’s actuarial provisioning, common in insurance, not the staged expected-credit-loss machinery IFRS 9 demands of banks.

So the line is simple. If you need staging, SICR cure tracking, PD/LGD/EAD at facility level, and outputs a validator can interrogate, you need purpose-built ECL software. Your core system can feed it data. It can’t replace it. Banks that assume otherwise tend to find out during their first examination, which is the worst possible time.

The Case for a Hybrid Approach

You might think the choice is binary. It’s not.

A growing number of mid-market GCC banks use vendor platforms for the calculation engine and audit trail while building their own PD models on top of that infrastructure. The vendor handles the compliance plumbing: staging logic, disclosure templates, IFRS 7 reporting. The bank’s risk team owns the credit modelling assumptions. You get speed and audit-readiness from the platform, and you keep the flexibility to calibrate PD/LGD/EAD curves to your actual portfolio without being locked into someone else’s methodology.

This approach works especially well when you need to satisfy SAMA’s independent model validation requirement. Your quant team develops and owns the model; the platform documents, runs, and stores outputs in an auditable format. The validation function can review the model logic separately from the infrastructure.

Does it work for everyone? No. It needs a quant team comfortable working at the intersection of credit risk modelling and software integration. But for banks with that capability that want SAMA-defensible outputs without a two-year build, it’s often the best answer. I’ll be honest: I don’t have a clean dataset on how many GCC banks have adopted this specific model. From the engagements our advisory team runs, though, it’s becoming more common than either pure build or pure buy.

How IFRS 9 Advisory Firms Fit the Picture

Whether you build, buy, or go hybrid, there’s a point where you need outside expertise. Not because your team isn’t capable. IFRS 9 advisory firms see patterns across dozens of implementations that an internal team on its first build simply can’t.

The most common engagement we see at Prima Consulting is an independent ECL model assessment: a structured review of methodology, documentation, and regulatory alignment before an external audit. For banks that built in-house and haven’t had external eyes on the model in 18+ months, this is worth doing before your next SAMA examination, not after.

When to Build, When to Buy: A Direct Answer

Most articles hedge this. I won’t. Your choice of IFRS 9 ECL software route has real consequences for your next examination cycle.

Build in-house if: you have a mature quant team (minimum 4-5 experienced credit risk modellers), more than SAR 150 billion in assets to justify the overhead, and a portfolio with genuinely idiosyncratic characteristics no vendor platform can replicate, like complex government-linked obligors with non-standard credit history.

Buy a vendor solution if: your bank is below that scale, your first IFRS 9 model goes live within 12 months, or your existing model has documentation gaps to fix before the next regulatory review. Time to compliance is your binding constraint, and vendor platforms solve that.

Consider a hybrid if: you have strong internal credit modelling capability but want professional-grade audit documentation and regulatory governance built into your workflow. The IFRS 9 impairment calculation logic can live in your team’s models; the infrastructure around it doesn’t have to.

The wrong answer is to spend 18 months building something that fails its first independent validation review. That’s not hypothetical. It happens. And at that point you’ve spent the time and money of a build, and you still need to buy or rebuild.

The GCC-Specific Factors That Change the Calculus

If your bank operates under SAMA or CBUAE supervision, two things matter that general build-vs-buy guides won’t tell you. First: the regulatory documentation bar is higher than many banks assume when they start a self-build. SAMA’s guidance on SICR documentation quality, referenced specifically in their 2024 and 2025 examination cycles, demands detail most in-house builds don’t plan for at the architecture stage.

Second: Islamic finance product coverage is a real gap in many vendor platforms. If more than 30% of your portfolio sits in Murabaha, Ijarah, or Wakala structures, verify in writing from the vendor how their platform handles the IFRS 9 Financial Instruments classification and measurement for those products. Assume nothing.

IFRS 9 ECL Software: Make the Call With the Right Advisors

The build-or-buy question for IFRS 9 ECL software has no universal answer. But it does have a wrong one: deferring the decision until a regulatory examination forces your hand. GCC banks operate in a tighter environment than they did three years ago. SAMA examinations are more granular. The CBUAE’s prudential filter is gone. The margin for “we’re still building it” has shrunk hard.

What matters now is that your ECL tool, built or bought, produces transparent, auditable, regulator-defensible outputs. If you’re not certain yours does, that’s worth examining before your next quarter close, not after.

Prima Consulting’s advisory team works with banks across Saudi Arabia, UAE, Kuwait, and Pakistan on IFRS 9 model development, ECL modelling, and independent model validation. First conversation is always free. No pitch. Just a direct read on where you stand.

Frequently Asked Questions

What is IFRS 9 ECL software and what does it do for banks?

IFRS 9 ECL software automates the expected credit loss calculation banks must perform under the standard. It replaces manual Excel-based ECL workbooks, handling PD/LGD/EAD modelling, three-stage classification, macroeconomic scenario weighting, and the audit documentation regulators require. Good ECL tools connect directly to core banking systems and produce provision figures at both facility and portfolio level.

How long does IFRS 9 ECL software implementation take in GCC banks?

Vendor-based IFRS 9 ECL software typically takes 60-90 days to implement when the bank has clean loan data. Building in-house runs 12-18 months on average before a production-ready system goes live. GCC banks with Islamic finance portfolios should add 30-60 days for product-specific calibration whichever route they take.

How much does IFRS 9 ECL software cost for a mid-size bank?

There’s no single figure. The cost depends on portfolio complexity, the state of your loan data, how many macro scenarios you run, and the depth of model validation your regulator expects. A clean retail book costs far less to model than a mixed portfolio carrying Islamic finance structures and government-linked exposures. Treat any quote given before a portfolio review as a rough guess.

What is the best IFRS 9 ECL software for GCC and Middle East banks?

The best fit depends on Islamic finance product coverage, SAMA/CBUAE macro-scenario flexibility, and audit-trail depth, not a feature-count comparison. A platform that handles Murabaha and Ijarah correctly and produces a validator-ready audit trail will serve a GCC bank better than a feature-rich tool built for European retail. Verify those three things against your own portfolio before deciding.

Does IFRS 9 credit modelling software need to support Islamic finance products?

Yes, if your portfolio includes Murabaha, Ijarah, Wakala, or Sukuk instruments. IFRS 9’s business model assessment and SPPI test require specific treatment for Islamic finance structures that differs from conventional loan accounting. Not all vendor ECL tools handle this natively, so verify it before any commitment.

What are the SAMA requirements for IFRS 9 ECL model validation?

SAMA requires banks to maintain at least three probability-weighted ECL scenarios (base, optimistic, pessimistic), run independent model validation, and document SICR criteria and staging decisions at exposure level. The 2024 and 2025 examination cycles focused specifically on macroeconomic overlay robustness and SICR documentation quality.

Can an IFRS 9 advisory firm help us choose between building and buying?

Yes. An experienced IFRS 9 advisory firm brings cross-bank pattern recognition an internal team on its first ECL model can’t replicate. They can run a rapid assessment of your data readiness, model governance gaps, and regulatory risk before you commit to either path, usually in two to three weeks, not months.