Core settlement infrastructure designed for speed, finality, and auditability across digital commerce.
Authorization is a quick yes-or-no. Settlement is where value actually moves — and it is where cost, delay, and reconciliation failure concentrate in legacy rails. Getting settlement right is the difference between a payment that looks complete and one that is provably final.
Legacy rails often confirm an authorization long before value is truly final, leaving a window where a payment can still fail or reverse. That gap forces every downstream system to hedge against outcomes that have not actually settled.
Funds typically pass through a chain of correspondents and processors, each adding cost, latency, and a private ledger no counterparty can fully see. When something breaks, tracing it means reconstructing state across systems that were never designed to agree.
Because state lives in many places, institutions spend enormous effort reconciling what happened after the fact. This reconciliation debt compounds with volume, turning routine disputes into manual, time-consuming investigations.
Every instruction moves through an explicit, observable sequence of states. Each state has a precise definition and emits a defined set of data, so any participant can reconstruct exactly what happened and when. The model below describes design intent, not timing commitments.
An instruction is accepted and assigned a durable identifier. Emits: instruction ID, source and destination references, amount and currency, and the initiating actor.
The instruction is evaluated against compliance and risk controls before any value is committed. Emits: screening decision, applied policy references, and any hold or escalation markers.
Required funds or credit are confirmed and the instruction is cleared to proceed. Emits: authorization result, funding source reference, and the authorized amount.
Value is actively moving across the underlying rail or network. Emits: settlement leg identifiers, intermediate state transitions, and the currently responsible party.
Value has moved irrevocably and the instruction reaches a terminal success state. Emits: finality confirmation, settled amount, and the immutable settlement record reference.
The settled instruction is matched against external records and internal balances with no remaining discrepancy. Emits: reconciliation match reference, balance impact, and closure marker.
Terminal states beyond the success path: Rejected (screening or authorization declines before settlement), Returned (value moves back to source after entering settlement), and Reversed (a previously settled instruction is unwound under defined conditions). Each terminal state is explicit and independently observable.
The rail is built around a small set of principles that make settlement predictable, replayable, and auditable. Each principle is a design commitment, expressed here alongside its implementation intent.
Settlement Rails is being developed in deliberate phases. Each phase widens capability while preserving the same deterministic, auditable core. The sequence below reflects direction, not a delivery schedule.
Establish the deterministic state machine, immutable event log, and core settlement primitives that everything else builds on.
Open the rail to a limited set of design partners under close supervision, hardening controls and observability against real instruction flow.
Extend settlement across additional currencies, methods, and value types, broadening reach while keeping finality semantics consistent.
Expose composable settlement building blocks so partners can express richer flows and conditional value movement directly on the rail.
Settlement Rails is in active development. If you are building where finality and auditability matter, we would like to hear about your use case.