Automating Allocations and Confirmations for T+1: The Latency Budget

T+1 does not make your settlement process faster. It removes the night you have quietly been relying on to fix everything by hand.

The EU is scheduled to move to a T+1 settlement cycle on 11 October 2027, under the political agreement reached in June 2025 to amend the Central Securities Depositories Regulation. Treat the date as firm enough to plan against and the detailed market-practice cut-offs as still settling. The headline is simple: trades executed on Monday settle on Tuesday. The consequence is not. Every allocation, confirmation and affirmation that used to have an overnight window now has an afternoon. If your middle office currently closes those steps by working late on T+1 morning, that morning is gone.

Most readiness programmes I see assume existing straight-through processing will simply run faster against the shorter cycle. It will not. Straight-through processing that is 85 per cent automated has a 15 per cent manual tail, and that tail is precisely what the overnight window was absorbing. The work is not to speed the pipe up. It is to find where the hours the new cycle removes are currently being spent, and to move those steps from overnight batch to intraday event.

What T+1 actually removes is the night

Under T+2, the allocation-and-confirmation chain has the whole of trade date plus a comfortable slice of the following morning. A block trade is executed, allocated across underlying accounts, confirmed by the broker, affirmed by the buy side, and matched at the custodian or central matching utility. When any of that breaks, someone picks it up next morning and there is still a full day of settlement runway behind them.

Under T+1, the affirmation has to be complete on trade date. The US market, which moved in May 2024, works to a same-day affirmation benchmark of roughly 90 per cent affirmed by 21:00 Eastern on trade date. The EU has not fixed a single published cut-off, and the exact time will be set by central securities depositories and market practice closer to the move, so build to a configurable deadline rather than a hard-coded one. The direction of travel is not in doubt. Affirmation stops being a next-morning clean-up and becomes a same-day gate, and everything upstream of it has to finish in daylight.

The latency budget, hop by hop

The useful discipline here is to treat the shortened window as a fixed budget and account for every hop that spends it. From execution to affirmed, a typical institutional flow crosses several systems and at least two organisations:

1. Execution report received from the venue or executing broker into the order management system.
2. Allocation instruction generated and sent to the broker, splitting the block across accounts.
3. Confirmation returned by the broker against each allocation.
4. Affirmation issued by the buy side, agreeing the economics.
5. Matched instruction released to the custodian and on to the central securities depository.

Each hop has a latency, and the ones that hurt are rarely the network. They are the human ones: the enrichment step waiting for a standing settlement instruction that is stale, the allocation held because someone reviews block splits manually, the confirmation that sits unmatched because a counterparty reference does not agree. You cannot manage what you have not measured, so the first build is not automation at all. It is instrumentation: a timestamp on every message as it arrives and leaves, so you can see where the budget is actually being spent rather than where you assume it is.

Automating the allocation-to-affirmation chain

In FIX terms the chain is concrete. The buy side sends an AllocationInstruction (MsgType J); the broker acknowledges it (P) and returns a Confirmation (AK) against each allocation; the buy side affirms with a ConfirmationAck (AU). SWIFT ISO 15022 and ISO 20022 equivalents carry the same economics between the parties that speak them. Whatever the transport, the automation goal is identical: no allocation waits on a person unless an exception forces it to, and every message is timestamped so the same-day affirmation gate can be measured, not hoped for.

The following instruments the chain. It records each hop, reports per-hop latency, and flags any trade that will miss the affirmation cut-off while there is still time on trade date to intervene.

"""Instrument the allocation-to-affirmation chain against the T+1 budget.

Each post-trade hop is timestamped as it happens; the tool reports the gap
to a same-day affirmation cut-off and flags trades that will not make it.
"""
from datetime import datetime, timezone

# FIX MsgType maps to the post-trade stage it represents.
STAGES = {
    "J":  "allocation_sent",        # AllocationInstruction, buy-side to broker
    "P":  "allocation_acked",       # AllocationInstructionAck
    "AS": "allocation_reported",    # AllocationReport
    "AK": "confirmation_received",  # Confirmation, broker to buy-side
    "AU": "affirmed",               # ConfirmationAck, buy-side affirms
}

# Same-day affirmation cut-off. The US market works to a 21:00 New York
# benchmark; the EU equivalent will be set by CSD and market practice for
# the 11 October 2027 move -- keep it configurable, not hard-coded.
AFFIRMATION_CUTOFF = "21:00"  # expressed in the relevant market timezone

def hop_latencies(events):
    """events: list of (fix_msgtype, iso8601_utc_timestamp) in any order."""
    ordered = sorted(events, key=lambda e: e[1])
    out, prev_t, prev_stage = [], None, None
    for msgtype, ts in ordered:
        stage = STAGES.get(msgtype, msgtype)
        t = datetime.fromisoformat(ts).astimezone(timezone.utc)
        if prev_t is not None:
            out.append((prev_stage, stage, (t - prev_t).total_seconds()))
        prev_t, prev_stage = t, stage
    return out

def affirmation_slack(events, deadline_iso):
    """Minutes of slack against the cut-off; negative means it will breach."""
    affirm = next((ts for m, ts in events if m == "AU"), None)
    if affirm is None:
        return None  # not yet affirmed -- open exception
    t = datetime.fromisoformat(affirm).astimezone(timezone.utc)
    deadline = datetime.fromisoformat(deadline_iso).astimezone(timezone.utc)
    return round((deadline - t).total_seconds() / 60)

# Example: one block, executed then allocated, confirmed and affirmed.
trade = [
    ("J",  "2027-10-11T14:02:11+00:00"),
    ("P",  "2027-10-11T14:02:19+00:00"),
    ("AK", "2027-10-11T15:40:03+00:00"),
    ("AU", "2027-10-11T16:12:44+00:00"),
]

for a, b, secs in hop_latencies(trade):
    print(f"{a} -> {b}: {secs:.0f}s")

slack = affirmation_slack(trade, "2027-10-11T19:00:00+00:00")
print("affirmed" if slack and slack >= 0 else "AT RISK", slack, "min slack")

It is deliberately small. The point is not the tool; it is that the affirmation gate becomes a measured, per-trade property you can alert on intraday, rather than a number you discover the next morning when it is already too late to act.

Where the overnight steps hide

Once you instrument the chain, the batch dependencies surface quickly, and they are usually not in the trading systems. The reference data refresh that runs overnight and enriches allocations with settlement instructions is a classic: if it runs at 02:00, every trade booked after it is enriched with yesterday’s data, and under T+1 that is a same-day break waiting to happen. Clean, current standing settlement instructions are a precondition, not a nicety, which is why treating SSIs as master data and cleaning them before T+1 pays back directly in affirmation rates.

The same audit tends to find fee and commission calculations that run in an end-of-day cycle, a corporate-actions check that assumes overnight processing, and an FX leg funded on a timetable the shorter cycle no longer permits. Each is an overnight step that has to become an intraday one. This is why T+1 is an architecture programme, not a settlement tweak, and why it belongs inside a structured settlement-readiness programme for the middle office rather than a line item on an operations to-do list.

Measure the exceptions, not the happy path

The trades that automate cleanly were never your problem. The latency budget is spent almost entirely on exceptions, so the metric that matters is not average affirmation time but the distribution of the tail: how many trades are unaffirmed at each hour of trade date, why, and how quickly the queue drains. An exception surfaced at 16:00 can still be fixed on trade date; the same exception discovered at 08:00 the next morning is a probable settlement fail, and under CSDR that carries cash penalties. Instrumenting the exception queue so fails are caught before they crystallise is the same discipline applied one step further down the chain.

Build the affirmation gate as something you can see moving through the afternoon, and T+1 becomes a scheduling problem you can manage. Leave it as an overnight number, and the first time you learn a trade missed the window will be the morning the penalty lands.