Programmable Settlement Rails
Issue the payment instruction for a bilateral contract automatically when a pre-agreed condition is met, with a cryptographic proof for every instruction. The same instruction cannot be issued twice. The two parties pay each other directly; Tomorrow does not guarantee settlement.
Explore settlement rails →What is this?
Traditional bilateral OTC settlement involves emails, confirmation matching, and manual payment instructions. It's slow, error-prone, and leaves a compliance gap between trade execution and cash movement. Settlement Rails automates the instruction step. You define the conditions under which a bilateral payment falls due, and the system watches for the trigger. When it fires, Tomorrow, as calculation agent, issues a payment instruction from the paying party to the receiving party with a unique SHA-256 proof. The parties make the payment directly, and both can verify the record independently.
How it works
You define settlement conditions
Specify the trigger: a fixed date, a price crossing a threshold, or an observable event (index fixing, SOFR publication, binary outcome). Conditions are agreed bilaterally and attached to the contract record.
The condition sweep checks for triggers every 10 minutes
A background process runs every 10 minutes and checks date-based settlement conditions. When a condition is met, it is marked as met; nothing is paid until the payment instruction is issued.
Payment instruction issued — idempotency key generated, proof stored
A deterministic SHA-256 idempotency key is generated. The system checks for duplicates, then issues the payment instruction to the paying party and stores a hash-chained receipt. The parties pay each other directly.
Counterparty verifies the proof independently
Both parties receive the settlement receipt with its SHA-256 hash. Either party can verify the proof in the Settlement Proof Explorer at any time — no Tomorrow intermediary required.
Trigger types
Time-based
Payment date fixed at contract inception (e.g., "T+2 from SOFR fixing on 15 June")
Manual confirmation
Both parties confirm settlement eligibility — the system then issues the payment instruction, and the parties pay each other directly
Key facts
SHA-256 idempotency key
Every settlement has a unique deterministic key. Double-settlement is mathematically impossible.
Bilateral — no custodian
Tomorrow does not hold margin or escrow. Funds move on your existing banking rails.
Hash-chained receipts
Each receipt is chained to the prior one. The chain is your regulatory evidence.
10-minute condition sweep
Conditions are checked every 10 minutes around the clock. No manual monitoring needed.
FAQ
How does the system prevent double-settlement?
Every settlement attempt generates a deterministic SHA-256 idempotency key derived from the contract ID, trigger type, and trigger timestamp. The system checks for an existing settlement with that key before executing. If one exists — even from a retry or a race condition — the duplicate is silently dropped. The same settlement cannot execute twice.
Is there a central custodian?
No. Settlement Rails is bilateral — funds move directly between you and your counterparty. Tomorrow does not hold margin, escrow, or act as an intermediary for the cash. The system coordinates the trigger and records the proof; the actual payment instruction runs on your existing banking rails.
How can my counterparty verify a settlement?
Every settlement receipt includes a SHA-256 hash of the settlement record, hash-chained to the prior receipt. Your counterparty can independently verify the hash against the Settlement Proof Explorer — no Tomorrow involvement required. The chain is the evidence.