# How must an instance bound FX rate snapshot skew between settlement parties?

**Date of Record:** 2026 November 2

**Scope:** Applies to cross-currency settlements where the exchange rate is captured at a specific instant from a specific source (ECB reference rate, WM/Reuters fix, central bank rate), and the two parties may capture it at different instants. Does not apply to rates explicitly agreed to be the rate at a fixed timestamp with verified synchronized source.

## Core Distinction

An FX rate is a function of time. The same "EUR/USD at 4pm London" is a range, not a point, because the reference source publishes over a window and each party's capture time varies. The variance is small in normal conditions and unbounded in volatile conditions — and volatile conditions are exactly when settlement amounts are largest.

**Invariant.** The rate is agreed if and only if both parties capture from the same source at the same publication instant, and the source publishes as a fixed tuple `(source, publication_time, window)`, not as a range.

**Violation.** The **Rate Snapshot Skew**. The instance captures the ECB 14:15 CET fix; the counterparty captures the same ECB fix at 14:16 because of a queue delay in its data feed. In stable markets the two captures are identical; in volatile conditions they can diverge by cents, and at institutional settlement volumes that is material. Neither side's capture is wrong — the capture instants differ.

**Asymmetry.** Each capture is timestamped with its local receipt time, not with the source publication time. The two timestamps do not compare, because they are timestamps of the same instant observed through different latencies.

**Recorded elements.** The `fx-source-tuple-receipt` (source name, publication instant, publication window), the `capture-instant-receipt` (per-party observed time, back-referenced to publication), and the `rate-drift-signature` (whether the pair is in a volatile regime where skew matters) make the agreement checkable.

## What Was Observed

**Signature.** Cross-currency settlement amounts differing by a small fraction that correlates with market volatility. The difference is negligible on calm days and material on volatile days; both parties' logs show the same rate value because the rate display rounds to the same tick, but the underlying captured rate differs at higher precision.

**Trace.** Notional €50,000,000 at EUR/USD reference. Instance captures 1.0856; counterparty captures 1.0855 from the same source, one publication window earlier during an FOMC release. The $50,000 difference in USD settlement is 1 pip, invisible at the rate level, material at notional. Neither party's capture is wrong.

**Why monitoring stays green.** Both parties show successful rate retrieval. Both report the same rate to 4 decimals. The divergence exists only at higher precision and only during the volatile window, which is not when reconciliation is typically run.

## Condition of Validity

The instance must ensure at least one holds before it treats the FX rate as agreed:

1. **Must capture from the fixed tuple.** The source is specified as `(publisher, publication_instant, window_duration)`; the tuple is stored in the settlement record.
2. **Must back-reference captures to publication.** Each capture is timestamped against publication time, not against the local receipt time, so the two captures are comparable.
3. **Must set a volatility contingency.** Where the pair is in a high-volatility regime, settlement is not bound to a single snapshot; either both parties agree on the published rate as the source of truth, or the trade is split into a pre-volatility and post-volatility portion.

## Decision Boundary

- Both captured from same tuple within the publication window: agreed.
- One captured from the window and one from before or after: not agreed in volatile conditions; agreed in stable ones if drift is below tolerance.
- Both captured outside the window: not agreed; the captures are not the reference rate.
- No tuple recorded: unknown; capture is at best approximately the reference, never exactly.

## Operational Effect

The invariant couples settlement amounts to a capture instant that varies with each party's data infrastructure. The instance's correct posture is to store the source tuple and back-reference captures to publication, not to local receipt.

**Trap.** Specify "the 4pm London fix". The reference is a window, not an instant, and the two parties' capture within the window can differ. The fix must be specified as a published tuple with the exact instant, not as a colloquial time.

```python
from dataclasses import dataclass


class RateSnapshotSkewError(RuntimeError):
    """Raised when two parties capture an FX rate at different publication instants."""


@dataclass(frozen=True)
class FxSourceTuple:
    publisher: str
    publication_instant: str
    window_seconds: int


@dataclass(frozen=True)
class FxCaptureGate:
    instance_source: FxSourceTuple
    counterparty_source: FxSourceTuple
    instance_capture_offset_seconds: int
    counterparty_capture_offset_seconds: int
    volatile_regime: bool = False

    def verify(self) -> bool:
        if self.instance_source != self.counterparty_source:
            raise RateSnapshotSkewError(
                f"source tuple mismatch instance={self.instance_source} "
                f"counterparty={self.counterparty_source}"
            )
        window = self.instance_source.window_seconds
        if self.instance_capture_offset_seconds > window:
            raise RateSnapshotSkewError(
                f"instance capture offset {self.instance_capture_offset_seconds}s "
                f"exceeds publication window {window}s"
            )
        if self.volatile_regime and abs(
            self.instance_capture_offset_seconds - self.counterparty_capture_offset_seconds
        ) > 0:
            raise RateSnapshotSkewError(
                "volatile regime with non-identical capture offsets: rate may diverge"
            )
        return True


def dispatch_fx_mode(gate: FxCaptureGate) -> str:
    try:
        gate.verify()
    except RateSnapshotSkewError:
        return "bind-to-published-rate"
    return "snapshot-rate"
```