Syed Ahmer ShahSyed Ahmer ShahSyed Ahmer ShahSyed Ahmer ShahSyed Ahmer Shah — home
  1. …
  2. Engineering Logs
  3. The Engineering Logs
  4. The Day the Money Moves
Part 18 of 19

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

Written by

Syed Ahmer Shah

Software Engineer

Oct 24, 20264 min read810 words—reading now▼
A settlement date, Tuesday 29 December 2026, shown large in gold on a dark MarketClock calculator, beside the title The Day the Money Moves
Read this articlevoice
Markdown

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, 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.

Also readCybersecurity Trends: Protecting Data in the Digital Age
HolidayOps: Building a Working Days API for 250 Countries

#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.

Find me across the web.

Same person, every platform

Work & code

  • ASPortfolioahmershah.dev
  • LinkedInin/syedahmershah
  • GitHub@ahmershahdev
  • AWSAWS Builder Center@syedahmershah
  • Crunchbasesyed-ahmer-shah
  • LinkedIn · Companycompany/syedahmershah

Writing

  • Dev.tosyedahmershah
  • Medium@syedahmershah
  • Hashnode@syedahmershah
  • Substack@syedahmershah
  • HackerNoonu/syedahmershah
  • CLCoderLegionuser/syedahmershah

Reviews & listings

  • Google Knowledge PanelSyed Ahmer Shah
  • Google Business Profileg.page
  • ClClutch
  • TpTrustpilot
  • DRDesignRush
  • TBTechBehemoths

Social

  • YouTube@ahmershahdev
  • Instagram@ahmershahdev
  • TikTok@ahmershahdev
  • Facebookahmershahdev
  • X@ahmershahdev
#marketclock#settlement#dates#finance#backend#softwaredesign#engineeringlogs
ShareXLinkedInRedditWhatsApp

← Previous in series

Cybersecurity Trends: Protecting Data in the Digital Age

On this page

  • T plus one, T plus two
  • A Christmas trade
  • The rule changed while nobody was watching
  • Not everyone agrees what day it is
  • What it taught me

The Engineering Logs

  1. 01The Edge Latency Lie: Solving Global Consistency
  2. 02Top 10 AI Tools Every Frontend Developer Should Know (2026 Guide)
  3. 03Change One Number. Take Everything.
  4. 04How Databases Work: From Tables to Query Execution
  5. 05The New Era of Software Engineering
  6. 06The Art of Object-Oriented Programming
  7. 07GleanGrid: Building a Pre-Order Marketplace for Farmers Markets
  8. 08The Last Mango Problem: Race Conditions in a Real Marketplace
  9. 09BookMyMovie: Building a Cinema Ticketing Platform
  10. 10One Seat, Two Buyers: Race Conditions, IDOR and Keys in a Cinema Booking System
  11. 11Zovita+: Building an Online Pharmacy That Adapts to Each Shopper
  12. 12The Discount That Knew You Were Hesitating: Rule-Based Personalisation in an Online Pharmacy
  13. 13RAG Retrieval Strategies on a 50k-Document Dataset: BM25 vs Dense vs Hybrid
  14. 14Inside the Database Stack
  15. 15HolidayOps: Building a Working Days API for 250 Countries
  16. 16The Weekend Is Not a Constant
  17. 17MarketClock: A Trading Calendar That Shows Its Work
  18. 17Cybersecurity Trends: Protecting Data in the Digital Age
  19. 18The Day the Money Moves

Up next

Keep reading.

All 57 articles→
  1. 01

    The Weekend Is Not a Constant

    Why 'is this a working day?' breaks so much software: weekends that differ by country and change over time, holidays that follow the moon, time zones that disagree about today, and the habits that kept my own date logic honest while building HolidayOps.

    Oct 18, 20265 minThe Engineering Logs

  2. 02

    The Discount That Knew You Were Hesitating: Rule-Based Personalisation in an Online Pharmacy

    How Zovita+ turns browsing into personal discounts without a machine-learning model: one visitor key for guests and customers, interaction counters, six offer rules, one pricing function for the bag and the charge, offers locked and redeemed once at checkout, guest-to-account merging, A/B tests, and the edge cases that shaped it.

    Oct 2, 202610 minThe Engineering Logs

  3. 03

    One Seat, Two Buyers: Race Conditions, IDOR and Keys in a Cinema Booking System

    How BookMyMovie makes sure one cinema seat is never sold twice, a guessed booking number shows nothing, and a leaked or missing key can't quietly break tickets: row locks, lock order, a NULL-tolerant unique key, status compare-and-set, idempotency, IDOR scoping, HMAC tickets, captcha step-up, and the bugs that still got through.

    Sep 29, 202611 minThe Engineering Logs

  4. 04

    The Last Mango Problem: Race Conditions in a Real Marketplace

    What happens when fifty people try to buy the last item, use a single-use coupon or book a nearly full pickup window at the same instant, the MySQL snapshot detail that almost overbooked a stall, and the quieter races that hide in stock forms, restocks and payments.

    Sep 27, 202610 minThe Engineering Logs

  5. 05

    MarketClock: A Trading Calendar That Shows Its Work

    How I built MarketClock on my own: a Flask and Next.js app that tells traders and back offices whether 30 stock exchanges are open, when they close early and when a trade settles, and that links every fact it stores to the page it came from.

    Oct 24, 20269 minThe Engineering Logs

  6. 06

    RAG Retrieval Strategies on a 50k-Document Dataset: BM25 vs Dense vs Hybrid

    How BM25, dense embeddings and hybrid search (RRF) behave on a 50k-document RAG corpus: working code, honest trade-offs, and when each one actually wins.

    Oct 5, 202611 minThe Engineering Logs

Available for new work · --:--:-- PKT

Have an idea?

sales@ahmershah.dev
Book a call WhatsApp +92 370 4831994

On this site

  • 01About
  • 02Education
  • 03Certificates
  • 04Skills
  • 05Projects
  • 06Experience
  • 07Services
  • 08Testimonials
  • 09Contact

Pages

  • Projects
  • Blog
  • Saved articles
  • RSS
  • Privacy Policy
  • Terms of Service
  • llms.txt

Elsewhere · official profiles

26 links

Professional

Work history, code and credentials.

  • in/syedahmershah
  • company/syedahmershah
  • @ahmershahdev
  • syed-ahmer-shah
  • syed-ahmer-shah
  • u/syedahmershah
  • @syedahmershah
  • AWS@syedahmershah

Coding & credentials

Problem solving, verified badges.

  • u/syedahmershah
  • syedahmershah
  • users/syedahmershah
  • learner/syedahmershah

Google & business

The official listings.

  • Google Business Profileg.page
  • Syed Ahmer Shah
  • syedahmershah
  • Beaconssyedahmershah
  • syedahmershah

Social (@ahmershahdev)

Build logs, clips, threads.

  • @ahmershahdev
  • @ahmershahdev
  • @ahmershahdev
  • ahmershahdev
  • @ahmershahdev
  • @bluesky.ahmershah.dev
  • ahmershahdev

Design

Interfaces and visuals.

  • syedahmershah
  • syedahmershah

Direct

  • sales@ahmershah.dev

    New projects & quotes

  • support@ahmershah.dev

    Support & help

  • syedahmershahofficial@gmail.com

    Personal

  • +92 370 4831994

    Phone · WhatsApp

  • Hyderabad, Sindh, Pakistan

    Remote-first · Asia/Karachi (UTC+5)

Resume ↗
SYED AHMER SHAH

© 2026 Syed Ahmer Shah. All rights reserved.

PrivacyTermsRSS
ahmershah.dev