This article argues that modelling transactions as slowly changing dimensions is a fundamental category error in financial data platforms. Transactions are immutable events that occur once and do not change; what evolves is the organisation’s interpretation of them through enrichment, classification, and belief updates. Applying SCD2 logic to transactions conflates fact with interpretation, corrupts history, and undermines regulatory defensibility. By separating immutable event records from mutable interpretations, platforms become clearer, auditable, and capable of reconstructing past decisions without rewriting reality.

Contents

1. Introduction: The Category Error That Breaks Otherwise Good Platforms

Well-intentioned data platforms often fail in subtle ways that only become visible once history, audit, or regulation demands precision.

Many financial services data platforms fail not because they lack sophistication, but because they commit a category error:

They model transactions as if they were mutable state.

This often manifests as:

• applying SCD2 logic to transactional tables,
• tracking “changes” to facts that should never change,
• or treating corrections as updates rather than reinterpretations.

This article makes a single, explicit claim:

Transactions are immutable events. They are not slowly changing dimensions, and modelling them as such corrupts both history and meaning.

Part of the “land it early, manage it early” series on SCD2-driven Bronze architectures for regulated Financial Services. Transactions as immutable events vs. mutable interpretations, for data modellers, engineers, and compliance teams who need to avoid category errors in temporal design. This article gives the boundary to preserve fact from belief.

2. What a Transaction Actually Is

Before discussing modelling patterns, it is necessary to be precise about what a transaction represents in the real world.

A transaction is a fact about something that occurred.

Examples:

• a payment instruction was executed
• a trade was matched
• a premium was charged
• an interest accrual was calculated
• a ledger entry was posted

A transaction:

• happens at a point in time
• is atomic
• cannot be partially true
• cannot later “change” without ceasing to be the same transaction

Once a transaction exists, its occurrence is no longer a matter of state — it is a matter of record.

3. What Slowly Changing Dimensions Are For

Slowly changing dimensions (SCD) exist to solve a specific and well-understood problem that is frequently misunderstood or over-generalised.

SCD2 exists to model mutable descriptive state.

Examples:

• customer address
• account status
• product attributes
• risk classification
• organisational hierarchy

These things:

• change over time
• overwrite prior values in source systems
• require preservation of historical versions
• must answer “what was believed at time T?”

SCD2 is a compensation mechanism for state mutation.

Transactions do not mutate.
They are observed.

4. Why Applying SCD2 to Transactions Is Wrong

When SCD2 is applied to transactional data, the resulting problems tend to follow a small number of recurring patterns.

Typically in this instance, one of three incorrect things is happening.

4.1 Confusing Correction with Mutation

One common failure mode arises from misunderstanding how errors and corrections relate to historical facts.

A transaction that is corrected does not change.

Instead:

• a new transaction is issued
• a reversal is posted
• an adjusting entry is created

The original transaction remains true.
What changes is interpretation, not fact.

SCD2 hides this distinction by overwriting meaning.

4.2 Confusing Enrichment with Change

Another source of confusion appears when additional context is mistaken for alteration of the underlying event.

Transactions are often enriched:

• linked to customers
• categorised
• risk-scored
• associated with cases

These enrichments evolve over time — the transaction does not.

SCD2-ing the transaction row conflates:

• a stable event
• with unstable context

This destroys lineage clarity.

4.3 Confusing Belief Evolution with Fact Evolution

The most subtle error occurs when changes in organisational understanding are treated as changes to reality itself.

As belief changes, the firm’s understanding of a transaction may evolve:

• fraud indicators change
• counterparty resolution improves
• regulatory classification updates

None of this alters the transaction.

SCD2 models belief evolution, not event evolution.
Transactions already encode time.

5. The Correct Model: Events Plus Interpretation

A more robust approach emerges once events and their evolving interpretations are treated as separate concerns.

The correct approach is to separate:

5.1 Immutable Event Records

At the foundation of this model is a clear commitment to preserving what actually occurred.

• one row per transaction
• immutable after creation
• event time is inherent
• corrections are additive

5.2 Mutable Interpretations

Around that foundation sits a layer designed to accommodate uncertainty, learning, and reclassification over time.

• classifications
• linkages
• derived attributes
• regulatory status

These interpretations:

• are time-dependent
• may change as belief evolves
• may be SCD2’d appropriately

The event remains constant.
The interpretation evolves.

6. Why This Matters for Regulatory Defensibility

These modelling choices are not academic; they directly affect an organisation’s ability to justify past actions.

Regulators care deeply about what actually happened.

If a platform:

• overwrites transaction records,
• hides reversals,
• or collapses corrections into “latest state”,

then it cannot:

• explain discrepancies
• reconstruct prior reports
• defend decisions made on earlier interpretations

Treating transactions as immutable events preserves:

• evidence
• auditability
• legal defensibility

Treating them as SCD2 rows erases it.

7. Transactions Already Have Time… Don’t Simulate It

Many temporal modelling techniques exist to compensate for missing information that transactions inherently possess.

A subtle but important point:

SCD2 exists to simulate time for things that lack it.

Transactions already have:

• occurrence time
• processing time
• settlement time
• posting time

Adding effective_from / effective_to to a transaction is redundant at best, misleading at worst.

It suggests the transaction itself changed, rather than the firm’s understanding of it.

8. Where This Boundary Is Commonly Violated

Despite its importance, this distinction is frequently lost in modern platform implementations.

This error often appears when:

• platforms try to “standardise” modelling patterns
• Bronze is treated as “SCD2 everything”
• teams optimise for uniform pipelines over semantic correctness

Uniformity is not maturity.

Correctness is.

9. How This Fits with Temporal Platforms

Separating events from interpretations does not conflict with temporal design principles, but clarifies them. This position does not weaken temporal platforms — it strengthens them.

By keeping transactions immutable:

• temporal complexity moves to where it belongs
• PIT reconstruction becomes clearer
• belief evolution is explicit
• corrections are additive and auditable

State changes and event occurrence are distinct temporal problems.
They deserve distinct models.

10. What This Article Does and Does Not Claim

To avoid misapplication, it is important to be explicit about the limits of the argument being made.

This article does not:

• describe how Bronze tables are implemented
• prescribe storage formats
• explain PIT reconstruction
• discuss performance optimisation

Those concerns are addressed elsewhere.

This article exists to enforce one boundary:

If something happened, record it once.
If understanding of it changes, record that change — not a new version of the fact.

11. The Architectural Consequence

Once the boundary is enforced, a series of downstream architectural effects follow naturally.

Once transactions are treated as events:

• SCD2 is reserved for true state
• enrichment pipelines become cleaner
• lineage becomes intelligible
• reconciliation becomes explainable
• “why did this change?” questions get real answers

Most importantly, the platform stops lying about reality.

12. Conclusion and Closing

When facts and beliefs are allowed to evolve independently, data platforms regain both honesty and clarity.

Transactions do not change.

Our understanding of them does.

A mature financial services data platform preserves that distinction… and everything else becomes simpler, clearer, and more defensible as a result.