The reports regulators actually ask for

There is a stage almost every growing institution passes through where the monthly regulatory return is produced by one person, in a spreadsheet, over three days, from figures they extract by hand and reconcile by memory. Everyone knows this is fragile. It survives because the alternative — going back and changing how data is captured — feels much larger.

It is larger. It is also the only thing that works, and the cost grows every quarter you delay.

The underlying problem is that operational systems are designed around what a transaction needs to complete, while supervisory reporting is designed around how exposures are classified. Those are different shapes. A loan disbursement needs a customer, an amount, a schedule and an account. A prudential return needs that same loan bucketed by sector, by product type, by tenor band, by arrears ageing, by security held, by related-party status, and by currency of denomination — often several of those simultaneously.

If the operational system never captured sector, or captured it as free text into a field three branches fill in differently, no reporting layer can recover it. The information does not exist. Somebody will assign it manually, from memory, at quarter end — and that is the actual reason the return takes three days.

So the first move is to work backwards from the returns you are obliged to file. Take them literally. Every dimension they slice by is a field that must be captured at origination, as a constrained value from a controlled list, not free text. Sector, product, tenor, security type, related-party flag, currency, branch, officer. Most of these cost one dropdown at the point of capture and are essentially unrecoverable afterwards.

The second move is to make classification rules explicit and versioned. Arrears ageing, provisioning bands, restructure treatment — these are policy, they change, and they change on dates that matter. When a definition changes mid-year, you need to be able to produce both the figure as reported then and the figure under today's rules, and explain the difference. A system that only ever holds the current rule cannot do this, and the conversation with a supervisor about why last year's number no longer reproduces is not one you want to have without evidence.

The third is that every reported figure should be traceable to the transactions that compose it. Not approximately — exactly. When somebody asks why the number moved, the answer should be a list of the underlying records, produced in minutes. This single capability changes the character of supervision. It turns a defensive exercise into a factual one, and it is almost entirely a function of whether your reporting reads from transactional records or from summary tables somebody populates.

Which brings up the most common architectural mistake: reporting off aggregates. It is tempting, because aggregates are fast. But the moment a figure is questioned, you cannot decompose it, and the moment a classification rule changes, you cannot restate history. Compute from the transaction record, and cache the aggregate if you need the speed — never the other way round.

There is a happy side effect to all of this. The dimensions a regulator wants are, with remarkable consistency, the dimensions a board wants. Exposure by sector, ageing by product, concentration by counterparty, yield by tenor — supervisors ask for these because they are the questions that matter about a lending book. Institutions that build for the return usually discover they have accidentally built the management information they had been asking for separately, and paying for twice.

The reverse never happens. Nobody has ever built a beautiful executive dashboard and found that it happened to satisfy a prudential return.

Start from the filing. The dashboard falls out of it.