This article sets out the definitive regulatory playbook for enterprise Point-in-Time (PIT) reconstruction in UK Financial Services. It explains why PIT is now a supervisory expectation: driven by PRA/FCA reviews, Consumer Duty, s166 investigations, AML/KYC forensics, and model risk, and makes a clear distinction between “state as known” and “state as now known”. Covering SCD2 foundations, entity resolution, precedence versioning, multi-domain alignment, temporal repair, and reproducible rebuild patterns, it shows how to construct a deterministic, explainable PIT engine that can withstand audit, replay history reliably, and defend regulatory outcomes with confidence.

Executive Summary (TL;DR)

In 2025–2026, UK regulators expect Financial Services firms to reconstruct historical “state as known” and “state as now known” views on demand. This requires more than snapshots: it demands SCD2-complete Bronze history, time-versioned precedence rules, temporal entity resolution, and a deterministic PIT engine capable of replay.

This article defines the enterprise PIT playbook, explaining how to build reproducible, multi-domain point-in-time reconstruction that supports Consumer Duty, s166 reviews, AML/KYC forensics, and model risk. Firms that cannot deterministically replay historical state will fail regulatory scrutiny; firms that can have a defensible data platform.

This article breaks PIT reconstruction down into its practical components. It explains the two distinct types of PIT required in Financial Services (“state as known” and “state as now known”), why most platforms fail to deliver either reliably, and the specific architectural flaws that cause those failures — incomplete SCD2 history, unversioned precedence, non-temporal entity resolution, misaligned domain timelines, and non-deterministic reprocessing.

It then sets out a concrete enterprise playbook: the foundations required in Bronze, the viable PIT implementation patterns (on-the-fly, materialised, and hybrid), how to align PIT across customers, accounts, products, contracts, transactions, and parties, how to build a reproducible PIT engine, and how to handle late-arriving data, corrections, and regulatory restatement. The result is a platform that can deterministically replay historical belief, generate audit-ready evidence packs, and withstand PRA/FCA scrutiny with confidence.

Contents

1. Introduction: PIT Is Now a Regulatory Requirement

How UK Financial Services rebuild “state as known” and “state as now known” for audits, reviews, model back testing, and Consumer Duty remediation.

Point-in-Time (PIT) reconstruction is no longer an architectural luxury in UK Financial Services — it is a regulatory expectation. PRA/FCA reviews, s166 Skilled Person investigations, Consumer Duty look-backs, AML/KYC forensic analyses, and model risk audits all require firms to show not only what is true today, but exactly what the organisation believed about a customer, account, party, transaction, or attribute at a specific moment in the past.

This article sets out the definitive playbook for enterprise-grade PIT reconstruction in a modern medallion architecture. It covers definitions, regulatory context, temporal modelling strategies, SCD2 pitfalls, entity-level PIT, multi-domain alignment, lineage expectations, and rebuild patterns. The goal is simple: build a platform where you can look a regulator in the eye and confidently reconstruct history — deterministically, explainably, and repeatedly.

Point-in-Time reconstruction used to be a data-architecture “nice-to-have” — something only advanced risk teams cared about. That world is gone.

In 2025–2026, PIT is central to:

• Consumer Duty reviews
• AML/KYC investigations
• Model monitoring and backtesting
• Complaints and remediation
• PRA/FCA supervisory reviews
• Operational resilience incident reconstruction
• Conduct and fairness assessments

Regulators no longer accept “the data isn’t available” or “we didn’t keep that version”.
They now expect firms to demonstrate:

“What did you know, when did you know it, and how do you prove it?”

This requires a deliberate, well-engineered, enterprise PIT strategy.

Part of the “land it early, manage it early” series on SCD2-driven Bronze architectures for regulated Financial Services. PIT for “as known” vs. “as now known” in UK FS, for architects, risk teams, and compliance specialists who need defensible historical views. This article gives the playbook to meet s166 and Consumer Duty expectations.

2. The Two Types of PIT: “State as Known” vs. “State as Now Known”

Most failures in PIT reconstruction stem from a single conceptual mistake: treating all historical views as equivalent. In reality, Financial Services requires two distinct reconstructions of the past, each serving a different regulatory purpose and each governed by different rules. The most important conceptual distinction — and the one most FS firms get wrong — is that there are two types of PIT.

2.1 PIT Type 1: “State as Known on Date X”

Regulatory scrutiny focuses on contemporaneous belief, not retrospective correctness. What matters is the data that genuinely existed at the time—even when it was incomplete, outdated, or wrong—because that is what informed real decisions and actions.

This means:

• use the data that actually existed at that time,
• including incorrect, incomplete, or out-of-date values that were genuinely held.

This is used for:

• complaints
• remediation
• regulatory forensics
• operational reconstruction

This is the version that must be audit-defensible.

2.2 PIT Type 2: “State as Now Known on Date X”

There is also value in reconstructing the past using everything the organisation knows today. This corrected view supports analysis, learning, and improvement, but it answers a different question and must never be substituted for audit-grade historical truth.

This means:

• reconstruct the correct view of what should have been known at that time,
• using corrected data, late-arriving information, and updated golden-source precedence.

Used for:

• model backtesting
• challenger models
• scenario-based risk analysis
• Consumer Duty fairness checks

Both PIT views are essential — but they must NOT be conflated.

Platforms that only support one of them fail under scrutiny.

3. Why PIT Reconstruction Fails in Most FS Platforms

Despite significant investment in data platforms, many firms discover their PIT capabilities collapse under challenge. The failure is rarely due to a single missing feature; it is usually the result of several small architectural shortcuts compounding over time.

So most organisations discover they cannot produce accurate PIT when asked.

Common failure modes:

3.1 Incorrect or incomplete SCD2 history

When historical change is not captured cleanly at the point of ingestion, every downstream reconstruction inherits that distortion. Seemingly minor SCD2 flaws quietly undermine the integrity of the entire timeline.

• Late events override earlier ones
• Version windows overlap
• Temporal gaps
• Updates applied in arrival order, not event order

3.2 Precedence rules not versioned

Authoritative source selection changes over time. When those changes are not explicitly recorded and versioned, historical reconstructions silently apply today’s logic to yesterday’s data.

Golden-source logic drifts over time without being tracked.

3.3 Entity resolution is non-temporal

Most entity resolution operates only in the present. Without historical versions of identity and linkage, platforms cannot reconstruct who the organisation believed an entity was at a given moment.

Clusters and links are current-only and cannot be reconstructed historically.

3.4 Multi-domain PIT not aligned

Customers, accounts, products, and contracts often evolve on different timelines. If those timelines are not aligned, reconstructed states become internally inconsistent and impossible to defend.

Customer PIT is on one timeline; account PIT on another; product on another.

3.5 No deterministic “replay” mechanism

A reconstruction that cannot be reproduced is not evidence. When backfills or reprocessing yield different answers, historical truth becomes subjective rather than demonstrable.

Backfills produce different results from original runs.

These problems make PIT unreliable and regulator-defensible reconstruction impossible.

4. PIT Foundations: SCD2 Bronze + Entity Resolution + Precedence

Reliable PIT reconstruction depends on a small number of foundational capabilities. Without these in place, no amount of downstream modelling or optimisation can compensate.

A correct PIT architecture rests on three components:

4.1 SCD2 Bronze (Event-Time Ordered)

The Bronze layer must preserve a complete, event-time-ordered record of change. Arrival order, convenience flags, or partial overwrites are incompatible with defensible historical reconstruction.

• Full history of every attribute
• Effective_from = true event time
• Effective_to = next event time
• Late/out-of-order event repair
• Hash-based change detection
• Hybrid merge optimised

Without correct SCD2, PIT is impossible.

4.2 Entity Resolution on Bronze

Historical belief about identity and relationships must be captured where history lives. Entity resolution that is applied only after aggregation cannot be reliably reconstructed backward in time.

PIT must reflect:

• who we thought the customer/entity was,
• which records belonged to the entity,
• and when we believed that link to be valid.

Entity-level relationships must be SCD2’d as well.

4.3 Versioned Precedence Rules

Precedence determines which source “wins” when facts conflict. Because those rules evolve, they must be time-bound and versioned so that historical reconstructions apply the logic that was valid at the time.

Precedence defines which source is authoritative.

For PIT, precedence itself must be:

• time-stamped
• version-controlled
• explainable

If precedence changes in 2024, your PIT on 2021 must use the 2021 rules unless building “now-known” PIT.

5. PIT Patterns: Snapshots, Temporal Joins, Windowed Aggregations

There is no single PIT implementation that fits every regulatory and operational need. Different patterns exist because different trade-offs matter in different contexts.

There are three broad PIT implementation patterns, each useful in FS.

5.1 On-the-Fly PIT (Temporal Joins)

Dynamic reconstruction offers flexibility and immediacy, but it amplifies any weakness in underlying temporal logic. Its power is matched by its fragility.

A query selects the versions valid at a specific timestamp:

SELECT *
FROM bronze_customer c
WHERE c.customer_id = 'C123'
  AND c.effective_from <= '2022-05-10T12:00:00'
  AND c.effective_to   >  '2022-05-10T12:00:00'

Advantages:

• always up to date
• no storage overhead

Disadvantages:

• expensive
• difficult across multiple domains
• sensitive to underlying SCD2 correctness

5.2 Materialised PIT Snapshots

Materialised PIT trades freshness for stability. In regulated environments, that stability often matters more than immediacy, particularly where audit and reproducibility are required.

Daily (or hourly) snapshots stored in Silver or Gold:

• customer_pit_20220510
• account_pit_20220510
• party_pit_daily

Advantages:

• fast queries
• stable for auditing
• reproducible

Disadvantages:

• storage cost
• snapshot timing must be consistent

5.3 Hybrid PIT (Best practice in large FS)

Large institutions rarely choose between dynamic and materialised PIT exclusively. Combining both allows precision where it is needed and stability where it is required.

• Materialised daily PIT for stable auditing
• On-the-fly PIT for intermediate exploratory analysis
• Versioned precedence and ER rules embedded

This hybrid model is the dominant pattern in modern Tier-1 banks.

6. PIT Across Multiple Domains: Customer, Account, Party, Product, Contract, and Transaction

Regulatory questions rarely concern a single domain in isolation. PIT becomes substantially harder—and far more important—once multiple, interdependent domains must be reconstructed as a coherent whole.

This is where PIT becomes complex.

Each domain has its own:

• identifiers
• SCD2 tables
• precedence rules
• entity resolution
• natural temporal grain

PIT must align these:

• a customer is PIT’d at T
• their accounts PIT’d at T
• the products linked to the accounts PIT’d at T
• contracts (e.g. loan terms) PIT’d at T

If these are not aligned:

• risk models use inconsistent states
• customer remediation aggregates the wrong accounts
• AML investigations miss relationships

6.1 Domain timelines must be normalised

Before domains can be combined, their timelines must be made compatible. Without normalisation, even technically correct PIT views fail when joined together.

A standard approach is:

• convert all timestamps to UTC
• snap PIT to daily midnight, unless sub-daily accuracy is required
• break ties deterministically

6.2 Multi-domain PIT joins

A defensible historical view depends on anchoring all domains to the same moment in time. Only then can relationships between customers, accounts, products, and contracts be trusted.

Use entity_id as the anchor:

customer_pit
  JOIN entity_links_pit
  JOIN account_pit
  JOIN product_pit
  JOIN contract_pit

All filtered to the same PIT timestamp.

6.3 Events vs. State: Why Transactions Behave Differently

Not all data participates in PIT in the same way.

Entities such as customers, parties, contracts, and products represent state that genuinely changes over time and must be modelled with temporal versioning (for example, SCD2). Transactions are different.

A transaction is a point-in-time event. It does not change after it occurs. What changes is the organisation’s knowledge about that event — for example, enrichment, classification, correction, or reconciliation. At the moment the transaction occurred, incomplete or erroneous attributes still represent “state as known” and must be preserved as such.

For PIT purposes, this means transactions are reconstructed by:

• anchoring the immutable event time, and
• selecting the attributes and classifications that were known at the reconstruction timestamp.

This distinction is critical. Treating transactions as mutable entities obscures the difference between historical belief and later correction, and leads to incorrect “as known” reconstructions.

7. How to Build a Reproducible PIT Engine

Ad-hoc PIT queries do not scale to regulatory scrutiny. What’s required is a formal mechanism that can reconstruct historical state consistently, repeatedly, and under challenge.

A regulator-defensible PIT engine has these components:

7.1 A PIT “compiler”

Given a timestamp and configuration, the platform must deterministically assemble a complete historical state. This turns PIT from an analytical trick into an operational capability.

A job that, given a timestamp T:

• performs all domain PIT selections
• applies precedence rules valid at T
• resolves entities/clusters at T
• materialises a complete PIT dataset

7.2 Versioned configuration

Historical reconstruction is meaningless if the rules applied are unknown. Every PIT output must carry the versions of the logic that produced it.

PIT must include:

• which rules were applied
• which attribute sets
• which precedence version
• which ER version

All captured in metadata.

7.3 Deterministic logic

If the same reconstruction produces different results over time, the platform has lost authority over its own history.

Re-running the PIT engine for T must produce:

• the same output
• with the same rules
• using the same SCD2 data

If it doesn’t, PIT is not reliable.

7.4 Back testable model inputs

Credible model validation depends on historically accurate features. PIT is what allows past decisions to be evaluated fairly, using the data that actually informed them.

For IFRS9, IRB, pricing, fraud, and credit models:

• PIT must reconstruct the exact feature sets
• including derived variables
• using historically correct data

This enables challenger models and fairness assessments.

8. Temporal Repair, Restatement, and Late-Arriving Corrections

History does not arrive neatly ordered. Mature PIT platforms are defined by how they absorb disruption without erasing evidence or rewriting belief.

This is the area where most FS firms fail.

8.1 Late-Arriving Data

When genuinely old information arrives late, it must be inserted into the past without distorting the present or obscuring the fact that it arrived after the event.

If a record from 2021 arrives in 2025:

• SCD2 Bronze must insert it in its correct place
• PIT must adjust
• PIT snapshots must be version-aware

8.2 Corrections and Restatements

Backdated changes affect timelines, precedence, and relationships. Handling them safely requires explicit control over which version of history is being reconstructed.

If a core system backdates changes:

• version windows shift
• precedence may change
• entity links may reconfigure

A mature platform can:

• rebuild PIT for any time period
• under old rules (state as known)
• or new rules (state as now known)

8.3 Regulatory Restatement

Restatement itself has become a regulated activity. Regulators expect evidence that changes to history were intentional, governed, and fully traceable.

PRA expects:

• documentation of restatement logic
• change logs
• evidence that PIT shifts were intentional and governed

This is now a core requirement for Consumer Duty.

9. Regulatory Expectations and Evidence Packs

At the point of scrutiny, PIT is no longer an internal capability: it is evidence. What matters is not how elegant the architecture is, but whether it can answer regulatory questions clearly and completely.

For PIT, the FCA and PRA typically ask for:

9.1 Demonstration of Temporal Accuracy

Regulators expect proof that timelines reflect real event ordering, not convenient reconstruction.

Show:

• the SCD2 lineage
• the event-time ordering
• how reprocessing is handled

9.2 Reproducibility

Historical state must be regenerated on demand, without hidden dependencies or manual intervention.

They expect:

• PIT for any date
• to be regenerated on demand
• with no hidden corrections

9.3 Explainability

Being able to explain why a value was selected is as important as the value itself.

You must show:

• which version of the record was used
• which source system won via precedence
• which ER decision placed the customer in that cluster

9.4 Traceability

Every reconstructed attribute must point back to a concrete source record and event.

Every PIT attribute must trace back to:

• an SCD2 row
• a source-system value
• supporting metadata (batch_id, event_id, source timestamp)

9.5 Completeness

Silence is suspicious. Regulators increasingly test whether anything has been omitted, not just whether what is present is correct.

Regulators increasingly verify:

• whether PIT includes all accounts, all products, all relationships
• whether any records were silently dropped
• whether linkage logic changed without documentation

PIT cannot be a black box.

10. Summary: PIT as the Definition of a Mature Platform

Point-in-time reconstruction is where data engineering, governance, and regulatory credibility converge. A platform that can reconstruct belief accurately, repeatedly, and transparently is no longer just technically mature: it is institutionally trustworthy.

Enterprise PIT reconstruction is where:

• SCD2 Bronze,
• entity resolution,
• precedence,
• and governance
  all converge.

A mature PIT platform can:

• replay history accurately,
• reconstruct “as-known” and “now-known” states,
• align multiple domains to the same timeline,
• withstand late and out-of-order data,
• and satisfy PRA/FCA audits with traceable lineage.

In 2025–2026, PIT reconstruction is the new definition of platform maturity in UK Financial Services:

If you can tell a regulator, with a straight face and full lineage, exactly what you believed about any customer, account, or product on any date — and how that belief has changed — then you have a modern FS data platform.

Everything else is commentary.