Financial services data architectures often fail by asking the wrong question: “Which system is the system of record?” This article argues that regulated firms operate with multiple systems of authority, while truth exists outside systems altogether. What data platforms actually manage is institutional belief: what the firm believed at a given time, based on available evidence. By separating authority, truth, and belief, firms can build architectures that preserve history, explain disagreement, and withstand regulatory scrutiny through accountable, reconstructable decision-making.

Contents

1. Introduction: Why “System of Record” Is the Wrong Question

Enterprise data debates in financial services often start from a desire for certainty and simplicity. That instinct is understandable: but in regulated environments, it leads to architectural shortcuts that fail under scrutiny.

Financial services data architecture is still haunted by a deceptively simple question:

“Which system is the system of record?”

In regulated environments, this question is not just unhelpful — it is actively misleading.

Modern financial institutions do not operate with a single system of record. They operate with multiple systems of authority, each optimised for a different purpose, operating under different constraints, and changing at different speeds.

Understanding this distinction — between authority, truth, and belief — is essential to building data platforms that are both operationally effective and regulator-defensible.

Part of the “land it early, manage it early” series on SCD2-driven Bronze architectures for regulated Financial Services. Separating authority/truth/belief in FS platforms, for architects, governance teams, and regulatory leads who need clarity on “system of record”. This article gives the lens to resolve debates and build defensible belief.

2. Three Concepts That Must Not Be Confused

Many disagreements about data quality, lineage, and correctness are not technical failures but conceptual ones. Clarity requires separating ideas that are often treated as interchangeable, despite serving fundamentally different purposes.

Most architectural confusion in financial services comes from collapsing three fundamentally different concepts into one.

2.1 Authority

Who is allowed to assert or change something

Authority is about permission and control.

Examples:

• A core banking system has authority to execute a payment
• A CRM system has authority to record customer intent or interaction
• A trading system has authority to submit an order

Authority answers the question:

“Who is allowed to say this happened?”

2.2 Truth

What actually happened in the world

Truth is independent of systems.

• A payment either cleared or it didn’t
• A trade either executed or it didn’t
• A customer either gave consent or they didn’t

No single system creates truth.
Systems merely observe, record, or act upon it.

2.3 Belief

What the institution believes to be true at a given point in time

Belief is what data platforms manage.

Belief is:

• time-dependent
• evidence-based
• revisable
• explainable

Belief answers the question regulators actually care about:

“What did the firm believe at the time the decision was made, and why?”

3. Why Financial Services Requires Multiple Authorities

Financial services operate across activities that differ in speed, control, and accountability. Execution, interaction, and observation impose requirements that cannot be satisfied by a single system without trade-offs.

This reality is often met with calls for a “golden source” or “master system”. These approaches fail not because they are poorly implemented, but because they attempt to collapse incompatible authority domains.

Treating this as simplification is a mistake. It is a refusal to accept how financial systems actually function.

In practice, this separation shows up consistently across financial services platforms.

3.1 Transactional Systems

• Require strong consistency
• Enforce integrity constraints
• Optimised for correctness and latency
• Often overwrite state

These systems are authoritative for execution, not history.

3.2 CRM and Case Management Systems

• Optimised for human workflow
• Allow correction, override, and free-text input
• Often non-temporal by design
• Reflect intent, not outcome

These systems are authoritative for authoring, not truth.

3.3 External and Market Feeds

• Arrive late, corrected, or restated
• Often lack a single definitive timestamp
• May contradict internal views

These are authoritative for observation, not decision.

4. The Lakehouse as a Belief Reconstruction Engine

Once authority is distributed, the role of the central data platform must change. Its value lies not in asserting reality, but in preserving how understanding evolved across the organisation.

In this landscape, the role of the enterprise data platform is often misunderstood.

It is not:

• the ultimate source of truth
• the place where reality is decided
• a replacement for operational authority

Instead, the platform is the system of institutional belief.

Its job is to:

• collect assertions from multiple authorities
• preserve them without overwriting
• order them in time
• apply governed interpretation rules
• allow prior beliefs to be reconstructed

This is why:

• history matters
• overwrites are dangerous
• point-in-time reconstruction is essential

The lakehouse does not decide what happened.
It preserves what the firm believed, when it believed it, and why.

5. Why Disagreement Is Not a Failure

In environments where actions, observations, and interpretations occur at different speeds, temporary inconsistency is inevitable. The real risk lies elsewhere.

When multiple authorities exist, disagreement is inevitable.

Examples:

• CRM shows a customer address change that hasn’t propagated
• A transaction is authorised but not yet settled
• A regulatory report differs from an operational dashboard
• A correction arrives after a decision was made

These are not architectural flaws.

They are evidence of separate authority domains operating correctly.

The failure is not disagreement.
The failure is being unable to explain it.

6. Belief Is What Regulators Actually Assess

Supervisory scrutiny focuses less on perfect outcomes than on defensible decision-making. Evidence, timing, and rationale matter more than retrospective correctness.

Regulators do not expect firms to have perfect foresight.

They expect firms to demonstrate:

• decisions were made using reasonable belief
• belief was based on available evidence
• belief evolved when new information arrived
• changes to belief were governed and auditable

This is why:

• point-in-time views matter
• “as-known” vs “as-of” distinctions matter
• lineage and provenance matter

A firm that can reconstruct belief is defensible — even if belief later proves incomplete or incorrect.

7. Edge Systems Are Not Compromises: They Are Authority Domains

Operational systems are often treated as technical baggage to be managed or replaced. In practice, they exist because certain responsibilities cannot be centralised without loss.

Operational systems at the edge of the platform are often described as “legacy”, “sources”, or “constraints”.

This framing is wrong.

Edge systems exist because:

• some actions must be strongly consistent
• some workflows must be human-centric
• some decisions must be made in milliseconds
• some controls must be enforced synchronously

These systems are not failures of centralisation.
They are necessary authority domains.

The data platform does not replace them.
It contextualises them.

8. Authority Decays; Belief Accumulates

The confidence attached to an action changes over time as new signals arrive. Systems must account for this shift rather than assuming that immediacy equates to certainty.

A crucial but under-articulated property of financial data systems is this:

• Authority is strongest at the moment of action
• Belief strengthens over time

Immediately after a transaction:

• the transactional system is authoritative
• belief is provisional

Over time:

• confirmations arrive
• corrections are applied
• relationships are resolved
• belief converges

The platform’s job is to preserve this evolution, not flatten it.

9. What This Article Does and Does Not Claim

Not every architectural concern can—or should—be addressed at once. Precision about scope is essential to avoid conflating principles with implementation.

This article does not:

• define eventual consistency mechanics
• explain PIT pipelines
• describe entity resolution algorithms
• prescribe lakehouse layering

Those topics are addressed elsewhere.

This article exists to make one principle explicit:

In regulated financial services, there is no single system of record — only multiple authorities and an evolving institutional belief.

10. The Architectural Consequence

Separating these concepts reshapes not only system design, but the questions organisations are able to answer when challenged.

Once authority, truth, and belief are separated:

• “system of record” debates disappear
• edge systems stop needing justification
• eventual consistency becomes inevitable
• point-in-time reconstruction becomes non-negotiable
• architecture diagrams stop lying

Most importantly, regulatory conversations change from:

“Why is this wrong?”
to
“Why did you believe this at the time?”

Only one of those questions is survivable.

11. Conclusion and Closing

Architectures are ultimately judged under pressure, not in diagrams. The ability to explain decisions coherently is the difference between resilience and exposure.

Financial services platforms that fail regulatory scrutiny rarely fail because they lacked data.

They fail because they cannot explain:

• who asserted what
• when it was asserted
• why it was believed
• and how belief changed

A mature data platform does not promise truth.

It promises accountable belief and the evidence to defend it.

Architectures that cannot answer these questions are not merely incomplete: they are indefensible.