The pattern that shows up every time
There is a pattern that repeats across financial services with uncomfortable regularity. An organisation decides to get serious about data. Budget is approved, a platform is chosen, a team is assembled. Eighteen months later there is genuinely impressive infrastructure in place, well governed, well documented, technically sound. And almost nothing has changed for the business.
The problem is rarely the technology. It’s that the technology came first and the business problem came second.

The real cost of data perfectionism
The instinct to build a complete foundation before doing anything useful is understandable in regulated industries. If you’re operating under FCA oversight, handling personal financial data under UK GDPR, or building products that touch payments or credit, governance isn’t optional.
But there’s a meaningful difference between data that is governed because it needs to be and data that is governed because someone bought a tool. The first is a business asset. The second is an overhead.
The cost isn’t just the time and money spent on the platform. It’s the opportunity cost of decisions still being made on gut instinct and spreadsheets while the modern data stack sits largely idle.
What trusted data actually means in practice
Good data engineering in financial services comes back to three principles: no invented data, no lost data, and no trust. They sound technical, but they translate directly into questions any business should be asking before using data to make decisions or train models.
Can you trace every number back to its source? If a regulator asked you to reconstruct a decision made six months ago, could you? Are you treating your data as something to be verified, or something to be believed?
You don’t need a perfect data catalogue to meet that standard. You need to be able to answer those questions for the data that matters most.
Start with the use case, not the platform
Governance built around a real use case is governance that gets used. Governance built speculatively is governance that becomes a burden.
Pick the highest-value problem first. Ask what data it depends on, where that data lives, and what it would take to trust it enough to act on it. Build the governance that answers those questions, and no more than that.
Audit trails, immutability, reconciliation, and access controls are not optional in regulated financial services, but they need to be built in from the start of a specific, well-defined use case, not a multi-year platform programme with no clear output.
The infrastructure layer underneath it all
All of it sits on top of infrastructure. And in regulated financial services, that infrastructure carries its own obligations.
Audit trail requirements mean data needs to be stored in a way that is tamper-evident and recoverable. UK GDPR means where data lives matters, not just how it is governed. FCA and ISO 27001 expectations mean access controls, change management, and incident response need to be demonstrable.
For lean firms moving fast in this space, those requirements are not something they want to own internally. They need infrastructure partners like Pipe Ten who understand the regulatory environment and have the compliance posture already built in.
Data-first doesn’t mean data-perfect
The firms that will move fastest on data and AI in financial services are not the ones with the most sophisticated platforms. They are the ones that are most deliberate about which data they trust, for which decisions, and why.
Perfect data is a distraction. Trusted data is the goal.
Key takeaways
- Building data infrastructure before identifying a clear business use case is one of the most common and costly mistakes in financial services
- Governance built around a real use case gets used; governance built speculatively becomes overhead
- Trusted data means tracing every number to its source, reconstructing decisions under scrutiny, and verifying rather than assuming
- Audit trails, immutability, and access controls need to be built in from the start, not bolted on afterwards
- The infrastructure beneath your data carries its own compliance obligations around residency, auditability, and security
- The firms that move fastest on AI are the ones most deliberate about which data they trust and why
Key takeaways
- Building data infrastructure before identifying a clear business use case is one of the most common and costly mistakes in financial services
- Governance built around a real use case gets used; governance built speculatively becomes overhead
- Trusted data means tracing every number to its source, reconstructing decisions under scrutiny, and verifying rather than assuming
- Audit trails, immutability, and access controls need to be built in from the start, not bolted on afterwards
- The infrastructure beneath your data carries its own compliance obligations around residency, auditability, and security
- The firms that move fastest on AI are the ones most deliberate about which data they trust and why
If you’re building data or AI capability in a regulated environment and want to talk about the infrastructure layer beneath it, feel free to get in touch.
Author: Gavin Kimpton
A founder and CEO/CFO of Pipe Ten, Gavin has been a leader in the digital sector for over 30 years, specialising in web application hosting, domain registration, and international site launches. He has navigated evolving internet governance, from new top-level domains to security and compliance. Under his leadership, Pipe Ten became a Nominet-accredited channel partner, reflecting his deep expertise in the digital ecosystem.

Author: