Regulatory Reporting: The Quarterly Fire Drill Nobody Fixes

Every quarter, the same thing happens. A small group of people stop doing their actual jobs and spend three weeks assembling the regulatory return. Spreadsheets circulate. Numbers get reconciled by hand. Someone stays late. It ships, just about, and everyone exhales — until next quarter, when it happens again, identically.

Nobody thinks this is a good process. It persists because fixing it is nobody's project, and because the fire drill is survivable each individual time.

Why it stays broken

It's survivable. That's the core reason. A process that fails catastrophically gets fixed. A process that's merely painful, quarterly, gets endured — because the pain arrives on a predictable schedule and is absorbed by a small number of people who've stopped complaining.

The knowledge is tribal. Two or three people know how the return is actually assembled — which adjustments, which exceptions, which manual overrides. It's not documented, and they're the reason it works. That's the same retirement risk as legacy systems, in a different costume.

The numbers don't reconcile from source. This is the real technical blocker. If your systems produced consistent, agreed figures, assembling a return would be a query. They don't, so the process is fundamentally an act of reconciliation — and reconciliation is manual because the discrepancies aren't systematic.

Each requirement was solved separately. Solvency, statutory, tax, regulatory — each got its own spreadsheet built by whoever owned it. There's no shared foundation, so there's five times the work and five chances to disagree.

Why it's worth fixing now

Two things have shifted the calculation.

Requirements are increasing. AI governance reporting under the NAIC bulletin and EU AI Act, climate and ESG disclosure, more granular data requests. The manual process that barely absorbs today's load will not absorb next year's.

Regulators increasingly ask for lineage. Not just the number, but where it came from. A figure assembled through an undocumented chain of spreadsheets can't answer that. This is turning "our process is manual" from an efficiency issue into a compliance exposure.

What actually fixes it

1. Define each figure once, in one place. The definition of a reported metric should exist as versioned code in your data platform, not as a formula in a spreadsheet cell. Every return that needs it reads the same definition. This is where most of the reconciliation work disappears — you're no longer reconciling because there's only one number.

2. Build the reporting layer on the platform, not beside it. Returns should be generated from governed tables, not from extracts someone downloads and manipulates. The moment data leaves the platform into a spreadsheet, you've lost lineage and reproducibility.

3. Capture the adjustments as data. There will always be legitimate manual adjustments. The mistake is making them in a cell. Record each as a structured entry with a reason, an approver, and a timestamp, applied by the pipeline. Now adjustments are auditable and reproducible rather than tribal.

4. Make it reproducible for any past date. You must be able to regenerate last year's return exactly as filed. That requires versioned data, versioned logic, and an immutable record of adjustments. If you can't reproduce a prior filing on demand, you have a problem you haven't discovered yet.

5. Run controls continuously, not at quarter-end. Reconciliation checks, completeness thresholds, and variance alerts should run daily. Then quarter-end is a confirmation rather than a discovery — and problems surface when there's time to fix them, not on the deadline.

6. Automate assembly, keep humans on judgment. The goal isn't removing people. It's removing the three weeks of copying and reconciling so the actual expertise — is this number right, does this adjustment make sense, does this look odd — gets the attention. Right now that judgment happens at 11pm on the last day, which is when judgment is worst.

The realistic path

Don't try to automate everything at once. Take one return, and within it the handful of figures that cause most of the reconciliation pain. Define those centrally, generate them from the platform, and run the controls daily.

Next quarter, that portion is a query instead of a fire drill. That's the proof that funds the rest — and unlike a big-bang programme, it delivers on a timeline someone will still be around to remember.

The point

Regulatory reporting is the clearest example in insurance of a process everyone accepts as painful because it's predictable. But the pain is a symptom: it exists because the underlying numbers don't agree, and the reconciliation is the manual patch over that disagreement.

Fix the definitions and the foundation, and the fire drill doesn't get faster — it stops being a fire drill. Which is a better outcome than another quarter of heroics from people who deserve their evenings back.

We build governed, lineage-aware reporting foundations that make regulatory returns reproducible. More at IntelliBooks.

Comments

Post a Comment

Popular posts from this blog

Why Your Insurance Data Warehouse Didn't Fix Anything

You built the data warehouse. It took eighteen months and cost more than planned. Policy data, claims data, billing — it's all in there. The project was declared a success and everyone moved on. And yet: underwriting still can't see the whole customer. The AI initiative is still stalled. Someone still asks for a report and waits three weeks. Nobody says it out loud, but the question hangs there — what exactly did we buy? You're not alone, and it isn't because you built it badly. It's because a warehouse solves a problem you didn't have. The problem a warehouse solves Warehouses solve location . Before: your data was in eight systems. After: it's in one place. That's genuinely valuable — you can run a query across policy and claims without begging two teams for extracts. But notice what that fixes: it fixes where the data is . It doesn't touch what the data means , whether it's trustworthy, or whether the records refer to who you think t...
Read more

Straight-Through Processing: From 10% to 90%

Straight-through processing is the number every insurance executive quotes and almost nobody achieves. The industry benchmark has moved from 10–15% to 70–90% at the carriers who've cracked it. That's not a marginal efficiency gain — it's a different cost structure. So why is your STP rate still stuck in the teens? Because STP gets treated as a workflow project. It isn't. It's a data problem wearing a workflow costume. What STP actually requires Straight-through means a quote, policy, or claim goes from submission to completion with zero human touches . For that to happen, every decision point in the chain has to be answerable automatically. Every single one. A chain of nine automated steps and one manual check isn't 90% straight-through — it's 0%. One human touch and the whole thing is a manual process with extra steps. That's the bar. And it means the constraint isn't the workflow engine — it's whether the data needed at each decisio...
Read more

Embedded Insurance: Why the API Is the Easy Part

Embedded insurance is the idea that coverage should be offered at the moment of need, inside someone else's product — travel insurance at checkout, device protection when you buy the phone, cover for the rental car in the booking flow. It's one of the fastest-growing distribution models in the industry, and every insurer has a strategy slide about it. Most of those strategies underestimate the same thing, and it isn't the partnerships or the product. It's the data plumbing. Everyone assumes the API is the hard part. The API is the easy part. What embedded insurance really demands The promise of embedded is speed and invisibility: a customer buys a flight and, in the same breath, is offered exactly the right travel cover at exactly the right price, and accepts with one tap. No forms, no friction. Deliver that and you've won. But "exactly the right cover at exactly the right price in one tap" makes brutal demands on your back end: You must price i...
Read more