T+1 settlement means trades settle one business day after execution. India completed this transition for equities in January 2023 under SEBI’s phased rollout, ahead of the United States’ 2024 move. The engineering consequence is specific: your systems must hold two truths simultaneously — what was agreed, and what has settled — and never confuse them.
Why this is an architecture problem, not a calendar one
Between trade and settlement lives a gap where money is promised but not moved. Your books show a purchase; the funds leave tomorrow; the securities arrive tomorrow. During that window, every report, margin calculation, risk number and reconciliation must know which truth it is reading.
Systems that store a single date column blur agreed against settled and produce the classic phantom: cash that is simultaneously spent and present. The buy has reduced your available balance in one report and not in another, and both queries are running against the same table, joined on the same column, by developers who each made a reasonable assumption.
The failure is quiet because both numbers look plausible. It surfaces when reconciliation against the broker contradicts one of them — usually at month-end, usually to someone senior, usually in a meeting.
The two-timestamp discipline
Every money event needs two dates recorded as separate facts:
Business time — when the thing was agreed. The trade date, the order date, the invoice date. This is what the commercial relationship refers to.
Settlement time — when value actually moved. Expected at first, then actual once confirmed. This is what the bank and the custodian refer to.
They are not interchangeable and neither is derivable from the other, because settlement can slip, fail, or be netted with something else. The ledger design lists single-timestamp storage among its expensive traps for exactly this reason.
With both recorded, positions become computable in either frame on demand: as-agreed for the commercial view, as-settled for the cash view, and the difference between them is a meaningful number in its own right — it is your pending-settlement exposure, which is precisely what a risk function wants to see.
The three states most systems miss
Pending settlement is a state, not a gap. Reports must be able to say “these obligations are agreed and not yet settled” as a category, because that is a real thing with a real value. Systems that only model settled and unsettled-forever have nowhere to put it.
Failed settlement is a first-class state too. When settlement fails, the agreed position and the actual position have genuinely diverged, and every downstream calculation needs to know which one it is reading. Treating it as an exception for someone to resolve by hand works at ten trades a day and collapses at a thousand.
Netted settlement is the one that catches people. Several trades settling as a single net movement means your one-to-one mapping between agreement and settlement no longer holds — the reconciliation has to match a set against a sum. Systems built on the assumption of one-to-one matching require rework precisely when volume makes netting worthwhile.
Compression pressure
Each step in settlement compression — T+5 to T+3 to T+2 to T+1, with same-day now being piloted — squeezes the operational slack that manual processes were quietly consuming.
Under T+2, a broken trade discovered on the afternoon of T had a day and a half of human time to fix it. Under T+1 that becomes hours. Under T+0 it becomes minutes, which means the fix has to be systematic rather than someone competent noticing. The manual reconciliation that survived T+2 dies at T+1: automated daily matching stops being a maturity milestone and becomes the minimum viable operation.
India ran this transition at retail scale while much of the world watched nervously, and the infrastructure lessons are worth studying rather than glossing over. The systems that coped were the ones that already separated agreed from settled; the ones that struggled were the ones where a single date column had been sufficient for years.
What this means if you are not a broker
Take the pattern rather than the vocabulary. Any business where an obligation is agreed at one moment and settles at another has a T+1 problem wearing different clothes:
Marketplace payouts on a settlement cycle — the seller’s earning is agreed at order, settled days later, and both numbers matter to different people. Subscription billing where a mandate presentation lags the invoice date. Lending disbursals scheduled forward. Card settlements arriving net of fees on the acquirer’s schedule.
In every one of those, the same three questions apply: are both dates recorded, can positions be computed in either frame, and does the reconciliation match on the settlement date rather than the agreement date? If the answer to any is no, you have the same phantom cash, just with a longer fuse and a less punctual regulator.
The marketplace case is the one I see most often outside capital markets, and it is instructive because the pain arrives from the seller’s side rather than the auditor’s. A seller sees an order confirmed on Monday and expects the money; your settlement cycle pays on Friday net of returns. If your system cannot show both the agreed earning and the settled payment as distinct facts, every support conversation becomes an argument about which number is real — and the seller is not wrong to ask.
The implementation checklist
Six things to verify in a system you are responsible for:
Both timestamps stored on every money event, as separate columns, with settlement time nullable until confirmed.
Positions computable in both frames — as-agreed and as-settled — with the report layer forced to state which it wants rather than defaulting silently.
Pending settlement as a reportable category, with its total exposed as a number someone monitors.
Failed and netted settlement modelled explicitly, not handled as manual exceptions.
Reconciliation matching on settlement date, against the broker or bank’s own settlement view, daily.
A test that catches the phantom. Assert that a trade agreed today and unsettled does not appear as available cash in any balance query. It is a five-line test and it prevents the single most expensive bug in this category — because that bug is invisible in normal operation and obvious only in hindsight.
The checklist is deliberately short because the discipline is small. What makes T+1 expensive is not complexity — it is that a single omitted column propagates into every report built afterwards, and by the time the contradiction surfaces, the wrong number has been quoted to people who remember it.
Related reading
/blog/ledger-design — where the two timestamps live · /blog/reconciliation-at-scale — matching on settlement date · /industries/wealth — portfolio accounting with this discipline built in · /work/portfolio-system — the production build
Questions I actually get
Is this only relevant to broking and capital markets?
No. Any business where an obligation is agreed at one moment and settles at another has this problem: marketplace payouts on a cycle, subscription billing with mandate delays, lending disbursals scheduled ahead, even retail card settlements. Capital markets simply have the shortest fuse and the strictest supervisor.
What exactly breaks with one date column?
Reports blur agreed against settled, so cash appears both spent and present. Margin and exposure calculations read the wrong position. And the reconciliation against the broker or bank has nothing to match against, because your record does not distinguish the two events it is trying to compare.
Does storing two timestamps solve it completely?
It is the necessary foundation, not the whole answer. You also need positions computable as-agreed and as-settled on demand, a pending-settlement state that reports treat as its own category, and reconciliation that matches on settlement date rather than trade date.
What happens when settlement fails?
It needs to be a first-class state rather than an exception someone handles by hand — because a failed settlement means the agreed position and the actual position have diverged, and every downstream number needs to know which one it is reading.
Will same-day settlement make this worse?
It compresses the operational slack further, so manual processes that survive T+1 will not survive T+0. The architecture requirement does not change; the tolerance for reconciliation done by hand disappears entirely.
Where do most systems get this wrong first?
In reporting rather than in the trade capture. Capture usually records enough; then a dashboard query joins on the wrong date and everybody trusts the resulting number because it looks plausible. The bug lives in the report, and it is invisible until reconciliation contradicts it.