Regulatory reporting programmes fail in a specific way. They do not fail because the requirement was misunderstood; the requirement arrives as a schema and a deadline, and both are unambiguous. They fail because delivering the new report breaks the reports that were already working, and nobody notices until the month-end run.
This is a view from the delivery side — what a regulatory reporting programme actually demands from a bank’s data team, written from the experience of delivering one for a Saudi bank under a regulator-defined schema and a fixed submission window.
In short
Regulatory reporting programmes rarely fail on the requirement — the schema and the date are unambiguous. They fail when the new report breaks the reports that already worked. One metadata model, legacy reports in every regression cycle, and monitoring from go-live.
The constraint that shapes everything else
In a normal data project, scope and date are negotiable against each other. In regulatory reporting neither is. The schema is externally defined, the submission window is fixed, and the regulator is not a stakeholder you can go back to with a change request.
That single constraint changes how the work must be sequenced. You cannot discover the hard parts late, because there is no room at the end to absorb them. Everything that could go wrong has to be found in the first third of the programme, when there is still time to react.
In practice that means front-loading the environment assessment and the message-structure analysis before any development starts — and treating that assessment as a deliverable, not a formality.
Three engineering decisions that decide the outcome
1. One metadata model, not a parallel one
The fastest way to deliver a new regulatory report is to build it alongside the existing model — a separate set of definitions, tuned for the new requirement, shipped without touching anything that already works. It is also the decision that costs the most, and the cost arrives later.
Two models means two definitions of the same business concept. Within a quarter they drift. Within a year the bank cannot say which number is correct, and every subsequent wave of the programme has to be built twice.
A single governed metadata model is slower in the first wave and faster in every wave after it. On a programme with known future waves, that trade is not close.
2. Legacy reports belong in every regression cycle
The reports that already run are the ones nobody is watching, and they are the ones a schema change is most likely to break. Including them in every regression cycle feels like wasted effort for most of the programme — right up until the cycle where it is not.
The alternative is discovering the break in production, during a submission window, with no time to fix it. The economics of that trade are not subtle.
3. Performance monitoring starts at go-live, not after the first complaint
Regulatory reports grow. Volumes rise, the model accumulates, and a report that completed comfortably in the first month starts to run close to the window in the sixth. If monitoring starts after someone complains, you are already in the month where it matters.
Instrument the runs from the first submission. The baseline you capture in month one is what tells you, in month six, whether you are looking at growth or at a regression.
What the work actually consists of
The visible part of a regulatory reporting programme — building the report — is rarely more than a third of the effort. The rest is spread across work that does not appear in the requirement document:
- Environment assessment — what exists, what it is connected to, and what the new requirement will disturb
- Message parsing and generation — reading and producing the regulator’s defined message structures exactly, including the cases the specification handles implicitly
- Metadata extension — adding the new concepts to the existing model without duplicating what is already defined
- Business and presentation layer modelling — so the numbers can be explained, not just produced
- Testing support — including the regression cycles above
- Post-launch operations — the part that decides whether the second submission is as calm as the first
Teams that scope only the visible third are the ones that run out of time in the final month.
The question to ask a delivery partner
Most firms will tell you they can build the report. The useful question is narrower: what will you do to make sure the reports we already submit still work the day after yours goes live?
An answer that treats that as an afterthought tells you how the programme will end. An answer that describes a regression approach, a single metadata model and a monitoring plan tells you the team has delivered one before.
The second question worth asking: what happens in wave two? Regulatory programmes arrive in waves. A partner optimising for the first wave and a partner optimising for the fourth make visibly different engineering decisions, and you are paying for the difference either way.
Why this is a data governance problem wearing a reporting costume
It is tempting to treat regulatory reporting as a reporting problem — a new output on top of an existing platform. It is not. Every requirement the regulator adds is a question about definitions, ownership and lineage: what does this field mean, who decides, and where did the number come from.
Banks that have those answers deliver each wave faster than the last. Banks that do not rediscover the same unknowns every time, and pay for the rediscovery every time.
Which is why the right time to put governance underneath regulatory reporting is during the first wave, not after the fourth.
How we work on these programmes
Smart Way Technology has delivered regulatory reporting work for Al Rajhi Bank across the full chain — environment assessment, message parsing and generation, metadata extension, business and presentation layer modelling, analysis development, testing support and post-launch operations — under externally defined schemas and fixed submission windows. Details of that engagement are in our case studies.
The capability sits across two of our practices: data management for the model and governance underneath the reports, and business intelligence for the analysis and delivery layer on top.
If you have a reporting wave approaching and want a second opinion on the sequencing before you commit the team, get in touch.
Not sure which solution fits your needs?
Every engagement is scoped to what you actually need. Tell us a bit about your goals and we will get back to you with the right approach.
Leave A Comment