--- title: "The Day the Money Moves" description: "When you buy a share, you don't own it the moment you click. A plain-language story of trade settlement, T+1 and T+2, why holidays in two countries can push a payment back a day, and what building MarketClock taught me about dates that have a history." author: "Syed Ahmer Shah" date: 2026-10-24 url: https://ahmershah.dev/blogs/the-day-the-money-moves tags: ["marketclock", "settlement", "dates", "finance", "backend", "software-design", "engineering-logs"] series: "The Engineering Logs" (part 18) --- # The Day the Money Moves _Why buying a share takes longer than clicking a button, and what one Christmas trade between New York and London taught me about counting days_ ![A settlement date, Tuesday 29 December 2026, shown large in gold on a dark MarketClock calculator, beside the title The Day the Money Moves](https://ahmershah.dev/blog/the-day-the-money-moves/cover-fe81aba4.webp) Imagine you buy a used car. You shake hands on Monday, but the money leaves your account on Wednesday, and that's the day the keys and the papers become yours. For two days, you've agreed to the deal but nothing has actually moved. Buying a share works the same way. When you click "buy", you've agreed a price. The share isn't yours yet, and the seller hasn't been paid. The actual swap happens a little later, on a day called the settlement date. I spent October building [MarketClock](/blogs/marketclock-case-study-trading-days-settlement), a tool whose job includes working out that date for 30 stock exchanges. I thought it would be the easy part. It wasn't, and the reasons are surprisingly human. * * * ## T plus one, T plus two Traders write settlement as **T+1** or **T+2**. T is the trade date, the day you clicked. The number is how many business days later the money and the shares swap. In the United States today it's T+1: buy on Monday, settle on Tuesday. In London it's T+2: buy on Monday, settle on Wednesday. That sounds like simple arithmetic until you remember the word *business*. A business day is a day the market is open. Weekends don't count. Holidays don't count. And countries don't all take the same holidays. ## A Christmas trade Here's the example that convinced me this was worth building properly. Say a fund places an order on Wednesday, 23 December 2026, that involves both New York and London. It's on a two-day cycle, so it needs two days on which both markets are open. - **Thursday 24 December.** Christmas Eve. Both markets open, though both close early. It counts. One day. - **Friday 25 December.** Christmas Day. Both closed. - **Saturday 26 and Sunday 27.** The weekend. - **Monday 28 December.** New York is open. London isn't: Boxing Day fell on a Saturday, so the holiday moves to Monday. It doesn't count, because London has to be open too. - **Tuesday 29 December.** Both open. Two days. That's the settlement date. If you'd counted on your fingers you'd probably say Monday the 28th. A spreadsheet that only knows American holidays would say the same. It would be wrong by a day, and in finance a day means someone's money sits somewhere it shouldn't, or a trade fails and has to be fixed by hand. ## The rule changed while nobody was watching The second surprise was that the number itself moves. Until May 2024, the United States settled on T+2. On 28 May 2024 it switched to T+1. The UK has announced it will make the same change in October 2027. Now picture a back office checking a trade from 2023. If their software only knows today's rule, it says T+1, and it's wrong, because that trade was made when the rule was T+2. Old trades come up constantly: audits, disputes, tax reports, a client asking why their money arrived when it did. So in MarketClock, a settlement rule isn't just a number. It's a number with a start date and a link to the official announcement. Ask about a 2020 trade and you get T+2. Ask about last week's and you get T+1. And under every answer it shows which rule it used, so you can click through and read it yourself. ## Not everyone agrees what day it is The last piece is time zones, and it's the one that catches even careful people. When it's 9 p.m. on a Friday in New York, it's already Saturday morning in Tokyo. So "is the market open today?" has no single answer. Each exchange has its own "today", and MarketClock reads every market's date in that market's own time zone before asking anything else. It sounds obvious written down. In code, it's very easy to ask "what's today?" once, using the server's clock, and then apply that one date to every market in the world. I nearly did. * * * ## What it taught me Building this changed how I think about dates in any software, not just finance. Three habits stuck. **A date rule has a history.** Weekends move, settlement cycles shorten, holidays get added. Store the rule with the day it started, not just the rule. **Count days the way the business does.** "Two days later" almost never means two calendar days. Ask whose days, and which ones count. **Show your working.** When a tool can say not just "Tuesday" but "Tuesday, because London was closed on Monday, under this rule, from this source", people stop double-checking it by hand. That trust is the whole point. If you've ever wondered why money takes "a couple of days" to move, now you know: somebody, somewhere, is counting the days that count. The full build, the architecture, the data checks and the mistakes, is in the [MarketClock case study](/blogs/marketclock-case-study-trading-days-settlement). --- *Originally published at https://ahmershah.dev/blogs/the-day-the-money-moves — © Syed Ahmer Shah*