Settlement Fails and CSDR Penalties Under T+1: Instrumenting the Exception Queue

The CSDR penalty invoice arrives monthly, weeks after the fails that caused it. By then there is nothing to do but pay. Compressing the settlement cycle to T+1 will make that invoice larger, and the only useful response is to stop treating fails as something you report and start treating them as something you predict.

ESMA has recommended 11 October 2027 as the date the EU moves to a T+1 settlement cycle. The consequence for operations is not subtle. Halving the time between trade and settlement removes most of the slack the middle office currently uses to fix a mismatched instruction, source a security, or fund a shortfall before intended settlement date. Less time to intervene means more trades fail, and under the CSDR settlement discipline regime, more fails means more cash penalties. The two curves move together, and after-the-fact reporting does nothing to bend either.

What the penalty regime actually charges you for

Cash penalties under CSDR went live on 1 February 2022. The mechanic is simple and unforgiving: for every business day an instruction fails to settle, from intended settlement date until it actually settles, a penalty accrues. It is calculated on the value of the failing transaction at a daily rate that depends on the instrument, ranging from around 0.1 basis points for sovereign bonds up to 1.0 basis point for liquid shares. The penalty runs every day the fail persists. Mandatory buy-ins remain on the statute book under the CSDR Refit, but as a last-resort tool that is not currently switched on, so for now the live financial exposure is the daily penalty.

Read that as an engineer rather than a lawyer. The regime prices two things you can influence: the probability that a trade fails, and the number of days it stays failed. A monthly reconciliation captures neither in time to act. What manages the exposure is a system that scores open trades before intended settlement date, surfaces the ones most likely to fail, and puts them in front of a human while there is still a day to fix them. That system is an exception queue, and building it well is an architecture problem, not a compliance one.

The signals that actually predict a fail

Most fails are not random. They cluster around a small number of causes that are visible in data you already hold, if you are willing to join it up. The ones worth scoring on:

• Instruction status. Is the trade matched at the CSD or the custodian, and how late in the cycle did it match? Unmatched or late-matched instructions are the single strongest predictor. A trade still unmatched on the afternoon of trade date under T+1 is already in trouble.
• Standing settlement instruction quality. A mismatched or stale SSI produces an instruction that will not pair. If your SSI master data is dirty, you are manufacturing fails before the trade is even booked.
• Predicted inventory position. Will the delivering account actually hold the securities, or the cash, at intended settlement date? A projected shortfall against pending deliveries is a fail waiting to happen.
• Counterparty history. Trailing fail rates by counterparty and by instrument are not gossip; they are a calibrated prior. Some names fail more, and the queue should know it.

None of this needs a machine-learning platform to start. A transparent, weighted score built from these signals will beat a model nobody trusts, because the desk has to act on the output and will only act on a score it can interrogate. Fit the weights later, once you have enough matched history of settled versus failed trades to calibrate against. Start explainable.

Prioritise money at risk, not raw count

The mistake that kills exception queues is ordering them by probability alone, or worse, by arrival time. A hundred small fails on liquid, easily-borrowed stock matter less than one large fail on an illiquid line that will penalise every day until it settles. The queue has to rank on expected penalty exposure: probability of failing, multiplied by the notional, multiplied by the applicable daily rate, multiplied by the days you expect it to stay failed. That single number tells the desk where an hour of attention returns the most avoided penalty. Everything else is noise dressed as urgency.

"""Fails-prediction scoring over settlement-status data.

Scores open trades by probability of failing at intended settlement date (ISD)
and expected CSDR cash-penalty exposure, then orders the exception queue so the
desk works the trades that move the most money and risk first.
"""
from dataclasses import dataclass
from datetime import date

# Daily CSDR penalty rates (basis points) by instrument class. ILLUSTRATIVE
# placeholders only -- replace with the current Delegated Act annex values
# before use, and re-check when the ESMA penalty-mechanism amendments apply.
PENALTY_BP = {
    "liquid_share": 1.0,
    "illiquid_share": 0.5,
    "sme_growth_share": 0.25,
    "corporate_bond": 0.20,
    "government_bond": 0.10,
}

@dataclass
class OpenTrade:
    trade_id: str
    instrument_class: str
    notional_eur: float
    isd: date
    ssi_matched: bool             # standing settlement instruction paired
    inventory_shortfall: bool     # projected securities/cash short at ISD
    counterparty_fail_rate: float # trailing fail rate, 0.0-1.0
    partial_eligible: bool

def fail_probability(t: OpenTrade) -> float:
    """Transparent, explainable score. Calibrate the weights against your own
    settled/failed history before you let it drive intervention."""
    p = 0.02
    if not t.ssi_matched:
        p += 0.45
    if t.inventory_shortfall:
        p += 0.40
    p += 0.30 * t.counterparty_fail_rate
    return min(p, 0.99)

def expected_penalty_eur(t: OpenTrade, p_fail: float, fail_days: int = 2) -> float:
    rate = PENALTY_BP.get(t.instrument_class, 1.0) / 10_000
    return round(p_fail * t.notional_eur * rate * fail_days, 2)

def score_queue(trades: list[OpenTrade]) -> list[dict]:
    rows = []
    for t in trades:
        p = fail_probability(t)
        rows.append({
            "trade_id": t.trade_id,
            "p_fail": round(p, 3),
            "expected_penalty_eur": expected_penalty_eur(t, p),
            "auto_partial": t.partial_eligible,
        })
    # Rank on money at risk, not on count or arrival time.
    return sorted(rows, key=lambda r: r["expected_penalty_eur"], reverse=True)

The queue has to close the loop, not just rank

A ranked list is half a system. The other half is the actions the desk takes and the fact that the queue watches whether they worked. For a predicted fail, the interventions are known: chase the match, correct the instruction, source the securities through a recall or a borrow, fund the cash, or flag the trade for partial settlement so at least the deliverable portion settles and stops accruing. ESMA’s October 2025 amendments to the settlement discipline standards push exactly this direction, making auto-partial settlement and hold-and-release mandatory CSD functionality, with the pre-settlement timing rules due to apply from December 2026 and the CSD changes from the October 2027 cutover. The queue should know which trades are partial-eligible and route them accordingly, rather than letting a whole instruction fail because one leg is short.

This is where the exception queue stops being a report and becomes an operational control. It feeds off the same clean reference data that the rest of the T+1 programme depends on: matched SSIs, timely allocations and confirmations, and a projected inventory position accurate enough to trust. Get the standing settlement instructions right as master data cleaned before T+1, hit the trade-date allocation and confirmation windows that the latency budget imposes, and the queue has good inputs to score. Feed it late, mismatched data and it will faithfully rank garbage. The queue is only as good as the settlement data underneath it, which is why it belongs inside the wider settlement-readiness programme and not bolted on afterwards.

Measure it against the invoice

The test of whether any of this works is not the sophistication of the score. It is whether the penalties the CSD charges you next month are the ones the queue flagged this month and the desk chose not to fix, rather than a monthly surprise you reconcile after the money has gone. Predicted, prioritised, and consciously accepted or resolved is a managed exposure. Discovered on an invoice is a failure of instrumentation. Under T+1 there will be more fails to manage and less time to manage each one, and the firms that treated the penalty regime as a reporting obligation rather than a real-time signal will find that out the expensive way.