T+1 settlement failures as a data problem, not a settlement problem

T+1 settlement is often discussed in terms of timelines, coordination and infrastructure, with a focus on whether systems can process trades more quickly and operate within a shorter settlement cycle.

This blog examines a different dimension: how T+1 settlement failures originate from the way trade and reference data is created, aligned and made available across systems. By the time a trade reaches settlement in a T+1 environment, it already depends on data that has passed through multiple systems, transformations and ownership boundaries.

The question is not only whether settlement can happen faster, but whether the data is complete, consistent and available on time. As such, T+1 settlement failures are not primarily a settlement problem, but a data problem.

T+1 settlement failures start before settlement

In day-to-day operations, failed trades rarely originate from a settlement engine not functioning as expected. They originate from instructions built on data that is incomplete, inconsistent or enriched too late in the process. This includes trades confirmed with outdated SSI, PSET derived differently across systems, or instrument identifiers that do not align between counterparties.

By the time a trade reaches settlement, it is already dependent on data that has passed through multiple systems, transformations and ownership boundaries. At that point, the outcome is largely determined.

Most T+1 settlement failures can be traced back to a small number of recurring data patterns. These patterns are not edge cases, but part of daily operations, often handled implicitly and only becoming visible when the time available to correct them disappears. The following examples show how these patterns surface under T+1.

Three data patterns behind T+1 settlement failures

1. Data that arrives too late

A trade may be confirmed internally while key enrichment still takes place afterwards. SSI may only be applied after confirmation, or allocations finalised once downstream processes have already started.

In these situations, the trade appears complete within one part of the process, but not across the full chain. By the time settlement instructions are generated, no time remains to align or correct discrepancies, leading to T+1 settlement failures.

2. Incomplete or inconsistent data

A counterparty may use an SSI that differs from the one stored internally, or a PSET may be missing or derived using outdated logic. Static data may also differ between front-office, middle-office and post-trade systems.

These inconsistencies often only surface at matching, when two valid versions of the same trade fail to align. Resolving them requires manual intervention, coordination across teams and, in some cases, external confirmation. In T+1, that resolution window is no longer available.

3. Data that does not reconcile

Instrument and reference data rarely exist in a single consistent form. The same instrument may be represented differently across systems, using ISINs, local identifiers or internal mappings. Vendors and counterparties may apply their own normalisation or classification logic.

In T+1, these differences lead directly to breaks in matching and reconciliation, particularly when different representations of the same instrument are assumed to be equivalent until they are not.

How data issues are absorbed in daily operations

T+1 efforts often focus on system upgrades and settlement capacity. These are necessary, but they do not address where most T+1 settlement failures actually originate.

Trades are often made to settle despite underlying data issues. Data is corrected late, enriched in multiple places, or implicitly aligned across systems through manual intervention. These adjustments are part of daily operations, not exceptions.

This creates the impression that processes are functioning as intended, while data issues are continuously absorbed in the background. In T+2, this remains manageable. In T+1, there is no time left to rely on these corrections, and the same issues surface as failed trades.

A more useful way to assess T+1 readiness

T+1 readiness becomes visible at the points where trades still require data to be adjusted to complete the process. This includes situations where breaks are resolved intraday, fields are aligned after matching, or outcomes depend on manual intervention or undocumented knowledge within operations teams.

This shows more than where processes rely on intervention. It shows where trades continue to progress even when the underlying data is not final. The issue lies at the point in the process where data is treated as complete.

Seen in this way, T+1 readiness comes down to identifying where this still occurs and shifting that point of completeness earlier in the process, so that matching runs on data that is already final rather than acting as the point where gaps are discovered.

Conclusion

T+1 settlement is often approached as a question of speed, coordination and system capacity. What determines whether a trade settles, however, is the quality and timing of the data on which it depends.

Trades rely on data that is enriched, corrected or aligned across systems, often after key process steps have already taken place. This allows trades to settle in T+2, but in T+1 they surface as failures because the time available to correct them no longer aligns with when the data needs to be accurate.

T+1 does not change how settlement works, but it exposes where it breaks. T+1 does not change how settlement works, but it exposes where it breaks. Addressing T+1 settlement failures requires ensuring that data is complete when it enters the process, rather than relying on corrections later. At BIQH, we focus on identifying and resolving market data gaps before they impact downstream processes.

If you are assessing your T+1 readiness and want to understand where data is still being completed too late in your process, feel free to get in touch. Or download our Market Data Platform factsheet below for a more detailed view of how our approach works in practice.