When Your Spreadsheets Fail a CBUAE Audit: The CFO's Case

Published by CodeNicely, the product studio founded by Meghal Agrawal and Ujjwal Agrawal in 2017

For: CFO or COO of a UAE-licensed financial services or trading enterprise running critical operational processes — credit exposure tracking, treasury reconciliation, or regulatory reporting — on shared Excel workbooks, who has just received a CBUAE or DFSA examination notice and realised those workbooks will not survive scrutiny

If a CBUAE or DFSA examination notice is on your desk and your credit exposure, treasury reconciliation or regulatory reporting runs through shared Excel workbooks, the honest answer is this: you will not pass by hardening the spreadsheets. The gap examiners cite is not formula accuracy — it is the absence of an immutable audit trail, enforceable maker-checker segregation, and row-level version integrity, none of which Excel can produce no matter how it is password-protected or stored on SharePoint. The budget conversation with your board therefore is not spreadsheet vs software. It is remediate a structural control gap now, in phases that pay for themselves, or absorb the enforcement, capital and headcount cost of doing nothing. This post gives you that argument in the language a CFO funds.

Why examiners fail spreadsheets (it is not what your team thinks)

Finance teams tend to defend their workbooks on accuracy. They point to reconciliation checks, locked cells, review sign-offs in email. That defence misses the regulator's actual test.

The CBUAE Operational Risk Management Regulation requires that a Licensed Financial Institution "must have in place adequate governance arrangements and internal controls to effectively manage and protect data," and must "reliably and accurately compile and analyse risk data and Operational Risk event data." The DFSA's GEN Rule 5.3.4 requires every Authorised Firm to maintain systems and controls to "identify, assess, mitigate, control and monitor its risks," with GEN 5.3.3 mandating segregation of key duties. The DFSA assesses operational risk against 11 principles adopted from the Basel Committee, including Principle 7 (a formal approval process for all new processes and systems) and Principle 8 (regular monitoring and reporting of operational risk exposures).

Read that list and ask what a shared .xlsx file on a network drive can actually prove:

• Immutable audit trail. Who changed cell F47 at 14:12 on Tuesday? Excel's track-changes is optional, local, and can be disabled or overwritten. There is no server-side log that survives a user's laptop being reimaged.
• Maker-checker enforcement. An email saying "approved" is not the same as a system that blocks the maker from being the checker. Excel cannot enforce that at all.
• Version integrity at the row level. If your Q2 liquidity report differs from Q1, examiners want to see which row changed, when, by whom, and under what approval. "We have the old file in a backup folder" is not an answer.
• Formal change control. Who approved the new VLOOKUP that now pulls from a different source tab? Principle 7 expects a documented approval process. Nobody writes a change ticket to edit a formula.

This is why the gap is structural. You cannot patch it. A SharePoint folder, a password, a macro-based audit log — none of these produce evidence an examiner accepts, because the control is still trust-based and reversible.

The cost of doing nothing, in CFO language

Boards fund modernisation when the status quo has a number attached. Here are the five numbers that belong in your paper.

1. The enforcement exposure

The reference case your audit committee needs to see is Standard Chartered's £46.55 million PRA fine in December 2021 — a record PRA-only enforcement penalty — triggered by a single spreadsheet cell error that caused the bank to over-report its U.S. dollar liquidity by $7.9 billion across five reporting periods. The fine was not for the error itself. It was for the control environment that let a single cell drive a regulatory submission without compensating controls. That is the same framework CBUAE and DFSA apply.

2. The error base rate

A 2024 literature review in Frontiers of Computer Science, synthesising 35 years of research, found that approximately 94% of spreadsheets used in business decision-making contain errors. Your workbooks are not the exception. Chartis Research has estimated roughly USD 12.1 billion in one-year end-user computing value at risk across the 50 largest financial institutions — the standard benchmark for spreadsheet-driven operational exposure. Scale it down to your balance sheet and you have a materiality number.

3. Headcount absorbed by workarounds

Walk the floor. Count the FTE-equivalent hours spent each month on: reconciling versions, chasing sign-off emails, rebuilding broken links, hand-keying numbers from one workbook into another, and recreating audit evidence after the fact for internal audit. In most mid-sized UAE financial institutions this is between two and six full-time equivalents hiding inside other job titles. At Dubai financial-services loaded salary costs, that is a line item.

4. Data quality drag

Gartner has estimated that poor data quality costs organisations an average of $12.9 million per year, with manual Excel ranking lowest among common reporting approaches on repeatability and auditability. The number itself is a benchmark, not a quote for your firm — but the direction and the mechanism (rework, restatement, misinformed decisions) are the same.

5. The scale of the problem you have not inventoried

An EUCplus poll of risk professionals found 53% of firms have no robust end-user computing policy, more than 47% use over 1,000 spreadsheets for day-to-day functioning, and 30% admit that more than 25% of those are critical to operations. If you have not run a EUC inventory, the first finding of your examination will be that you cannot tell the regulator how many critical spreadsheets you have. That alone is a Principle 7 failing.

Sequencing: strangler-fig vs big-bang, under a hard deadline

With an examination notice already in hand, the sequencing question is not academic. Both paths have a risk profile. Pick deliberately.

Big-bang replacement (buy or build)

What it is: procure or build a single system that replaces the spreadsheet-run process end-to-end — a treasury management system, a regulatory reporting platform, a credit exposure engine — and cut over on a date.

Where it works: when a credible off-the-shelf product covers 80%+ of your process with configuration (not customisation), your data is clean enough to migrate, and you have 9–18 months of runway before the examination lands on the specific process the system replaces.

What it is bad at: hitting a near-term examination date. Vendor selection, procurement, data migration and parallel-run alone typically consume two to three quarters before go-live, and that is before user acceptance. If your examination window is shorter than that, big-bang is a bet, not a plan. It also tends to surface undocumented process logic late — the "everyone knows Fatima handles the Islamic-finance exposures differently" problem — which inflates scope.

Strangler-fig increments

What it is: wrap the existing spreadsheets with a thin system of record that captures inputs, enforces maker-checker, and writes an immutable audit log — then replace the workbooks one calculation domain at a time, retiring tabs as the new system takes them over. The term comes from Martin Fowler's pattern for legacy displacement.

Where it works: when the examination deadline is tight, when the process logic is poorly documented and lives in people's heads, and when the business cannot pause operations for a cutover. The first increment — usually the audit trail and access control layer — closes the most-cited examiner finding fastest, often within a quarter, before any calculation logic is rewritten.

What it is bad at: total cost of ownership over a 5-year horizon. You will pay more in integration glue than a clean big-bang, and the intermediate state (part spreadsheet, part system) is operationally more complex while it exists. If you stop halfway through, you have made things worse.

The honest recommendation for a firm with a notice in hand

Phase one is almost always a strangler-fig: get the control gap closed on the highest-risk process before the examination, then re-plan the rest with the examiner's findings in hand. A board that funds "close the finding, then modernise the rest with the regulator's input" tends to approve faster than one asked to fund a 24-month platform programme sight-unseen.

How to phase the spend so increment one pays for increment two

Cost and timeline for this work are driven by five variables, not by a vendor price list:

1. Process scope. A single reporting workbook with three contributors is a different project from a cross-desk credit exposure estimate aggregating from twelve source systems. The number of integration points and the number of maker-checker roles are the dominant drivers.
2. Data state. If your source data is already in a core banking system or data warehouse with stable APIs, ingestion is weeks. If it lives in a mix of CSV exports, counterparty emails and PDFs, ingestion is months and probably needs a data remediation workstream before build starts.
3. Regulatory artefact requirements. How many regulatory returns does the output feed? Each one carries its own reconciliation and sign-off evidence requirements that have to be designed into the system, not bolted on.
4. Change-management load. How many users, in how many locations, on what notice period? User training and parallel-run cost scale with headcount, not system complexity.
5. Build vs buy on the calculation engine. If a credible off-the-shelf engine exists for your calculation (standard FX reconciliation, standard Basel exposure methods), buying the engine and building only the wrapper is cheaper and faster. If your calculation is bespoke — Islamic finance structures, non-standard credit exposures, firm-specific limit frameworks — build is usually unavoidable.

A phased spend model that boards tend to approve looks like this (illustrative, not a quote):

• Phase 0 — EUC inventory and risk-rank (weeks, not quarters). Catalogue every spreadsheet touching regulated outputs, score each on examiner exposure, pick the top three for Phase 1. This phase is cheap and produces the evidence the examiner will ask for first ("show me your EUC register").
• Phase 1 — Control wrapper on the highest-risk process. System of record for inputs, enforced maker-checker, immutable audit log, role-based access. Spreadsheets continue to do the calculation, but can no longer be edited outside the system. This is the increment that closes the structural finding.
• Phase 2 — Replace the calculation engine for process one. Funded in part by the headcount hours Phase 1 releases from reconciliation and sign-off chasing. Now you can retire the first set of workbooks.
• Phase 3 onward — Repeat for processes two and three, re-using the Phase 1 wrapper. The marginal cost of each additional process is lower than the first.

The two or three specifics that turn this shape into a real number are: (a) the EUC inventory output — how many critical workbooks, how interconnected; (b) the state of your source data and the APIs available on your core systems; and (c) whether the calculation engines you need exist off-the-shelf or must be built. Those are the questions to bring to a scoping conversation.

What the business has to supply

Modernisation programmes stall when the vendor is ready and the business is not. Before Phase 1 starts, the sponsor needs to have committed:

• A named process owner per workbook domain — not a steering committee, a person — with authority to sign off requirements.
• Access to the people who actually run the spreadsheet today. Not their managers. The analysts who know why the February adjustment exists.
• A written statement of which regulatory returns the process feeds and what evidence Compliance currently produces for each. If Compliance cannot articulate this in a week, that itself is the first finding.
• A parallel-run commitment. Expect to run old and new side by side for at least one full reporting cycle, and budget the double-keying hours.
• A decision on data retention. Immutable audit logs grow. Someone has to decide the retention period and the archive strategy, aligned with CBUAE record-keeping requirements.

How CodeNicely can help

The engagement that most closely mirrors this problem is our work with GimBooks, a Y Combinator-backed fintech where we built the accounting and compliance platform small businesses rely on for GST filings and audit evidence. The relevant parallel is not the end-user segment — it is what the system had to prove: every ledger entry traceable to a user and timestamp, maker-checker on sensitive postings, and the ability to reconstruct the state of the books on any past date for a tax notice. Those are the same control properties a CBUAE or DFSA examiner wants to see on your treasury or exposure process.

For UAE-licensed firms specifically, our Dubai software and digital transformation practice works on strangler-fig increments where the first deliverable is the control wrapper — audit log, role-based access, enforced segregation — on top of existing spreadsheet calculations, so the examination finding closes before the full platform is built. We work with your IP, no vendor lock-in, and the source code sits in your repository. For the broader modernisation path across legacy systems, data and automation, see our digital transformation hub.

One honest limitation: we do not sell a packaged treasury management or regulatory reporting product. If your examination finding points you to a specific off-the-shelf system that genuinely covers 80%+ of your scope with configuration alone, that is the right answer and we will tell you so. Our work is the custom layer around and between those systems — and the full build when no off-the-shelf system fits.

The one-paragraph argument for your board paper

"Our examination exposure on [process] is not a formula-accuracy problem — it is a structural control gap under CBUAE Operational Risk and DFSA GEN 5.3, which Excel cannot meet regardless of hardening. The reference enforcement case is a £46.55m fine for a single-cell error that reflected a control environment, not an arithmetic mistake. We propose a phased remediation: Phase 1 closes the audit-trail and maker-checker finding on our highest-risk workbook within [X] weeks and is the evidence we present to the examiner; Phases 2 and 3 replace the calculation engines and are part-funded by the reconciliation hours Phase 1 releases. The alternative — defending the current state — carries enforcement, capital add-on and headcount costs that exceed the modernisation spend within [X] reporting cycles." Fill in the two bracketed numbers from your scoping work, and you have the paper.

Frequently Asked Questions

Will encrypting our spreadsheets or moving them to SharePoint satisfy CBUAE?

No. Encryption and SharePoint storage address confidentiality and backup, not the controls the regulator actually tests — immutable audit trail, enforced maker-checker segregation, and row-level version integrity. The CBUAE Operational Risk Management Regulation and DFSA GEN 5.3 require the firm to demonstrate these controls to an examiner, which requires a system that cannot be bypassed, not a shared file with better access rules.

How long does it take to replace a spreadsheet-run process with proper software?

The honest answer is "it depends on five things," and the five are: how many workbooks and integration points are in scope, the state of your source data, how many regulatory returns the output feeds, how many users need re-training, and whether the calculation engine exists off-the-shelf or must be built. A strangler-fig Phase 1 that closes the control gap on a single high-risk process is typically scoped in a different order of magnitude than a full platform replacement. A scoping conversation that inventories those five variables is the only way to turn the shape into a real timeline — talk to our Dubai team to run that scoping.

Should we buy a packaged treasury or regulatory reporting system instead of building?

If a credible off-the-shelf product covers 80%+ of your process with configuration rather than customisation, buy it. The build-vs-buy decision hinges on how bespoke your calculations are — standard Basel exposure methods and FX reconciliation have mature products; firm-specific limit frameworks, Islamic finance structures and non-standard reporting usually do not. In most UAE enterprise engagements, the right answer is a packaged engine where one exists, with a custom wrapper for the integrations, controls and firm-specific logic.

What should we tell the examiner if we have started but not completed modernisation?

Examiners respond better to a documented, dated remediation plan with evidence of execution than to a defence of the current state. Phase 0 (your EUC inventory and risk-ranking) and Phase 1 (the control wrapper on the top-risk process) are specifically designed to produce that evidence. This is a point to confirm with your compliance counsel and external auditor — they will know how your specific examiner has treated similar remediation plans in recent cycles.

How do we build the business case without a vendor quote in hand?

Lead with the cost of doing nothing: enforcement exposure benchmarked to published cases, FTE hours absorbed by workarounds (count them, do not estimate), data quality drag, and the capital add-on your regulator can impose for weak operational risk controls. Then present the shape of the modernisation spend — the five cost drivers and the phased sequencing — and ask the board to fund Phase 0 (the inventory) as a discrete decision. Phase 0 produces the numbers that justify Phase 1, and so on. Boards fund visible increments more readily than 24-month platform programmes.