The hardest part of automating regulatory reporting is the list

An institution considering automated regulatory reporting usually opens with the question of which system to buy. It is the wrong first question. The right one is duller: how many returns do you actually owe?

Most cannot answer quickly. Not because nobody knows, but because the knowing is distributed. The monthly statement of affairs sits with one person. The weekly foreign exchange position sits with another. The sectoral advances return belongs to whoever inherited it four years ago. Each of them is reliable. Collectively they are an undocumented system.

The list is the deliverable

We built a reporting engine for an institution carrying more than fifty periodic obligations across several authorities. The automation was the straightforward part. The work that took longest, and mattered most, was writing the returns down.

A registry entry that is actually useful records more than a name:

• What the return is, in the authority’s own language rather than the bank’s internal shorthand.
• Who it goes to. More than one authority is normal, and the same figure often goes to two of them in different shapes.
• The cycle — daily, weekly, monthly, quarterly — on the regulator’s calendar rather than the institution’s.
• Where the data comes from: which system, which table, which field. Not “core banking”.
• The mandated template, and which version of it is current.
• Who prepares it, and who is permitted to approve it.

Fill that in for every return and two things happen before a line of code is written. You find obligations nobody had on a list. And you find returns being assembled in a spreadsheet one person maintains by hand, which is a continuity risk before it is an efficiency one. The question was never only whether a return goes out on time. It is whether anyone other than its usual author could produce it at all.

What automation adds, once the list exists

With the registry written down, the engine has something to run on, and four things become worth building.

Pulling from source. The engine collects from the systems that hold the numbers, not from a prepared extract. The moment a human assembles the input, the automation is decorating a manual process rather than replacing one.

Templates as configuration. Each return is built against its mandated template, and that template is data the engine reads — not logic compiled into it. This is the decision that pays for itself, for reasons the next section covers.

Scheduling as the system’s job. If the cycle lives in someone’s calendar reminder, the cycle is still a person. Due dates belong in the registry, and the engine is what notices.

Maker-checker inside the flow. A person prepares, a different person approves, and the submission cannot happen without both. The control has to be in the path rather than beside it. A review step that can be skipped under deadline pressure will be.

What breaks, and it is always the same thing

Templates change. A regulator reissues a return with two new columns, or renames a field, or alters a validation rule, and does so with weeks of notice rather than months.

If the template is configuration, this is an afternoon: update the mapping, run the validator against last period’s data, submit. If the template is code, it is a release — with a developer, a test cycle, and an approval queue standing between the institution and a statutory deadline.

We have been through three format migrations on a single reporting system. Every one of them was absorbed without touching the engine, and that is not a sign of clever engineering. It is a sign of the one architectural decision made correctly at the start.

The related trap is validation. A return that is submitted and rejected has not been filed. Schema validation belongs before submission, inside the pipeline, with the failure landing on the preparer while there is still time to act on it — not in an authority’s rejection notice two days later.

What we would tell someone starting

Spend the first fortnight on the registry, not on tooling. Write down every return the institution owes, with its authority, cycle, template and data source. Do it in a spreadsheet if that is what moves fastest; the format matters far less than the completeness.

Then automate the three or four highest-frequency returns and leave the rest alone. A daily return automated well is worth more than fifteen annual ones automated adequately, and it produces the evidence you will need to justify the next phase.

And keep the audit trail from the first filing, not the first audit. What was produced, from which data, approved by whom, submitted when. Assembling that retrospectively is the single most expensive thing we have watched a compliance team attempt.

The uncomfortable part of all this is that the registry is the deliverable. The automation is worth less than the list it runs on — and the list is the part no vendor can sell you.

We wrote about the system this came from in our regulatory reporting engine case study, and the broader service is compliance and RegTech automation.