In most UAE banks, regulatory reporting is understood as something that happens at the end of a quarter. There is a reporting team, a window, a submission, and a sense of relief when it is filed. That framing is the reason so many banks carry reporting risk they cannot see: by the time the return is being assembled, its integrity has already been decided. The figure in a CBUAE return is the last visible step of a chain that started months earlier, in transaction systems, data movement, and aggregation the report only inherits. The reporting team does not create the integrity of the number. It discovers what the rest of the year already determined.
This piece is a perspective on why CBUAE reporting integrity is set upstream of the report, and why treating reporting as a quarter-end activity misplaces the risk. The argument is opinionated. We are not arguing that reporting teams are weak or that deadlines do not matter. We are arguing that the correctness and, more importantly, the defensibility of a regulatory figure are properties of its origin, its movement between systems, and its aggregation, none of which the reporting window can repair; that the visible production step absorbs effort it cannot convert into integrity; and that the supervisory exposure a bank carries is inherited from upstream stages that could not show their working. Reporting is not where integrity is made. It is where the absence of it becomes visible.
The audience for this analysis is heads of regulatory reporting, finance and risk data leads, CROs, and CFOs at UAE banks who meet their CBUAE windows and still feel exposed when a figure is questioned. The useful diagnostic question is not "did we submit on time" but "for any figure in the last return, can we show where it originated, how it moved, and how it was aggregated, without reconstructing it".
The Chain a Figure Travels Before It Is Reported
Below is the path a reportable number actually takes, from the transaction system that creates it to the supervisory exposure that follows submission. The point is not that any one stage is uniquely hard; it is that integrity is set in the first three stages, which run all quarter and are largely uninstrumented for reporting, while effort concentrates in the fourth, which cannot create what the earlier stages did not. Tap any stage to see what it sets, where integrity breaks, and what instrumenting it changes.
From transaction to supervised return: where integrity is decided
Tap a stage for what it sets, where integrity breaks, and what changes
Why Integrity Cannot Be Added at the End
The reason the reporting window cannot create integrity is that integrity is a statement about a figure's history, not its formatting. A regulator does not only ask whether a number is correct; it asks the bank to demonstrate how the number was produced. A figure that is numerically plausible but cannot be traced from origin through every transformation to the return is, for supervisory purposes, an unproven figure. That traceability is built, or not built, in the source systems and the data movement that happen all quarter. The reporting team inherits whatever history exists and can only present it; it cannot retroactively give a number a documented past it never had.
The CBUAE framework makes this concrete in two ways. First, the windows are fixed and unforgiving: audited financial statements no less than three weeks before the AGM and published within four months of year-end, BRF95 within four weeks of quarter-end, and quarterly Pillar 3 within six weeks where no interim financial statements are published. A bank reconstructing data integrity inside those windows is doing the hardest possible work at the worst possible time. Second, the consequence is severe and explicit: under Federal Decree-Law No. (6) of 2025 the administrative fine ceiling on a violating licensed financial institution is up to AED 1,000,000,000, and in 2024 the CBUAE took enforcement action against eleven banks, six of them in connection with weak or absent AML/CFT and sanctions-compliance frameworks. The exposure is real and it attaches to figures that cannot be explained as much as to figures that are wrong.
This is why the failure is structural rather than a reporting-team performance problem. A capable team can assemble a return perfectly and still leave the bank exposed, because the assembly is sound and the lineage underneath it is not. The bank that is exposed here is not the one that misses windows; it is the one that meets every window and cannot, when asked, show where a figure came from, because the systems that would have to show it were never built to.
The shift in one observation
A CBUAE return read as a quarter-end deliverable produces a bank that optimises the reporting window. Read as the last step of a chain that ran all quarter, it produces a decision to instrument origin, movement, and aggregation. The banks that are exposed when a figure is questioned are usually the ones that perfected the window. The ones that are not are the ones that made every figure traceable before it ever reached the window.
Where the Quarter-End Model Breaks
The reporting-is-a-window model breaks in four predictable places against a supervised return.
Origin attributes never captured
A figure cannot be more correct than the data captured when the transaction was created. When source systems built for operating do not capture the classification and counterparty attributes the return needs, the integrity ceiling is set low at origin and no downstream effort raises it.
Undocumented movement
Every hop between core, product, risk, and finance either preserves meaning or degrades it. Transformations applied in transit without documentation mean the final figure has a history no one can fully state, and an unexplainable figure is a supervisory problem even when it is numerically close.
Risk and finance disagree
When the same underlying data is aggregated differently by risk and finance, one reality produces two numbers. The reconciliation that resolves them is done under window pressure, which is when it is most error-prone and least documented, embedding the weakness into the return.
Production mistaken for assurance
Assembling and formatting a figure to the CBUAE structure is visible work that feels like control. It is not. It cannot make a figure with an unsound origin sound, so effort spent perfecting production is effort that does not touch the place integrity is actually decided.
The Numbers
Two Ways to Treat Regulatory Reporting
The difference between banks that can defend any figure and those that can only submit it is whether reporting is a window or a chain.
| Dimension | Reporting as a window | Reporting as a chain |
|---|---|---|
| Where effort goes | The quarter-end production step. | Origin, movement, and aggregation, all quarter. |
| Origin attributes | Reconstructed into the return later. | Captured fit-for-return at the point of origin. |
| Data movement | Undocumented, history unknown. | Lineage preserved across every hop. |
| Risk vs finance | Reconciled under deadline pressure. | One agreed basis, reconciled by construction. |
| A supervisory question | Answered by reconstruction under scrutiny. | Answered by following documented lineage. |
A bank exposed when the CBUAE questions a figure has usually not missed a deadline. It has met every window and cannot show where the number came from, because integrity is a property of a figure's history, and history is built all quarter in the systems the report only inherits.
What Upstream Instrumentation Looks Like
The pattern in banks that can defend any submitted figure is recognisable. The attributes a return needs are captured at the point of origin, so data enters its life fit for the return rather than reconstructed into it. Lineage is preserved across every movement between core, product, risk, and finance, so each figure carries a documented path rather than an untraceable history. Risk and finance aggregate on a single agreed basis, so they reconcile by construction instead of in a quarter-end firefight. The reporting window is then spent validating and assembling figures that are already sound and traceable, which is the only thing the window can usefully do. When the regulator asks how a number was produced, the answer is to follow the lineage, not to reconstruct the number under scrutiny.
This does not necessarily mean replacing the core, risk, or finance systems already in place. In many banks the lineage and origin capture can be built around the existing systems, so traceability becomes a property of the data flow rather than a separate reconciliation exercise. Replacement becomes the better option mainly where the existing systems structurally cannot carry the attributes or preserve lineage across movement. Which applies is specific to the systems in place, and is established in scoping before any build commitment.
How This Sits Alongside the Bank's Own Responsibilities
The configuration keeps a clear separation. The bank owns its regulatory relationships, its reporting submissions, its accounting and risk judgements, and its own compliance with the CBUAE framework. The software is the instrumentation: capturing origin attributes, preserving lineage across movement, and supporting a single aggregation basis so figures are sound and defensible before the window.
This is the role BY BANKS is positioned for. We are an independent software engineering company based in the UAE. We design and build software and hand it over to the bank that runs it. We do not prepare regulatory submissions, make accounting, risk, or capital determinations, act as auditors, or act for or on behalf of the CBUAE, and we are not affiliated with or endorsed by the CBUAE or any authority. The bank owns its submissions, its determinations, and its own compliance; we build the instrumentation that makes its figures traceable. The accountable party leads and owns the obligations; we build to their direction.
Where This Analysis Is Useful
The conversations where this perspective is most useful tend to be at three moments: a bank that meets every CBUAE window and still feels exposed when a figure is challenged; a reporting or data lead who cannot trace a submitted number back to origin without reconstruction; or a CRO reviewing why supervisory questions are hard to answer cleanly. The honest answer is usually the same: integrity is decided upstream of the report, the window cannot create it, and the durable fix is instrumenting origin, movement, and aggregation rather than perfecting production.
For broader related work, see our perspective on why global AML platforms keep needing custom work in the UAE and our perspective on why UAE banks keep losing money on analytics they already bought. The applied work sits across our CBUAE regulatory reporting, banking document management, and core banking augmentation capabilities, within the broader banking software practice and our operational platforms work. Get in touch if a 45-minute conversation about a specific reporting chain would be useful.
Frequently Asked Questions
No. We are an independent software engineering company based in the UAE. We design and build software and hand it over to the bank that runs it. We do not prepare regulatory submissions, make accounting, risk, or capital determinations, act as auditors, or act for or on behalf of the CBUAE, and we are not affiliated with or endorsed by the CBUAE or any authority. On any engagement, the bank owns its submissions, its determinations, and its own compliance. We build the instrumentation that makes figures traceable; the bank produces and owns the returns.
They are drawn from the CBUAE rulebook and Federal Decree-Law No. (6) of 2025 as published, and are summarised here, not reproduced as legal text and not legal advice. The authoritative requirements, including any conditions, exceptions, and updates, are those issued by the CBUAE and in the law itself. Banks should rely on the official instruments and qualified regulatory and legal advice for their specific obligations, not on this summary.
Meeting deadlines proves the window is managed; it does not prove a figure is traceable. The exposure this addresses is a number that is submitted on time and cannot be explained from origin when the regulator asks. If a supervisory question about how a figure was derived would currently trigger a reconstruction rather than a lineage walk, the deadline performance is not the gap; the upstream traceability is.
Often not. In many banks the origin capture and lineage can be built around the systems already in place, so traceability becomes a property of the data flow rather than a separate reconciliation. Replacement becomes the better option mainly where the existing systems structurally cannot carry the required attributes or preserve lineage across movement. Which applies is specific to the systems in place and is established in scoping before any build commitment.
It is sequenced and does not require pausing reporting. The usual starting point is the returns and figures most exposed to supervisory challenge, instrumented for origin capture and lineage first, so the highest-risk numbers become defensible before anything else. Aggregation reconciliation and the remaining returns follow. The order is driven by where the supervisory exposure and the traceability gap coincide, which scoping establishes for the specific bank.
CBUAE regulatory reporting is widely treated as a quarter-end deliverable and is in practice the final step of a chain whose integrity was decided months earlier, in origin, movement, and aggregation the report only inherits. The window cannot create traceability, the fixed CBUAE deadlines make reconstruction inside it the hardest work at the worst time, and the consequence, an administrative fine ceiling of up to AED 1 billion under Federal Decree-Law No. (6) of 2025 and eleven bank enforcement actions in 2024, attaches to figures that cannot be explained as much as to figures that are wrong. The banks that can defend any figure are the ones that instrumented the chain upstream. The build is software work; the submissions, the determinations, and compliance with the CBUAE framework remain entirely the bank's, and the system simply makes every figure traceable before it reaches the window where its integrity would otherwise only be discovered.
References to the CBUAE rulebook, CBUAE reporting deadlines, CBUAE 2024 enforcement activity, and Federal Decree-Law No. (6) of 2025 are descriptive of publicly available official sources and are summarised, not reproduced. Figures cited (administrative fine ceiling up to AED 1,000,000,000 under Federal Decree-Law No. (6) of 2025; 11 banks subject to CBUAE enforcement action in 2024, 6 in connection with AML/CFT and sanctions-framework weaknesses; audited financial statement, BRF95, and Pillar 3 submission windows) are drawn from public sources listed on our Sources and Data page; the lineage chain is an observational model rather than a regulatory methodology and represents no specific bank or system. BY BANKS is an independent software engineering company; we do not prepare regulatory submissions, make accounting, risk, or capital determinations, act as auditors, or act for or on behalf of the CBUAE, and we are not affiliated with or endorsed by the CBUAE or any authority. On any banking engagement, the bank owns its submissions, its determinations, and responsibility for its own regulatory compliance. This article is not regulatory, accounting, or legal advice; banks should obtain qualified advice for their specific obligations. Public sources used in this piece are listed on our Sources and Data page.
Ready to Build Something?
If this resonated, let's talk about how we can apply these ideas to your business.
Start a Conversation