Programmable settlement, explained without the jargon

Every trade has two halves: the asset changes hands, and the money changes hands. For decades those two halves have lived in different systems, run by different institutions, on different clocks. The gap between them is where risk, cost and delay quietly accumulate.

Programmable settlement closes that gap. Instead of two separate instructions that are reconciled later, both legs are tied together so that either both happen or neither does.

Why the gap exists

When you buy a bond, three things need to line up. The seller must actually own it, the buyer must actually have the cash, and someone has to update two ledgers. Because those ledgers are separate, the industry settled on a waiting period, commonly two business days, during which everybody hopes nobody defaults.

The cost of waiting

Waiting is not free. Capital sits idle, collateral is posted against risk that may never materialise, and operations teams spend their mornings chasing breaks.

Model	Typical delay	Who carries the risk
Legacy, two ledgers	T+1 to T+2	Both counterparties
Netting via a clearing house	T+1	The clearing house
Atomic, programmable	Seconds	Nobody, by construction

What changes in practice

Nothing about the trade itself changes. What changes is how the two legs are instructed:

1. The buyer and seller agree the terms, exactly as today.
2. Both legs are locked into a single conditional instruction.
3. A check confirms the asset and the cash exist and are eligible.
4. Both legs are released together, or the whole instruction is cancelled.

The best settlement system is the one your operations team stops thinking about.

A note on regulators

Most of our early conversations were not about technology at all. They were about what evidence would satisfy a supervisor that the new flow is at least as safe as the old one. We now start every project by writing that evidence down.

instruction:
  legs: [asset_transfer, cash_transfer]
  condition: all_or_nothing
  timeout: 15m
  audit: append_only

If you want the longer version, our field guide covers it in detail. For now, the short answer is: fewer steps, fewer failures, one trail.