Settlement exceptions are expensive, operationally disruptive, and often preventable. The industry has accepted a level of exception volume that reflects the design of its infrastructure, not the complexity of its instruments.
That distinction matters. When exceptions are treated as a cost of doing business, the response is headcount: more operations staff to catch, investigate, and repair breaks before they become failed trades. When exceptions are understood as a structural outcome of fragmented, manual post-trade processes, the response differs. It is architectural.
The data now supports the architectural argument more clearly than ever. Research published in 2025 by Euroclear found that 21% of settlement failures are caused by data issues, incorrect or stale data preventing trade matching. It is the second-largest cause of settlement failures, and it is one that better infrastructure design can directly address.
What follows is a three-phase framework for doing so.
Key Takeaways
- 21% of settlement failures are caused by data issues preventing trade matching. This is the most directly addressable category of exception at scale.
- Elevated settlement fail rates across EU markets, ranging from 2% for sovereign bonds to over 15% for certain asset classes such as ETFs, a range that reflects structural causes.
- Over the last decade, settlement failures through direct penalties and resolution expenses, operational workload, and business risk have cost the industry a jaw-dropping US$914.7 billion
- The transition to T+1 settlement compresses the window available to resolve exceptions before they become failed trades, making pre-exception prevention the only viable strategy at scale.
- The FINOS Common Domain Model (CDM) is the data standard that makes deterministic, exception-resistant post-trade processing possible.
Start With The Exceptions Banks Can Prevent
Before designing a solution, it is worth being precise about the problem.
ESMA’s November 2024 assessment of the EU settlement cycle documents persistently elevated settlement fail rates across EU markets, ranging from approximately 2% for sovereign bonds to over 15% for certain asset classes such as ETFs, despite improvements in efficiency in certain markets. That range encompasses a variety of causes: counterparty credit events, collateral shortfalls, operational errors, and data failures. These causes are not equally tractable.
Of all settlement failures, 21% were caused by data issues: incorrect or stale Standing Settlement Instructions (SSIs) and mismatched trade data preventing matching. That category is directly addressable through better data architecture.
This should shape how banks prioritise investment. Data-driven settlement failures are not best addressed through additional manual repair capacity. They require a shared trade state, standardised data, and deterministic lifecycle automation.
CSDR (Central Securities Depositories Regulation) creates the financial case for urgency. Cash penalties for settlement failures in EU markets have been in place since 1 February 2022, and ESMA finalised its technical advice recommending increases to penalty rates in November 2024, with the European Commission expected to amend the delegated regulation accordingly. For institutions with persistently elevated exception rates, the regulatory cost compounds each time data issues cause a preventable fail.
Why T+1 Changes the Calculus But Not the Root Cause
The shift in the UK and EU to T+1 settlement in October 2027 is frequently framed as the reason banks need to address exceptions. That framing is partially correct and partially misleading.
T+1 does not create new categories of settlement exceptions. The data mismatches, amendment processing errors, and incorrect settlement instructions that cause exceptions under T+2 cause the same exceptions under T+1. What changes is the time available to catch and resolve them.
Under T+2, a manually managed exception management workflow had two business days to surface a break, investigate the cause, and repair it before settlement failed. That window was not comfortable, but it was workable with sufficient headcount.
The consequence is a shift in strategic priority. Under T+2, exception management was a viable operational discipline. Under T+1, and increasingly under proposals for T+0 in certain markets, the only viable strategy is preventing exceptions before they occur. That requires deterministic lifecycle processing rather than more manual efforts.
The implications of T+1 for exception management strategy are explored in depth in our analysis of why exception handling will make or break T+1 settlement.
The Data Architecture Problem Behind Settlement Exceptions.
The 21% of failures caused by data issues is, unfortunately, a predictable output of how most banks’ post-trade infrastructure is designed.
Post-trade activity at many institutions runs across a fragmented stack of disconnected systems, each maintaining its own version of the trade state, often not authoritative. When a trade is executed, its data propagates across multiple downstream systems: trade capture, confirmation, matching, risk, regulatory reporting, and settlement instruction generation. Each system may represent the same trade slightly differently, using its own data model, its own field conventions, and its own interpretation of ambiguous terms.
In that environment, data quality problems are structural. A mismatch in how two systems represent a floating-rate methodology, or how each applies a holiday calendar to a critical date, can pass schema-level validation and still produce a break at matching. The exception is caused by the absence of a shared, semantically consistent trade record from which all downstream processes derive.
Barclays’ post-trade transformation, documented in Camunda’s December 2024 case study, shows how a legacy mix of monolithic systems and vendor platforms made post-trade processing hard to support, costly to change, and vulnerable to growing trade volumes and regulatory pressure.
Addressing this at the source requires a different starting point: the trade record itself.
The case for a shared data foundation in post-trade is examined in detail in Why Automating Post-Trade Workflows Requires a Shared Data Foundation.
CDM as the Foundation for Exception-Resistant Post-Trade Processing
The FINOS Common Domain Model (an open standard stewarded by FINOS and developed with ISDA, ICMA, and ISLA), provides a machine-readable representation of financial trade events and lifecycle processes.
It is the data architecture that makes deterministic, exception-resistant processing possible. Most trade matching systems validate at field level: they confirm that required fields contain data of the correct type, but not that the economic meaning of those fields is consistent between counterparties.
A mismatch in floating rate methodology or holiday calendar application can pass field-level validation and still produce a break. CDM-native, object-level matching compares the full semantic content of a trade, isolating discrepancies before they propagate into settlement exceptions. CDM also embeds lifecycle logic directly in the data model.
When a reset, amendment, or corporate action occurs, the contractual processing parameters are already encoded, applied deterministically, the same way, every time, eliminating the manual interpretation step that drives the majority of processing errors in non-standardised environments.
A Three-Phase Framework for Reducing Settlement Exceptions
The following framework addresses settlement exceptions across the three categories that account for the largest share of preventable exception volume: data misalignment at matching, processing errors in amendments and lifecycle events, and incorrect settlement instruction generation. Each phase builds on the last. None requires replacing existing infrastructure.
Phase 1: Establish the Unified Trade Record
The most common source of data-driven settlement exceptions is a fragmented trade record. Multiple systems hold conflicting versions of the same trade state, and lifecycle events are applied against whichever version happens to be consulted at the time.
Phase 1 addresses this at the source. The objective is to establish a single CDM-based authoritative trade state (a Unified Trade Record), shared by all parties to the trade and by all downstream consumers of the trade data.
Tokenovate’s Workflows-as-a-Service connects to existing infrastructure via APIs, creating the Unified Trade Record as an overlay that draws from existing systems without displacing them. Each system retains its existing function; the Unified Trade Record becomes the shared reference point from which all lifecycle processing derives.
The operational benefit is foundational: for the first time, every participant in the post-trade lifecycle is working from the same version of the trade. The structural condition that produces data-driven exceptions is removed.
Phase 2: Automate Matching and Amendment Processing
With a Unified Trade Record established, Phase 2 activates two of the highest-impact exception reduction workflows: CDM-native trade matching and affirmation, and automated amendment processing.
Trade matching and affirmation: CDM-native, object-level matching compares the full semantic content of each trade against the counterparty’s record, not just the field schema, and the economic meaning. Discrepancies are isolated proactively, before they enter the lifecycle and generate downstream exceptions. And as we’ve seen before, 21% of settlement failures are pointing to data and matching issues, something Phase 2 directly targets.
Amendment automation: When a trade is amended, a change to rate, term, collateral basket, or other contractual term, the agreed change must be applied consistently across all records. In manual environments, this requires coordinated updates across multiple systems, each with its own data model. The result is frequently a temporary divergence between counterparty records, and often a permanent one if the manual update is missed or misapplied. Automated amendment processing applies agreed changes synchronously across the Unified Trade Record, once, deterministically, with no manual step and no divergence between counterparty states.
Phase 3: Close the Lifecycle with Deterministic Event Processing
Phase 3 extends automation to the remaining high-exception-volume lifecycle events: fixings and resets, corporate actions, and settlement instruction generation.
Fixings and resets: Floating-rate instruments require periodic rate fixings and, in some cases, holiday calendar adjustments. In manual environments, these calculations are performed by operations teams, compared against counterparty results, and reconciled when they differ. Automated reset processing applies the contractual fixing logic deterministically, using parameters encoded in the CDM trade representation. Both sides receive the same result, produced by the same logic, with no opportunity for manual interpretation to introduce a discrepancy.
Corporate actions: Coupon payments, rights, and other corporate action events during the trade term require accurate entitlement calculation and downstream distribution coordination. These are among the most exception-prone events in the post-trade lifecycle, due to the complexity of calculating entitlements correctly against fragmented underlying records. With the Unified Trade Record in place, corporate action processing operates from a single, consistent view of the underlying position.
Settlement instruction generation: Determining cash and securities obligations and generating the DvP (Delivery versus Payment) instructions accordingly is the final exception surface. Automated transfer processing derives settlement obligations directly from the Unified Trade Record and routes instructions without manual intervention, eliminating the instruction errors that account for a material proportion of preventable settlement failures.
By the end of Phase 3, all three exception categories are operating under deterministic, CDM-native automation. The data-driven share of settlement exceptions is now addressed structurally rather than operationally.
What Structural Exception Reduction Looks Like in Practice
Reducing data-driven settlement exceptions structurally has consequences that extend beyond the exceptions themselves.
For banks operating in EU markets under CSDR, fewer data-driven exceptions means a lower penalty exposure profile, and the financial case for structural exception reduction is strengthened.
For operations teams, it means the exceptions that remain are predominantly genuine business events (counterparty credit issues, market disruptions, liquidity constraints), rather than data artefacts produced by fragmented infrastructure. That is a different kind of exception to manage: it requires judgment, not repair.
For banks approaching T+1 readiness, it means the settlement window compression that T+1 imposes is met by an architecture designed to prevent exceptions before the window opens, rather than by additional headcount racing to resolve them after it closes.
And as the Unified Trade Record accumulates a clean, consistent history of lifecycle events, the downstream benefits compound: regulatory reporting accuracy improves, counterparty communication becomes cleaner, and the audit trail required by regulators and counterparties is built automatically.
The question for most banks is not whether to address data-driven settlement exceptions. The regulatory environment, the settlement cycle compression, and the cost of the status quo make the case clearly. The question is how to sequence the investment to produce measurable operational improvement in the near term while building toward a more resilient post-trade architecture for the long term.