Section 12

Reference use case 2: Capital markets T+1 settlement exceptions

This reference use case applies the architecture to post-trade operations at a global broker-dealer: predicting, triaging and resolving settlement exceptions in a T+1 world. As in use case 1, the architecture is vendor-neutral except for the transactional platforms named (SAP S/4HANA for the general ledger and Snowflake for trade history and analytics), and trading, matching and settlement platforms are described generically. The final subsection shows how MuleSoft and Informatica realize the design.

Overview

The US moved most broker-dealer securities trades, including equities and corporate bonds, to T+1 settlement on May 28, 2024, together with a new requirement for broker-dealers to complete allocations, confirmations and affirmations as soon as technologically practicable and no later than the end of trade date.⁹⁵ The EU, the UK and Switzerland will move to T+1 together on October 11, 2027.⁹⁶ T+1 compresses allocation, confirmation, affirmation, funding and exception handling into a single day, and failures are expensive. In 2024, participants paid on average €70.43 million a month in EU cash penalties for settlement fails on the T2S platform, and a 2025 industry survey found that 71% of respondents’ settlement fails in 2024 were caused by counterparty shorts and 21% by data issues such as incorrect or stale standing settlement instructions (SSIs).⁹⁷

In most firms, exceptions are still worked by analysts who move between order and booking systems, matching platforms, settlement systems, custodian portals, SWIFT messages and email. This use case adds an agentic layer on top of those systems. Agents predict likely fails and fix standard breaks, prepare the non-standard ones for people and keep a complete audit trail, while people keep authority over anything that moves money, changes settlement instructions or commits the firm to a counterparty.

• Trigger: trade booking on trade date (T) and every later lifecycle event: allocation, confirmation, affirmation and settlement status.
• End state: trade settled, or a failed trade resolved with costs accrued, penalties recorded and counterparties informed.
• Users: settlement operations analysts and supervisors, the trading desk for inventory issues, treasury, finance and compliance.
• Out of scope: trade execution and pre-trade compliance.

Business case and expected outcomes

Illustrative for a broker-dealer settling 50,000 trades a day with a 3% exception rate (about 1,500 exceptions a day) and an average handling time of 18 minutes (about 450 analyst hours a day). Replace with the firm’s baseline.

• T+1 readiness for the October 2027 European go-live, with evidence of control for supervisors.
• Lower cost per trade as volumes grow, without growing the operations team at the same rate.
• Analysts focused on genuine exceptions, with complete context instead of swivel-chair research.
• Fewer client and counterparty escalations, and faster answers when they happen.

Key performance indicators

Baselines below are illustrative and should be measured during discovery.

Solution architecture

Figure 14 shows the architecture against the same layers as the reference architecture, with the cross-cutting security, governance and observability controls on the right.

Clients and channels

Analysts work in an operations copilot, inside their operations workspace or the collaboration tool. Supervisors sign off on mobile devices, with step-up authentication, and operations management works from control dashboards. Outbound channels to counterparties (email, SWIFT and counterparty portals) are reachable only through the gateway, so every message is checked and archived.

Agents and autonomy tiers

Orchestration model selected

The firm runs a dedicated orchestration tier for settlement operations, federated under the enterprise control plane. Settlement is latency-sensitive and cutoff-driven, runs in a tightly controlled operations domain and needs every action traceable, so the orchestrator and its agents run in a dedicated tier close to the trading and settlement systems, while identity, policy, registry, audit and cost remain centrally governed. Orchestration is event-driven (trade, matching and settlement-status events), with a supervisor pattern over A2A²⁷ and deterministic workflows for regulated actions, so SSI changes, payments and borrows above limits always follow maker-checker rules.

Models and routing

• Fine-tuned small language model: self-hosted, it classifies exceptions and parses SWIFT and ISO 20022 messages and emails, handling most of the volume at low latency and cost.
• Frontier model: on a private endpoint with zero data retention, it drafts non-standard counterparty messages and summarizes complex breaks. A second provider is configured for failover, which also supports DORA expectations on ICT third-party risk.⁹⁸
• Fail-prediction model: conventional machine learning (for example gradient-boosted trees) trained on settlement history in Snowflake. It is not an LLM, and its features and drift are monitored under model risk management.
• Rules engine: applies matching tolerances and penalty calculations deterministically.
• Routing policy: client and trade data stay on private models unless masked, and EU desks’ data stays in EU regions. Every step runs to a latency budget.

Control plane and policy

The control plane components match use case 1, with limits and maker-checker rules added to the policy set:

• SSI changes require two approvers, a verified source and a call-back record, and agents can propose them but never apply them. Each approval is bound to the exact change and expires before the settlement cutoff.
• Agents may book internal borrows up to a notional limit per trade and per day, and the desk must approve anything above that. The daily limit is enforced across agents and sessions, so many small borrows cannot add up past it.
• Outbound messages pass data-loss-prevention checks, and account numbers and client identifiers are masked unless the channel is authenticated SWIFT.
• Every agent-sent communication is archived to write-once storage before it is sent.

MCP servers, APIs and systems of record

The orchestrator and its agents work with these systems:

• Trade and booking APIs.
• The matching and confirmation platform.
• The settlement engine, with SWIFT and ISO 20022 messaging.
• Custodian and CSD status feeds.
• Positions, securities-lending and treasury APIs.
• SAP S/4HANA for general-ledger postings.
• Snowflake for trade history and model features.

Streaming events feed the orchestrator, and MCP tools give agents narrowly scoped read and write actions.

Reference data and semantics

About a fifth of fails trace back to data, much of it standing settlement instructions, so reference data is a control rather than a back-office afterthought:

• Counterparty and legal-entity master: golden records keyed by LEI with parent-child hierarchies, so exposure, SSIs and communications roll up correctly.
• Instrument (security) master: one record per security with ISIN, CUSIP and FIGI cross-references, settlement conventions and corporate-action status.
• SSI golden source: SSIs per counterparty, market and asset class with effective dates, a maker-checker workflow and a full change history. The EU and UK T+1 programs are setting market standards for how SSIs are managed and exchanged.⁹⁹
• Account and book master: which legal entity, book and custody account each trade belongs to.

For semantics, the firm aligns its glossary and data contracts to industry standards: ISO 20022 for securities and payment messages,¹⁰⁰ FIBO for business concepts¹⁰¹ and the Common Domain Model for trade lifecycle events.¹⁰² Agents, reports and regulators then share one vocabulary. Lineage and data-quality controls follow the BCBS 239 principles for risk data aggregation and reporting.¹⁰³

Security at every level

The same zero-trust baseline applies as in use case 1,⁹⁰ with controls specific to markets infrastructure:

Governance and observability

Operations risk owns the autonomy tiers and limits, and model risk management validates the fail-prediction model and the small language model. The DORA register records model and platform providers as ICT third parties.⁹⁸ Dashboards show cutoff SLOs by market, exceptions by cause, auto-resolution rate, penalties accrued, policy blocks, model latency and failover events, all built from OpenTelemetry traces⁹⁴ tied to a trade reference.

Daniel’s day in settlement operations

Daniel Okafor works in the firm’s EMEA settlement operations team. The timeline follows an illustrative day (Figure 15).

Daniel starts at 06:30 with his copilot’s briefing. Overnight, 1,240 exceptions arrived and agents have already closed 610 of them (standard matching breaks and SSI enrichments from verified sources), while 38 trades are flagged as likely fails, ranked by value and time to cutoff. At 06:50 he opens the top item: a $48 million corporate-bond trade unmatched on place of settlement. The SSI agent has found that the counterparty published updated instructions the previous afternoon and proposes the correction. Daniel approves as maker, his supervisor approves as checker on mobile with step-up authentication, and the settlement system re-instructs. At 07:20 the inventory agent spots that a sale of German Bunds is short and books an internal borrow within its limit.

By 09:10 the communications agent has sent 14 templated queries and routed one price dispute to Daniel, who rewrites the message himself. At 11:05 the gateway masks an account number that a draft email should not contain and shows Daniel the policy event. At 12:40 the primary model’s latency spikes and the gateway fails over to the secondary provider, leaving a trace only on the operations dashboard. The 15:30 cutoff sweep leaves 12 exceptions, each with its full history, and Daniel escalates two to the trading desk. At 17:15 the penalty and accounting agent posts fail-cost accruals to SAP S/4HANA and publishes the daily fails and penalty report to operations and compliance.

How the components work together

Figure 16 traces the day through the architecture, and the table explains what each component did and which controls applied.

Realizing the use case with MuleSoft and Informatica

As in use case 1, MuleSoft Agent Fabric provides the control plane and the governed paths into the firm’s systems, and Informatica provides the data foundation, while the firm keeps its trading, matching and settlement platforms, its models and its agent frameworks (Figure 17).

The pattern matches use case 1 by design, with MuleSoft governing the agents and the paths they use and Informatica governing the data they act on. The operational setup differs, with a dedicated orchestration tier, deployment close to the trading systems on Runtime Fabric, and policies that center on limits, maker-checker controls and records retention. Confirm connector coverage for each trading and settlement venue during planning.

Delivering the settlement work in phases

As in use case 1, delivery follows the four phases of Section 8, and each milestone widens the scope or raises the autonomy tier only after the previous one has proved its value and its controls.

Values are illustrative and before platform, model and change costs. The savings from fewer fails, lower penalties and cheaper funding come on top and depend on the firm’s own history. Automation that moves money or changes instructions waits for phase 3, when bound approvals and cross-session limits are in place, and until then the earlier phases release analyst capacity in read-only and propose-only modes.