Publications | Heywood

Why T+1 is an operational control problem, not just a settlement deadline

Written by Matt Swinburne-Johnson | 02 September 2026

11 October 2027 is an important date for the UK investment industry, but there is a danger in focusing on it too much.

Treat T+1 primarily as a regulatory deadline and it becomes a programme with a start date, a project plan and, eventually, a reassuring green tick next to “implementation”. Treat it as an operational control challenge and the conversation becomes rather different.

The morning after T+1 goes live, firms still need to settle trades. Then they need to do it again the next day and the day after that. The real test is not simply whether the industry gets through the transition, but whether individual operating models can consistently control data, decisions, processes and exceptions at the speed the new settlement cycle requires.

The control window is shrinking

Under T+2, time itself has often formed part of the control environment. Overnight processing takes place, reconciliations identify discrepancies, operations teams investigate breaks, missing information gets chased and manual corrections are made before settlement.

T+1 compresses much of that activity. The FCA says firms will have around 80% less transaction-processing time once the UK moves to T+1 and is urging organisations to review their end-to-end arrangements now, including the manual processes and blockages that could prevent settlement within one business day.

What started as inefficiencies now become real operational risks. A control that depends on somebody spotting a problem tomorrow morning becomes much less effective when tomorrow morning is settlement day.

Settlement failures often start before settlement

The settlement process does not suddenly begin when securities and cash are due to move. What happens beforehand matters enormously.

Trade allocations, confirmations, data enrichment, standing settlement information, cash availability and other pre-settlement activities all influence whether a transaction can subsequently settle as intended. If information is missing, inconsistent or late, that problem travels with the transaction.

This makes T+1 a broader operating model issue. The quality of the final settlement outcome increasingly depends on the quality and speed of all the decisions and information that came before it.

That is also where fragmented operating models start to become difficult.

Critical logic often sits around the edges

Many firms have invested heavily in core technology while still allowing important pieces of operational logic to accumulate around it. A spreadsheet performs a particular calculation, a macro transforms a file before upload, a small application handles an awkward exception, or a process document tells an operator which decision to make under a particular set of circumstances.

None of these things necessarily looks alarming in isolation. In many cases they exist precisely because somebody found an ingenious way to make an imperfect process work.

The difficulty is that complexity builds quietly. Over time, an organisation can find itself with critical logic distributed across platforms, spreadsheets, databases, calculators, inboxes and people.

Under T+1, that creates problems with both speed and control. If a decision is being made outside the core environment, can the organisation demonstrate which rule was applied? Can it change that rule quickly? Can it test the change? Can it reproduce the outcome? Is the same rule being applied consistently every time?

When the answer is uncertain, there is work to do and not always enough time to do it.

Operational resilience raises the bar

The wider regulatory direction reinforces this point. The FCA's operational resilience framework requires firms in scope to understand and map the resources and dependencies supporting their important business services. Its more recent reviews have continued to emphasise that operational resilience is an ongoing obligation rather than a completed implementation exercise.

That distinction matters because resilience is not simply the ability to recover when something goes wrong. It involves understanding vulnerabilities, controlling dependencies and being able to continue delivering important services through disruption.

T+1 places another source of pressure on those systems and processes because it reduces the available recovery window. It therefore makes little sense to build a T+1 solution that simply moves existing manual activity faster or adds more people around a weak process.

The objective should be to make the process itself stronger.

Automation as a control mechanism

Automation is often discussed primarily as an efficiency play. The usual argument is that firms can do the same work with fewer manual touchpoints, save time and reduce cost. Those are all valid benefits, but under T+1 automation also becomes part of the control environment.

A defined rule applies the same logic every time. A validation happens when it is supposed to happen. A calculation does not depend on which spreadsheet version somebody opened. An exception can be identified immediately rather than waiting for a manual reconciliation.

When rules are transparent and governed properly, the organisation also has a much clearer record of what happened and why.

The FCA itself has said that automation will be key to a successful transition for most firms and has warned that supporting manual arrangements with additional staff can increase both operational costs and the risk of penalties. The point is not to automate everything. It is to automate the parts of the process where consistency and speed matter most.

Strengthening control without starting again

One understandable concern when technology enters a T+1 discussion is scale. Does fixing these problems mean replacing a core platform, launching a multi-year transformation programme or unpicking technology that works perfectly well for most of the process? In many cases, trying to build new automation directly into a core platform may not be the most practical route. Core systems can be complex, heavily governed and difficult to change quickly. Enhancements may depend on lengthy development cycles, specialist resources or third-party suppliers, and there is always a balance to strike between introducing new capability and protecting the stability of a business-critical platform.

A standalone rules-based layer provides another option.

Heywood Idiom can sit alongside existing technology and take responsibility for defined rules, calculations and decision logic. That can include logic currently sitting in spreadsheets or legacy tools, or business rules that are difficult to change within core systems.

The approach can be targeted. Identify the control weakness, understand the underlying rule, make that logic explicit, testable and repeatable, then integrate it with the systems already surrounding the process.

Idiom has been developed over more than 20 years and is used for complex, high-volume calculations and decision-making where accuracy, repeatability and auditability matter. Its use within settlement operations is an emerging application, but the underlying control challenge is familiar.

T+1 is certainly a race against the clock, but it is also a test of whether an operating model can control data, processes and exceptions at the speed settlement now demands. Passing that test will matter long after 11 October 2027.

Make operational control part of your T+1 plan

If you are assessing how T+1 will affect your controls, data, processes or exception management, Heywood can help you explore where greater automation could strengthen your operating model.

Speak to us about the areas of your settlement process creating the greatest concern, and we can look at how Idiom could be introduced alongside your existing technology to improve consistency, auditability and operational resilience.

Talk to Heywood about strengthening your T+1 operating plans.