The overnight batch completed on time. The custodian still received the allocation too late.
When a market moves to T+1 settlement, the regulators talk about reduced counterparty risk and lower margin requirements. Inside the enterprise architecture team, the conversation is entirely about the job scheduler. The batch window did not shrink. It disappeared.
For decades, the overnight batch was a buffer. It absorbed variance. A late trade, a mismatched allocation, a failed foreign exchange execution, a counterparty delay—all of it could be fixed before the settlement window opened the next morning. T+1 removes the buffer. Every exception that used to be absorbed now propagates directly to the settlement process. An operations queue is just a human batch process, and it does not scale when the window closes in the middle of the trading day.
Most firms spend their capital upgrading the settlement engine. The settlement engine is the easy part. The critical path is the affirmation file that arrives at 3:47 PM when the funding cut-off is at 4:00 PM. The affirmation and matching layer—often file-based, often managed by a legacy middle-office vendor—is where the window actually collapses.
Hardware will not save a sequential chain. Upgrading the database or adding cores to the mainframe only works for parallel workloads. If a job cannot run until a flat file arrives from the custodian via SFTP, faster processors do nothing. The critical path is locked by external dependencies.
In a T+2 world, you settled the security, calculated the exact cash requirement, and then executed the foreign exchange trade to fund it. T+1 breaks that sequence. Funding a T+1 settlement requires executing the currency trade almost simultaneously with the equity trade, based on estimated cash positions, or paying steep premiums for same-day liquidity facilities. The treasury team is now in the affirmation business.
Then there is the securities lending recall. A recall has to settle before the sale settles. In a T+2 environment, the lending desk had a full day to initiate the recall and recover the position. In T+1, the chain is impossible unless the recall is initiated intraday. The lending desk has to know about the sale earlier, which means the allocation has to happen earlier, which means the affirmation has to happen earlier. The architecture diagram shows the systems. It does not show the dependency chain that most program managers do not discover until the first live day.
A global fund trading in multiple markets does not have one settlement clock. It runs several. One order may produce trades in a T+1 market, a T+2 market, and a market observing a local holiday. Each trade arrives with a different market calendar, a different currency obligation, and a different set of intermediary cutoffs.
The batch scheduler has to know which market a trade belongs to, which cut-off applies, and which exception path to follow. This is not a scheduling problem. It is a data model problem. The trade has to carry its settlement cycle as a first-class attribute, and the workflow has to route on that attribute. The batch scheduler, configured to run a monolithic end-of-day XML file, cannot do this.
Internal processing speed is irrelevant if the external dependencies are slow. Your order management system can be event-driven. Your custodian’s matching engine might still be file-based. Your prime broker’s API might be available, but the rate limits make it unusable for intraday matching. The vendor documentation says real-time. The rate limits say eventually.
You are integrating against their roadmaps, not their current systems. When a global custodian moves their end-of-day file generation from 6:00 PM to 8:00 PM to accommodate their own legacy constraints, they consume your entire processing buffer. The vendor’s roadmap is your roadmap.
When the APIs do not talk to each other, the operations team talks to the counterparty. The ops team becomes the integration layer.
An operations manager looks at the runbook for the new settlement cycle. The runbook has forty-seven steps. Eleven of them are manual. Four of those manual steps involve calling someone. Two of those calls are to counterparties in different time zones. The runbook was written for T+2. It has not been updated. The dashboard shows the queue size, but it does not show which exceptions will miss a market cutoff in the next hour.
You cannot solve a sequencing problem with throughput. Running a monolithic batch process four times a day instead of once causes database locks and impacts trading system performance. True micro-batching requires decoupling the ingestion layer from the core ledger.
The firms that survive the transition are the ones that move affirmation and allocation as close to the point of execution as possible. They separate the cash ledger update from the final settlement confirmation. A shadow ledger listens to real-time execution messages from the trading desk and calculates estimated funding requirements instantly. They break the monolithic end-of-day file into hourly delta files.
End-of-day reporting, regulatory archiving, and performance attribution can remain in the batch window. You only need to stream the critical path: execution, allocation, affirmation, and funding.
T+1 is a rehearsal for T+0. If you solve T+1 by making the batch faster, you will solve T+0 with batch. The architecture decisions you make for the next twelve months determine whether you can absorb continuous settlement without another rebuild.