Late-Arriving Events and Backdated Corrections

A payment is economically effective on 17 August at 09:15 but reaches the controlled platform on 19 August at 07:30. On 18 August, the account was delinquent, behavioural PD increased and collections generated an action.

The platform must now answer three questions: what did it know on 18 August, what does it now believe was economically true on 18 August, and which downstream states and decisions changed?

Late does not mean wrong. The payment can be structurally valid and economically correct while arriving after the decision window. Discarding it merely because it is delayed preserves the wrong state.

Actual knowledge and corrected economics are both history

Historical model validation must use known state to avoid hindsight advantage. Data-quality analysis deliberately compares known and restated state to quantify what source latency changed. Mixing these purposes silently corrupts both.

A correction is a new event, not a hidden mutation

interface CorrectionEvent extends FinancialEvent {
  correctionReason: string;
  supersedesEventId?: string;
  correctionType:
    | "BACKDATED"
    | "SOURCE_REPAIR"
    | "MANUAL"
    | "RESTATEMENT";
}

A direct update such as changing payments.effective_time without retaining its old value destroys evidence. Preserve the original event, correction identity, causal link, reason, producer, received time and corrected effective semantics.

Supersession can replace the current interpretation while retaining the previous record. If a correction is corrected again, preserve E₁ → Correction₁ → Correction₂. Corrections are also idempotent events: redelivery must not multiply their economic effect.

Replay from the earliest affected safe point

A late event does not always require replay from origination. Determine T_replay, then select a verified snapshot strictly before the late event's effective position.

async function restateAggregate(
  aggregateId: string,
  lateEvent: FinancialEvent
) {
  const snapshot = await snapshots.findBefore(
    aggregateId,
    lateEvent.effectiveTime
  );
  const events = await eventStore.loadFrom(
    aggregateId,
    snapshot.version
  );
  return replay(snapshot.state, orderForReplay(events, lateEvent));
}

This omits production concerns such as locking, idempotency, schema versions and atomic projection replacement, but preserves the core boundary. Mark invalid snapshots stale, rebuild, verify and replace; never silently mutate snapshot contents. Lineage should retain source version, event range, reducer version and creation time.

Late events belong in economic order, not arrival order

effectiveTime may place a payment economically, but some streams also require source sequence, causal reference or aggregate rules. Sorting by one timestamp blindly can put a reversal before its payment or violate a contractual transition.

A late payment whose reversal arrived earlier in system time still requires identity and causal linkage to determine the valid economic sequence. If evidence cannot establish order safely, quarantine rather than guess.

One late payment can change a temporal graph of dependants

Identify affected account, facility, customer, feature windows, model outputs and decisions. Recompute that radius, not the whole portfolio. Feature metadata should expose source event types, lookback window and calculation version.

A payment effective on day t can affect LatePaymentCount_90d across scoring dates in an interval conceptually resembling [t, t + 90 days], subject to exact feature boundaries and availability rules. The impact is a range, not one row.

Classify shallow corrections to one balance, medium corrections across state components, and deep restatements reaching features, decisions or reporting. This guides orchestration and urgency.

Restate the counterfactual; preserve the actual decision

If rebuilt features change from X^actual to X^restated, the restated PD may differ. Never overwrite the historical score or action; otherwise the institution can no longer explain what it did with the information it had.

The actual collections action remains evidence. The counterfactual shows the action would not have occurred if the payment were available. Classify impacts such as unchanged, approve → reject, no action → contact, or limit increase → hold using domain-specific severity.

Finance may restate balances under controlled accounting rules while Decisioning records counterfactual impact only. Reporting-date and ECL corrections can affect stage, EAD, PD, cure or default, but the architecture does not prescribe whether a reporting period is reopened.

Bitemporal state preserves economic truth and institutional knowledge

CREATE TABLE account_state_history (
  account_id     TEXT NOT NULL,
  balance_minor  BIGINT NOT NULL,
  valid_from     TIMESTAMPTZ NOT NULL,
  valid_to       TIMESTAMPTZ,
  system_from    TIMESTAMPTZ NOT NULL,
  system_to      TIMESTAMPTZ,
  state_version  TEXT NOT NULL,
  CHECK (valid_to IS NULL OR valid_from < valid_to),
  CHECK (system_to IS NULL OR system_from < system_to)
);

Do not bitemporalise every field automatically. Use the second axis where late correction, decision reproducibility and audit value justify storage and query complexity. Never delete known-state history after restatement.

A correction ledger governs detection through closure

These are engineering workflow states, not accounting statuses. Human-created corrections require user identity, timestamp, reason, source evidence and approval where appropriate. Anonymous mutable fixes are not an operational control.

{
  "aggregateId": "acc_9012",
  "restatedFrom": "2026-08-17T09:15:00Z",
  "reason": "LATE_PAYMENT",
  "affectedStateVersion": "state_v42"
}

After verified state replay, an illustrative STATE_RESTATED event can notify downstream consumers. Each consumer decides whether and when its dependency window requires rebuilding; do not trigger blind full rebuilds.

Correct current treatment quickly; complete history reproducibly

A direct current-state patch is acceptable only when lineage is explicit and eventual replay must reconcile to it.

Compare state before and after replay and explain the entire delta through correction events. Current collections may correct immediately while monthly monitoring rebuilds later. Track each consumer separately so online correction does not silently coexist with stale offline history.

A Wednesday payment repairs Tuesday economics without erasing Tuesday history

1. Detect the Wednesday 07:30 arrival as a payment effective Monday 09:15.
2. Validate identity, economic meaning and expected/source latency class.
3. Load the last verified account snapshot before Monday.
4. Insert the payment into causal economic order and replay the account.
5. Restate Tuesday DPD from 1 to 0.
6. Rebuild affected behavioural feature windows and calculate restated PD.
7. Retain the actual Tuesday collections action and input manifest.
8. Record that corrected state would have generated no contact.
9. Update the current queue and reconcile all downstream consumers.

Golden restatement tests prove both histories survive

A golden stream combines ordinary events, a late payment, correction, reversal and decision timestamp. Assert known and restated state at several instants, plus expected actual decision, restated counterfactual and impact class.

This equality assumes identical business semantics and ordering. Also verify full replay equals snapshot-based replay, patch convergence holds, and every state delta reconciles to correction lineage.

Monitor lateness, correction depth and completion

No universal threshold is appropriate. Track median, p95, p99 and extreme delay by source, event type, product and provider. Some next-day sources meet contract; a five-minute source suddenly taking hours is an incident.

Repeated backdating can reveal mapping weakness, source-process failure or a temporal contract mismatch. Data contracts should define event-time meaning, expected arrival cadence, correction behaviour and identity stability. Monitor hotspots as structural infrastructure debt rather than isolated tickets.

The Entimema late-event architecture separates repair from evidence

Banks can use this around corrections from servicing, accounting and legacy batch interfaces; non-bank lenders face the same need across PSP webhooks, SaaS synchronisation, statement lag and external collections. Modern APIs do not eliminate temporal repair.

A Late-Event & Restatement Integrity Agent can orchestrate evidence

A future controlled agent can detect and classify late events, identify invalid snapshots, propose replay boundaries, reconstruct corrected state, compare histories, map affected features and models, quantify decision impact, track consumer completion and surface repeated source failures.

Continue with Reconstructing Account State from Financial Events, Idempotency in Payment and Credit Event Processing, Event Time vs Processing Time vs Posting Time, The Payment Is Not the Balance, Why Batch Risk Is Becoming a Business Risk and The Hidden Infrastructure Debt of Modern Lending. Reversals, DPD and point-in-time features are future Engineering directions, not fabricated routes.