Show Me the Trail, Not Your Data Platform

Everyone in financial services is talking about the same things right now: data platforms, governance tools, lineage software, AI-powered compliance. Walk into any banking conference and you'll hear vendors promise that the right stack solves audit-readiness.

It doesn't. Not on its own.

When an inspector walks in, whether it's a regulator checking your risk data or one checking your financial crime controls, they don't ask what platform you run. They ask one question: show me the trail.

I learned that lesson before I ever worked in banking.

Show me the trail

Piraeus, spring 2014. I was a Safety Manager on board a vessel, there to run an internal audit, the routine check you do under the ISM (International Safety Management) Code to catch problems before anyone else does. By the time I reached the engine room, Port State Control was already onboard.

A vessel calling at a port can be boarded at any time by Port State Control, port inspectors who verify that the ship meets international safety and environmental standards, regardless of what flag it sails under. That day, they asked for the maintenance record on the auxiliary engine.

The work had been done. I knew that, the crew knew that. But the logbook didn't show it. No timestamp, no sign-off, no entry proving the maintenance happened when it was supposed to.

Inspector issued a deficiency in their report. Not because the engine wasn't maintained. Because we couldn't prove it.

That's the moment that's stayed with me. The inspector never asked what system we used to track maintenance. He asked if we could prove what happened, when it happened, and who signed off on it. The work was real. The trail wasn't.

Two ways a trail breaks

Across two industries now, I've seen the same pattern repeat. Compliance trails don't fail randomly. They fail in one of two ways.

People forget to document in the moment. The work gets done, but the proof doesn't keep pace with it. Nobody meant to cut corners; the task got finished, the form stayed open, and "I'll fill it in later" quietly became never. That's Piraeus.

Or people reconstruct after the moment. The audit is already scheduled, the gap is already visible, and the record gets built backwards to close it, dated as if it happened on time.

Both patterns exist in maritime. Both exist in banking.

Take the first one, forgetting to document in the moment. The European Central Bank's own 2024 supervisory guide on risk data found banks taking 40 or more working days just to produce a single risk report, because the trail behind it had to be pieced back together by hand before anyone could trust it.

Take the second, reconstructing after the fact. The same guide is direct about it: manual overrides must be documented the moment they happen, not patched in afterward. Supervisors wrote that requirement because they've seen what happens when that discipline slips.

Nobody's lying here. The system just makes both failures easy. Figuring out which one happened, that's the inspector's job.

The same problem, bigger stakes

Banks don't fail audits because they lack data platforms. Most have invested heavily: Databricks, Snowflake, Collibra, dashboards, governance frameworks. The problem sits underneath those platforms.

A transaction moves through three systems before it reaches a report. A risk number gets adjusted by hand on a Tuesday and nobody logs why. Ownership of a dataset changes when a team reorganises, and six months later nobody remembers who's accountable for it. The lineage exists, but it lives in someone's memory, in a Slack thread, in an analyst's head. Not in the system. That's how the trail breaks.

The European Central Bank's 2024 guide on risk data aggregation didn't mince words: across the banks it reviewed, none had fully implemented the data principles regulators expect, including the largest, most resourced institutions in Europe. Progress on the basics, clear ownership, documented lineage, audit-trailed changes, hadn't moved in years.

This isn't only a risk-reporting problem. Dutch authorities have fined the country's largest banks over €1 billion combined this past decade for the same underlying failure: policies that looked sound on paper, but didn't match what was actually happening.

The principles regulators are pushing, complete lineage, traceable ownership, documentation at the point of action, are becoming the standard every supervisor expects, regardless of a bank's size or systemic status. Because the underlying question never changes: when something goes wrong, can you show me what happened, step by step, before I have to ask twice?

A design decision, not a feature

Buying the platform was never the hard part. Designing it so the trail can't quietly disappear, that's the actual work.

Most governance conversations inside a bank happen too late. The platform gets built first. Lineage, ownership, documentation: those get scheduled for "phase two," a cleanup task after go-live. By the time anyone circles back to it, the trail has already started to fray. Someone's left the team. A transformation step got changed without a note explaining why. What was supposed to be a temporary gap quietly becomes permanent, embedded in how the team operates.

Go back to that engine room in Piraeus for a second. The lesson I took away wasn't "use better software to track maintenance." It was simpler than that: a good system doesn't ask people to remember. It makes the right action the only easy one. If documenting maintenance the moment it happens is harder than doing it later, people will do it later, and "later" is where trails go to die. If reconstructing a missing record is easier than admitting the gap, some people will reconstruct it. Both failures share one root cause: a system where the easy path and the wrong path happen to be the same path. Good design breaks that link. It makes the right thing the only easy thing left to do.

My colleague Sam recently wrote about exactly this, walking through a real migration from legacy SSIS and SQL systems onto Snowflake. What stands out in her is the sequencing, not the tooling. Lineage gets captured while the data moves. Ownership gets assigned before go-live, not chased down six months later when someone finally asks who's responsible for a dataset.

There's a real difference between a platform that happens to have good governance and one that was built so the trail can't get lost. One depends on people remembering. The other doesn't need them to.

Audit-readiness isn't a checkbox you tick after the system is live. It's a decision you make before a single table gets migrated, about who owns what, what gets logged, and what happens automatically versus what depends on someone's good intentions on a Friday afternoon.

What's already being built

The good news is the industry isn't standing still. The shift happening right now in compliance tooling is exactly the one this post has been describing: tools that don't wait for an audit to assess whether a control is working. They sit next to the data itself, evaluate requirements continuously, and attach evidence the moment it's generated. At DataChef, we're building in that direction.

That's a meaningful change from how most banks have operated. For years, audit-readiness has meant a once-a-year scramble: pull the spreadsheets, chase down the owners, hope the gaps aren't too large to explain. Continuous assessment flips that. The trail builds itself as the work happens, so there's nothing to reconstruct when someone finally asks.

The inspector doesn't care about your platform. They care about your trail.

Make sure it exists before they arrive.

Sources

• European Central Bank, Guide on effective risk data aggregation and risk reporting, May 2024
• Netherlands Public Prosecution Service, ING pays €775 million due to serious shortcomings in money laundering prevention, September 2018
• Netherlands Public Prosecution Service, ABN AMRO pays €480 million on account of serious shortcomings in money laundering prevention, April 2021