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.

In less regulated domains, this modelling mistake may appear harmless or merely stylistic. In financial services, however, where audit, reconciliation, and regulatory scrutiny are unavoidable, the distinction between immutable fact and evolving interpretation becomes foundational. What seems like a convenience early on becomes a liability later.

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.2.1 Example (late arriving completeness)

• Consider a payment that is first published with a NULL amount because pricing is not yet known.
• A later feed emission populates the amount once settlement completes.
• An SCD2 approach would suggest the payment “changed”.
• The correct model is additive publication history: the event did not mutate, the platform received a more complete observation of it.

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 immutable record per observed transaction occurrence (one “row”)
• 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.

In this context, an interpretation is any derived, assigned, or contextual attribute that is not part of the transaction’s occurrence itself.

The event is what happened; the interpretation is what the organisation later concludes, attaches, or believes about it.

5.3 Event Revisions and Late Arriving Completeness

A practical complication arises in real financial feeds that is worth naming explicitly.

While transactions are immutable events, transaction feeds are not always a single, perfect publication of those events.

In payments and trading systems, it is common for the same transaction identifier to appear multiple times across days or processing cycles. This does not mean the transaction has changed. It means the organisation is receiving repeated or revised publications of the same underlying occurrence.

For example:

• a payment is first recorded with an unknown amount or missing price
• a trade is reported before final settlement values are confirmed
• an upstream platform emits a placeholder row and later emits a completed one
• the same transaction is replayed unchanged as part of resilience or batch recovery

In these cases, the correct interpretation is not that the transaction mutated, but that the platform’s knowledge of the event arrived in stages.

This creates an important distinction:

• Transaction identity (the business correlation ID)
• Event instance (the fully observed row as published at a point in time)

A transaction identifier is often a correlation key used by upstream systems, not a guarantee that the first published row is complete or final.

Event identity lies in the occurrence itself, not in the convenience of a source-system primary key.

A mature platform must therefore support event revision semantics without collapsing into SCD2 mutation.

The correct handling is:

• If an incoming transaction row is identical to one already recorded, it should not be rewritten. The platform may simply update a “last seen” marker for operational traceability.
• If an incoming row shares the same transaction identifier but differs materially (e.g., amount populated, price corrected, settlement attributes updated), it should be treated as a new published instance, stored additively.

The transaction did not change.

The platform received a new version of the event’s publication.

This preserves the boundary:

• the event record remains immutable
• completeness and correction are additive
• history is not overwritten
• regulatory defensibility is maintained

In other words: late arriving enrichment must not be implemented as mutation of fact.

It must be modelled as the arrival of new evidence about the same occurrence, recorded explicitly rather than rewritten implicitly.

Transactions remain events.

But transaction feeds often deliver those events through successive revisions of completeness — and a correct architecture must represent that honestly.

5.4 A Concrete Example: Late Arriving Completeness Is Not Transaction Mutation

A simple payment example makes the category error visceral.

A transaction feed may first publish an event with incomplete information:

• the payment occurred
• the identifier is known
• the amount is not yet populated

Later, the same identifier is re-emitted with the amount filled in.

A naïve SCD2 approach models this as if the transaction itself changed.

5.4.1 Bad: Transaction as SCD2 (Implies Mutation of Fact)

txn_id	amount	valid_from	valid_to
TX123	NULL	Jan 1	Jan 2
TX123	100.00	Jan 2	NULL

This suggests the transaction evolved over time, as if the payment was first “partially true” and later became real.

That is a category error.

The transaction did not change.

5.4.2 Good: Immutable Event Publications (Additive Observation History)

Event table (what was observed):

txn_id	amount	observed_at
TX123	NULL	Jan 1
TX123	100.00	Jan 2

The platform has not rewritten history.

It has recorded successive publications of the same occurrence as completeness arrived.

Interpretation table (what the organisation later believed about it):

txn_id	classification	valid_from
TX123	CustomerPayment	Jan 3

The transaction remains immutable.

What evolves is:

• completeness
• enrichment
• classification
• belief

This is why transactions belong in event records, and interpretations belong in mutable temporal layers — not in SCD2 versions of the transaction itself.

This is the operational reason transaction ingestion must be revision-aware and additive, rather than update-in-place.

5.5 Idempotent Event Publication and Revision-Aware Append

A transaction platform must distinguish between the immutability of an event and the operational reality that events may be published more than once.

Transaction feeds are frequently replayed, re-emitted, or completed in stages. The same transaction identifier may appear repeatedly, either unchanged or with additional information populated later.

A correct architecture therefore requires an ingestion rule that is neither naïve overwrite nor SCD2 mutation, but idempotent event publication tracking.

The abstract pattern is:

• Each transaction is treated as an immutable event record.
• Each incoming feed row is treated as a publication of that event.
• Publications that are identical to one already recorded are not rewritten.
• Publications that differ materially are stored additively as new event instances.

In other words:

• Identical replays are operational duplicates and should only update a “last observed” marker.
• Materially different re-emissions are new evidence and must be preserved as additional history, not collapsed into a single mutable row.

This preserves the boundary:

• the event does not change
• completeness arrives over time
• corrections are additive
• history remains defensible

The system is therefore not performing update-in-place, nor simulating slow change.

It is implementing a revision-aware, append-only event ledger in which immutability applies to recorded instances, while feed replay and late arriving completeness are handled explicitly and honestly.

Transactions remain events.

What evolves is not the fact, but the sequence of published observations of it.

5.6 What This Is Not

Because these patterns are frequently misunderstood, it is worth stating explicitly what this model is not.

This approach is not SCD2 applied to transactions.

SCD2 exists to preserve versions of mutable descriptive state. Applying it to transactional facts implies that the transaction itself evolved, when in reality the platform is observing repeated publications or revised completeness of the same occurrence.

Transactions are not slowly changing dimensions.

They are events.

This approach is also not a naïve overwrite or upsert strategy.

A “latest row wins” model collapses history, erases corrections, and destroys the ability to explain what was known at earlier points in time. Overwriting transactional facts is indistinguishable from rewriting reality.

Nor is this simply “deduplication” in the superficial sense.

The goal is not to remove history, but to preserve it correctly:

• identical replays are operational noise
• materially different re-emissions are new evidence

Finally, this is not a claim that transaction feeds are perfectly clean or that upstream systems never revise their outputs.

They do.

The architectural requirement is that the platform must represent those revisions honestly:

• by recording additive event instances
• by separating fact from evolving interpretation
• by maintaining defensible historical truth

The transaction does not change.

The organisation’s observation of it may arrive in stages.

A mature platform preserves that distinction rather than simulating mutation through SCD2 or overwriting through convenience.

Revision-aware append is an event-sourcing concern, not a dimensional modelling concern.

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

Event time is inherent to the transaction: it encodes when something occurred.
SCD2 validity time is an artificial construct designed to simulate temporal evolution for mutable state.
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.

This separation makes point-in-time questions trivial: the event table answers what happened, while the interpretation table answers what we believed about it at time T.

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
• prescribe specific merge or ingestion mechanics for revision-aware transaction feeds, only the semantic boundary they must respect

Those concerns are addressed elsewhere.

It is also worth acknowledging the trade-off explicitly: separating immutable event records from mutable interpretations often increases historical volume and requires more disciplined point-in-time querying. That cost is real, but in regulated finance it is the price of preserving defensible truth rather than optimising for convenience.

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
• transaction writes become revision-aware and idempotent, preventing duplicate replays while preserving additive corrections

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.