Your data doesn’t need to live together.
It needs to make sense together.

One customer can exist across five systems. The Board still needs one answer.

Financial institutions have spent years centralising data for good reasons: reporting consistency, control, reconciliation and scale. Those investments matter. But the hidden risk between regulatory silos is not fundamentally a storage problem. It is a relationship problem.

A complaint can live in CRM, a vulnerability marker in a customer platform, an outage in a service-management tool, a fraud intervention in a financial-crime system and a Conduct metric in a reporting layer. Moving all five records into one warehouse does not automatically tell the firm that they describe the same customer, product, journey or outcome.

The enterprise view comes from the relationships

The practical architecture is a joined-up regulatory ecosystem: one governed understanding of regulation, products, journeys, customers, services, suppliers, controls, metrics and events – with evidence able to remain in the systems best placed to own it. Connected does not mean centralised. It means the same business reality can be understood consistently across domains.

The question is no longer ‘how do we put everything in one place?’ It is ‘how do we make everything relevant to the same risk make sense together?’

One place can still produce five different answers

Centralisation can improve control and scale. But a warehouse can still contain several definitions of ‘complaint’, multiple customer identifiers, different journey taxonomies, local calculations and competing versions of the same control. Storage does not resolve semantic disagreement.

That is why three dashboards can all be green. Each may be correct within its own definition and still miss the combined story. The customer does not experience the warehouse, the CRM or the incident platform. The customer experiences the product and the journey that cut across them.

The joined-up regulatory ecosystem is the missing layer

The enterprise needs to know that a complaint, an outage, a vulnerability indicator, a fraud intervention and a Consumer Duty metric can all point to the same product, customer cohort, journey step or service. That relationship is what turns separate evidence into triangulation.

The missing layer is a governed business and regulatory map: obligations linked to products; products to journeys; journeys to customers; journeys to services and third parties; controls to obligations; evidence to all of them. This is the ecosystem that lets different teams read the same event against the same enterprise context.

The data can stay distributed. The meaning cannot.

The source systems can stay authoritative

For many use cases, the source evidence does not need to be copied into one master repository before it can be connected. The customer platform can own the vulnerability marker. The service tool can own the incident. The complaints system can own the complaint. The financial-crime platform can own the intervention.

A relationship and metadata layer records what each item means, where it came from, how it is calculated and what customer, product, journey, service, control and obligation it relates to. The intelligence comes from joining the context, not pretending the source estate is simple.

One Board conclusion. Many auditable paths back to source.

If a Board is told that customer outcomes are deteriorating, it should be possible to trace the conclusion through the relevant complaint pattern, vulnerability cohort, service incident, fraud control, metric, calculation, source evidence and regulatory expectation. That is a joined-up view without losing accountability for the underlying sources.

This becomes even more important as AI is introduced. A fast answer assembled from inconsistent definitions is not enterprise intelligence. It is automated reconciliation risk. Common meaning, provenance and lineage are what make cross-domain reasoning defensible.

One enterprise view. Many sources. No loss of lineage.

The regulator is moving towards machine-readable, dynamic evidence

On 19 October, the FCA described dynamic data collection as part of the future of supervision. It highlighted its Handbook API, launched in August, and said it is working on machine-readable data-collection APIs. It also described AI that can gather evidence from disparate sources and surface intelligence. [1]

On 22 October, Nikhil Rathi separately challenged potentially duplicative data packs, risk reports and assurance activity that contribute to ‘tick-box compliance’. [2] None of this tells firms to abandon data platforms or build one specific architecture. It does strengthen the case for an operating model in which evidence is machine-readable, reusable and connected rather than repeatedly reconstructed for each report.

AI needs the relationships, not just access

Give an AI system access to complaints, incidents, customer data and controls and it can retrieve more information. But unless it knows which definitions are authoritative and how the records relate to the same customer, journey, service and obligation, it can still produce a coherent answer to the wrong question.

A joined-up regulatory ecosystem gives AI that context: entities, relationships, lineage, permissions and rules. It tells the machine which evidence belongs together before asking it to reason across the enterprise.

One customer. Five systems. One governed story.

The regulatory model defines what the firm is expected to achieve. The business map describes the products, journeys, customers, services, suppliers and controls that deliver it. The evidence model points to complaints, vulnerability, incidents, fraud events, metrics and source data that show what is happening.

Triangulation then happens around the shared context. A complaint spike, an outage and a vulnerability impact can be read as related evidence even though the records remain in different systems. That is the practical move from siloed dashboards to one enterprise view.

Five questions that should now be asked