# Capital Markets Post-Trade Design: [Firm or platform name]

> Solution design for the post-trade chain of a broker, bank or asset
> manager: trade capture, allocation, confirmation and affirmation,
> clearing, settlement, reference data, fails management and
> reconciliation. It is written for the move to a one-business-day
> settlement cycle (T+1): in the United States under SEC Rule 15c6-1 as
> amended in 2023 (compliance date 28 May 2024), and in the European
> Union under Regulation (EU) 2025/2075 amending the Central Securities
> Depositories Regulation (applies from 11 October 2027). Message
> references use the FIX Protocol (FIX 5.0 SP2 and FIX Latest) and
> ISO 20022 securities settlement messages. Replace every `[bracketed]`
> value and every row marked *Example*. Regulatory dates and obligations
> are summarised for planning only: check the current official texts,
> CSD and CCP rulebooks with a qualified professional. This is a
> documentation format, not legal or financial advice.

<!--
Guidance: How to use this template
- Write one design per post-trade platform or per market migration
  programme. Market-specific detail (one CSD, one CCP) goes into rows of
  the registers, not into separate documents.
- Fill the market register (section 2) and the deadline register
  (section 14) first. They fix the cut-off times that every other
  section has to meet.
- Draw the T+1 timeline (section 8) before you design any component.
  Most T+1 failures come from batch jobs, overnight FX and manual
  allocation steps that no longer fit in the shorter window.
- Related documents: ISO 20022 payments design
  (`industry/iso20022-payments-design`), Banking solution design mapped
  to BIAN (`industry/banking-bian-solution-design`), Master data
  management design (`architecture/master-data-management-design`),
  Integration design (`architecture/integration-design`), Event-driven
  architecture design (`architecture/event-driven-architecture-design`),
  Account reconciliation (`finance/account-reconciliation`), Cutover
  plan (`project/cutover-plan`).
-->

## Document control

<!-- Guidance: Record the markets and the settlement-cycle change the design targets. Adding a market is a minor version; a new asset class or a new CSD link is a major version. -->

| Field | Value |
|---|---|
| Document ID | [PTD-001] |
| Platform | [Post-trade hub / Middle office / Settlement engine] |
| Asset classes in scope | [Cash equities, ETFs, government bonds, corporate bonds] |
| Markets and infrastructures | [CSDs, CCPs, custodians, trading venues] |
| Settlement cycle target | [T+1 from YYYY-MM-DD] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@post-trade-architect] |
| Approvers/reviewers | [@head-of-operations], [@head-of-treasury], [@compliance-lead], [@ciso], [@enterprise-architect] |
| Classification | [Internal / Confidential] |
| Last updated | YYYY-MM-DD |
| Related documents | [Operating model], [Reference data standard], [Cutover plan] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Head of securities operations | [@name] | [Approve / Approve with conditions / Reject] | YYYY-MM-DD |
| Treasury and funding | [@name] | [Decision] | YYYY-MM-DD |
| Compliance | [@name] | [Decision] | YYYY-MM-DD |
| Architecture review board | [@name] | [Decision] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft |
| 0.2 | YYYY-MM-DD | [@name] | *Example:* Added EU T+1 timeline and CSD cut-offs |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Approved for build |

## Contents

<!-- Guidance: Keep this list aligned with the headings below. -->

1. [Scope and drivers](#1-scope-and-drivers)
2. [Market and infrastructure register](#2-market-and-infrastructure-register)
3. [Trade lifecycle and flows](#3-trade-lifecycle-and-flows)
4. [Trade capture and enrichment](#4-trade-capture-and-enrichment)
5. [Allocation, confirmation and affirmation](#5-allocation-confirmation-and-affirmation)
6. [Clearing](#6-clearing)
7. [Settlement instructions and messages](#7-settlement-instructions-and-messages)
8. [T+1 timeline and cut-offs](#8-t1-timeline-and-cut-offs)
9. [Fails, penalties and buy-ins](#9-fails-penalties-and-buy-ins)
10. [Reference data](#10-reference-data)
11. [Funding, FX and securities financing](#11-funding-fx-and-securities-financing)
12. [Reconciliation and operational controls](#12-reconciliation-and-operational-controls)
13. [Non-functional design, testing and cutover](#13-non-functional-design-testing-and-cutover)
14. [Deadline register](#14-deadline-register)
15. [Traceability matrix](#15-traceability-matrix)
16. [Glossary and references](#16-glossary-and-references)

## 1. Scope and drivers

<!-- Guidance: State the asset classes, markets, client types and flows in scope, and the event that forces the change. Separate the minimum scope needed for the regulatory date from improvements you would like to make at the same time, so the date is never put at risk by optional work. -->

### 1.1 Scope

| ID | Flow | Asset class | Markets | Client type | In scope |
|---|---|---|---|---|---|
| SCP-001 *(Example)* | Agency execution for institutional clients, with block allocation | Cash equities, ETFs | EU venues, US venues | Asset managers | Yes |
| SCP-002 *(Example)* | Principal trading in government bonds | Government bonds | EU, UK | Banks, asset managers | Yes |
| SCP-003 *(Example)* | Retail order flow from the online broker | Cash equities | EU | Retail | Yes |
| SCP-004 *(Example)* | Securities lending recalls linked to sales | Equities | EU, US | Lending agent | Yes |
| SCP-005 *(Example)* | OTC derivatives clearing | Interest rate swaps | EU | Banks | No (separate design) |

### 1.2 Drivers

| ID | Driver | Consequence for the design |
|---|---|---|
| DRV-001 *(Example)* | EU move to T+1 under Regulation (EU) 2025/2075, applicable from 11 October 2027 | Allocation, confirmation and settlement instruction must complete on trade date; overnight batches move to intraday processing |
| DRV-002 *(Example)* | US T+1 in force since 28 May 2024 under the amended SEC Rule 15c6-1 | European clients buying US securities need same-day affirmation and same-day FX funding |
| DRV-003 *(Example)* | UK move to T+1 announced for 11 October 2027, aligned with the EU | One design for EU and UK flows; check the UK legislation and FCA rules before relying on the date |
| DRV-004 *(Example)* | Cash penalties for settlement fails under the CSDR settlement discipline regime | Fails prediction, partial settlement and penalty reconciliation become first-class functions |
| DRV-005 *(Example)* | Manual allocation by email for 18 percent of block trades | Electronic allocation with FIX or a matching utility for every client |

### 1.3 Principles

1. Match early: every trade should be matched with the counterparty or
   affirmed by the client on trade date, not on settlement date.
2. Process events, not batches: each lifecycle step starts when the
   previous one completes, with batch jobs only as a safety net.
3. One golden source per reference data item, with standing settlement
   instructions (SSIs) held electronically and never re-keyed.
4. Every trade carries the same identifiers from execution to
   settlement and reconciliation.

## 2. Market and infrastructure register

<!-- Guidance: One row per CSD, CCP, custodian, venue and matching utility the firm uses. Record each one's settlement cycle, cut-off times and messaging standard. This register drives the timeline in section 8. -->

| ID | Infrastructure | Role | Markets | Messaging | Settlement cycle | Key cut-off (local time) |
|---|---|---|---|---|---|---|
| INF-001 *(Example)* | [EU CSD settling on a shared platform] | CSD | Eurozone equities and bonds | ISO 20022 sese and semt | T+2, T+1 from 2027-10-11 | [Night-time settlement input cut-off from the CSD rulebook] |
| INF-002 *(Example)* | [EU CCP] | CCP | EU cash equities | CCP proprietary and FIX | Follows the CSD | [Netting cut-off] |
| INF-003 *(Example)* | [US CSD and clearing agency] | CSD, CCP | US equities | Proprietary and ISO 15022 or ISO 20022 via custodian | T+1 | [Affirmation cut-off from the CSD rules] |
| INF-004 *(Example)* | [Global custodian] | Custodian | Markets without direct membership | ISO 15022 MT 54x and ISO 20022 sese | Per market | [Custodian instruction deadline] |
| INF-005 *(Example)* | [Central matching utility] | Matching | Institutional allocations | FIX and proprietary API | Not applicable | [Match by end of trade date] |

Status notes to check at the source before use:

- The amended SEC Rule 15c6-1 (Release 34-96930, adopted
  15 February 2023) set T+1 as the standard settlement cycle for most
  US broker-dealer transactions from 28 May 2024. The same release added
  Rule 15c6-2 on completing allocations, confirmations and affirmations
  as soon as technologically practicable and no later than the end of
  trade date. Check the release for the exact scope and exceptions.
- Regulation (EU) 2025/2075 of 8 October 2025 amends Article 5 of
  Regulation (EU) No 909/2014 (CSDR) to require T+1 for transactions in
  transferable securities executed on trading venues. It was published
  in the Official Journal on 14 October 2025, entered into force on
  3 November 2025 and applies from 11 October 2027. Check the
  consolidated text for the exemptions, such as privately negotiated
  trades executed on a venue and certain securities financing
  transactions.
- The UK has announced the same date, 11 October 2027. HM Treasury
  published a draft statutory instrument amending Article 5 of the UK
  CSDR in November 2025 (as reported by HM Treasury's T+1 policy update
  and law-firm summaries); check legislation.gov.uk for the final
  instrument and the FCA publications for the binding text.

## 3. Trade lifecycle and flows

<!-- Guidance: Draw the main lifecycle with the message or event on each arrow. Show who confirms to whom, and where the trade can fail. Keep the participants identical to the components named in sections 4 to 7. -->

### 3.1 Agency equity trade with block allocation

*Example:* an asset manager sends one block order; the broker executes
it, the manager allocates it to funds, and the broker settles each
allocation through the CSD.

```mermaid
sequenceDiagram
  participant AM as Asset manager OMS
  participant OMS as Broker order management
  participant V as Trading venue
  participant PT as Post-trade hub
  participant CCP as CCP
  participant CSD as CSD
  AM->>OMS: NewOrderSingle (FIX 35=D)
  OMS->>V: order routed
  V-->>OMS: fills
  OMS-->>AM: ExecutionReport (FIX 35=8)
  V->>CCP: trade feed for novation
  OMS->>PT: block trade captured, enriched with SSIs
  AM->>PT: AllocationInstruction (FIX 35=J)
  PT-->>AM: Confirmation per allocation (FIX 35=AK)
  AM-->>PT: affirmation
  CCP-->>PT: net settlement obligations
  PT->>CSD: sese.023 settlement instructions
  CSD-->>PT: sese.024 matching and status
  CSD-->>PT: sese.025 settlement confirmation
  PT->>PT: update positions, cash and books
```

### 3.2 Lifecycle states

Each allocation moves through these states; the settlement engine
publishes a state-change event for each transition so that operations
screens and reconciliations read the same status.

```mermaid
stateDiagram-v2
  [*] --> Executed
  Executed --> Enriched: SSIs and fees added
  Enriched --> Allocated: allocation received
  Allocated --> Affirmed: client affirms
  Affirmed --> Instructed: sent to CSD or custodian
  Instructed --> Matched: counterparty instruction matches
  Matched --> Settled: delivery versus payment
  Matched --> Failed: no securities or no cash at cut-off
  Failed --> PartiallySettled: partial delivery
  PartiallySettled --> Settled
  Failed --> Settled: resolved on a later day
  Settled --> [*]
```

### 3.3 Flow inventory

| ID | Flow | Trigger | Key messages | Owner |
|---|---|---|---|---|
| FLW-001 *(Example)* | Agency equity, CCP cleared | Client order | FIX 35=D, 35=8, 35=J, 35=AK, sese.023 | Equities middle office |
| FLW-002 *(Example)* | Principal bond trade, bilateral settlement | Trader | FIX TradeCaptureReport 35=AE, sese.023 | Fixed income operations |
| FLW-003 *(Example)* | Retail equity order | App order | Internal events, sese.023 net by account | Retail operations |
| FLW-004 *(Example)* | Securities lending recall to cover a sale | Sale of lent stock | Lending platform recall, sese.023 | Securities finance desk |
| FLW-005 *(Example)* | Corporate action on a pending trade | CSD event | seev messages, market claim | Asset servicing |

## 4. Trade capture and enrichment

<!-- Guidance: Describe where each trade enters the post-trade chain, how fast, and what is added to it. Under T+1, trade capture must be real time; a trade that arrives in the post-trade hub hours after execution has already lost part of its settlement window. -->

| ID | Source | Interface | Latency target | Enrichment added | Validation |
|---|---|---|---|---|---|
| CAP-001 *(Example)* | Broker OMS | FIX ExecutionReport over FIXT 1.1 session | Under 1 second after fill | Book, trader, strategy | Instrument and account exist |
| CAP-002 *(Example)* | Bond trading platform | FIX TradeCaptureReport | Under 5 seconds | Accrued interest, settlement place | Price tolerance, ISIN active |
| CAP-003 *(Example)* | Retail order platform | Internal event stream | Under 1 second | Client account, tax status | Cash or position available |
| CAP-004 *(Example)* | Manual ticket (exception only) | Operations screen with four-eyes check | Under 15 minutes | All fields | Second user approves |

Enrichment rules:

- Add settlement place, settlement date, SSIs, fees, commissions and
  taxes from reference data at capture, not at instruction time.
- Calculate the intended settlement date from the trade date, the
  settlement cycle of the market and the business-day calendars of both
  the market and the settlement currency.
- Keep the execution identifiers from the venue and the order system on
  every record so that breaks can be traced back to the fill.
- Flag trades that already miss the same-day affirmation cut-off at
  capture, so operations sees them while there is still time to act.

## 5. Allocation, confirmation and affirmation

<!-- Guidance: This is the step that T+1 compresses most. Describe how each client allocates, how the firm confirms, and how the client affirms, with a target time for each. Name the clients who still allocate by email or file and the plan to move them. -->

### 5.1 Allocation channels

| ID | Client segment | Allocation channel | Confirmation channel | Affirmation | Target completion |
|---|---|---|---|---|---|
| ALC-001 *(Example)* | Large asset managers | FIX AllocationInstruction | FIX Confirmation | Central matching utility | Within 1 hour of last fill |
| ALC-002 *(Example)* | Hedge funds | Prime broker allocation file | File acknowledgement | Matching utility | Before 18:00 trade date |
| ALC-003 *(Example)* | Small institutions | Client portal | Portal and email PDF | Portal click | Before 19:00 trade date |
| ALC-004 *(Example)* | Legacy email allocation (to retire) | Email | Email | Manual | Retire before the T+1 date |

### 5.2 Rules

1. Allocations are matched against the block quantity and average price;
   a residual of more than the price rounding tolerance is a break.
2. Commission, fees and taxes are calculated per allocation and sent in
   the confirmation, so the client can match its own calculation.
3. A trade that is not affirmed by the affirmation cut-off is escalated
   automatically to the client service desk and appears on the fails
   prediction screen in section 9.
4. Standing settlement instructions are taken from the electronic SSI
   source at allocation time; an SSI change after confirmation requires
   a re-confirmation.

### 5.3 Measures

| ID | Measure | Definition | Target |
|---|---|---|---|
| AFM-001 *(Example)* | Same-day affirmation rate | Allocations affirmed by the trade-date cut-off divided by all allocations | Above 95 percent |
| AFM-002 *(Example)* | Electronic allocation share | Allocations received through FIX, files or portal divided by all allocations | 100 percent before go-live |
| AFM-003 *(Example)* | Confirmation turnaround | Time from allocation receipt to confirmation sent | Under 5 minutes |

## 6. Clearing

<!-- Guidance: Describe which trades are centrally cleared and how, and which settle bilaterally. Show how CCP netting output becomes settlement instructions. The CCP's own deadlines move under T+1, so record them in section 8. -->

| ID | Trade type | Clearing model | CCP or bilateral | Netting | Output to settlement |
|---|---|---|---|---|---|
| CLR-001 *(Example)* | On-venue cash equities | Novation to CCP | [EU CCP] | Multilateral net per ISIN and settlement date | Net instructions generated by the CCP or by the firm, per CCP rules |
| CLR-002 *(Example)* | Off-venue equity trades with institutions | Bilateral | Bilateral | None | Gross instructions per allocation |
| CLR-003 *(Example)* | Government bond repos | CCP where eligible | [Repo CCP] | Net per ISIN | Net instructions |

Design notes:

- Margin calls from the CCP arrive intraday; link them to the treasury
  funding plan in section 11.
- Keep both the gross trades and the net obligations, so that a failed
  net delivery can be traced to the underlying client trades.
- Clearing membership models (direct, general clearing member, client
  clearing) decide who instructs settlement: record the model per row.

## 7. Settlement instructions and messages

<!-- Guidance: List every settlement message the platform sends and receives, per infrastructure, with the standard and the version the infrastructure requires. ISO 15022 and ISO 20022 often coexist in custody chains; record which applies on each link. -->

### 7.1 Message catalogue

| ID | Message | Purpose | Standard | Direction | Infrastructure |
|---|---|---|---|---|---|
| MSG-001 *(Example)* | sese.023 | Securities settlement transaction instruction | ISO 20022 | Outbound | CSD |
| MSG-002 *(Example)* | sese.024 | Settlement status and processing advice (matched, unmatched, pending, failing) | ISO 20022 | Inbound | CSD |
| MSG-003 *(Example)* | sese.025 | Settlement confirmation | ISO 20022 | Inbound | CSD |
| MSG-004 *(Example)* | sese.020 | Cancellation request | ISO 20022 | Outbound | CSD |
| MSG-005 *(Example)* | semt.017 | Statement of transactions | ISO 20022 | Inbound | CSD, custodian |
| MSG-006 *(Example)* | semt.002 | Statement of holdings | ISO 20022 | Inbound | CSD, custodian |
| MSG-007 *(Example)* | MT 540 to MT 547 | Settlement instruction and confirmation in ISO 15022 | ISO 15022 | Both | Custodian (legacy link) |
| MSG-008 *(Example)* | FIX 35=J, 35=AS, 35=AK | Allocation instruction, allocation report, confirmation | FIX 5.0 SP2 or FIX Latest | Both | Clients, matching utility |

### 7.2 Settlement instruction content

| ID | Element | Rule |
|---|---|---|
| SIN-001 *(Example)* | Trade date and intended settlement date | From capture; the intended settlement date is T+1 for in-scope trades after the migration date |
| SIN-002 *(Example)* | ISIN and quantity | From the trade; quantity in units or nominal per instrument type |
| SIN-003 *(Example)* | Settlement amount and currency | Net of fees where the market practice requires |
| SIN-004 *(Example)* | Delivering and receiving parties, places of settlement | From the SSI database; never typed by hand |
| SIN-005 *(Example)* | Partial settlement indicator | Allow partial settlement by default where the CSD supports it, unless the client has opted out |
| SIN-006 *(Example)* | Hold and release indicator | Used only for trades waiting for cash or securities; released automatically when the condition clears |
| SIN-007 *(Example)* | Transaction type and settlement transaction condition | Per market practice for the CSD |

### 7.3 Version management

- Pin the message versions required by each CSD and custodian, and the
  release calendar of each. Check the usage guidelines published by
  each infrastructure rather than the latest ISO 20022 catalogue
  version.
- Keep schemas and validation rules per infrastructure in a versioned
  repository, with automated tests against the infrastructure's sample
  messages.

## 8. T+1 timeline and cut-offs

<!-- Guidance: Draw the trade-date and settlement-date timeline with every cut-off from the infrastructures and the internal step that must finish before it. Time zones matter: a European client trading US securities has its trade date evening in the middle of the US afternoon. -->

### 8.1 Trade-date timeline

*Example:* EU cash equity, executed on a trading venue, settled at an EU
CSD after the T+1 date. Times are illustrative; take the real cut-offs
from the CSD and CCP rulebooks.

| ID | Step | Owner | Start | Must finish by (CET) |
|---|---|---|---|---|
| TL-001 *(Example)* | Execution and trade capture | Trading, OMS | Market open | Real time |
| TL-002 *(Example)* | Allocation received | Client | Last fill | 18:00 trade date |
| TL-003 *(Example)* | Confirmation sent | Middle office | Allocation | 18:30 trade date |
| TL-004 *(Example)* | Affirmation or matching | Client, matching utility | Confirmation | 21:00 trade date |
| TL-005 *(Example)* | Settlement instruction sent and matched at CSD | Settlement engine | Affirmation | Before the CSD's night-time input cut-off on trade date |
| TL-006 *(Example)* | Funding and securities availability checked | Treasury, securities finance | Trade date afternoon | Before night-time settlement |
| TL-007 *(Example)* | Settlement | CSD | Night-time and daytime cycles | Settlement date |
| TL-008 *(Example)* | Fails resolution | Settlement operations | Settlement date morning | Settlement date end of day |

### 8.2 Cross-time-zone flows

| ID | Flow | Issue | Design response |
|---|---|---|---|
| TZ-001 *(Example)* | EU client buys US equities | US trade date ends after European business hours; FX for USD funding must happen on trade date | FX booked automatically at allocation; operations cover until the US affirmation cut-off |
| TZ-002 *(Example)* | Asia-Pacific client trades EU bonds | Client allocates during its night | Allocation API with automated rules; standing allocation templates per fund |
| TZ-003 *(Example)* | ETF with constituents in several markets | Creation and redemption baskets settle on different cycles | Basket settlement plan per constituent market |

### 8.3 Batch-to-event changes

| ID | Process | Today | After T+1 |
|---|---|---|---|
| BTE-001 *(Example)* | SSI enrichment | Overnight batch | At allocation, event driven |
| BTE-002 *(Example)* | Settlement instruction generation | End-of-day file | Per affirmed allocation, streamed |
| BTE-003 *(Example)* | Securities lending recall | Next-day check | Triggered at sale execution |
| BTE-004 *(Example)* | FX funding | Next morning | At allocation, with a trade-date cut-off |

## 9. Fails, penalties and buy-ins

<!-- Guidance: Describe how the firm predicts fails before they happen, how it manages them after, and how it calculates, checks and passes on cash penalties. Under CSDR the CSD calculates penalties; the firm must reconcile them and allocate them to the client or desk that caused the fail. -->

### 9.1 Fails prediction

| ID | Signal | Source | Action |
|---|---|---|---|
| FPR-001 *(Example)* | Allocation not affirmed by the cut-off | Section 5 measures | Client service escalation |
| FPR-002 *(Example)* | Instruction unmatched at the CSD | sese.024 status | Counterparty contact with the unmatched reason |
| FPR-003 *(Example)* | Securities not available (short position, lent stock) | Position keeping and lending platform | Recall or borrow |
| FPR-004 *(Example)* | Cash not available in settlement currency | Treasury projection | Fund or use credit line |

### 9.2 Cash penalties

Under the CSDR settlement discipline regime, CSDs calculate cash
penalties per failing instruction and per business day of the fail,
using reference prices and penalty rates set in Commission Delegated
Regulation (EU) 2017/389 as amended. Check the current consolidated text
and the CSD's published rates before use; the rate below is invented
for illustration and is not the regulatory rate.

*Example:* a delivery of shares with a settlement value of
EUR 2,400,000 fails for 3 business days. With an illustrative rate of
1 basis point per day, the penalty is 2,400,000 x 0.0001 x 3 =
EUR 720. The firm receives the amount in the CSD's penalty report,
recalculates it, books it to the desk or client that caused the fail,
and raises a dispute with the CSD if the recalculation differs.

| ID | Control | Frequency | Owner |
|---|---|---|---|
| PEN-001 *(Example)* | Recalculate every penalty reported by the CSD | Daily | Settlement operations |
| PEN-002 *(Example)* | Allocate penalties to the responsible client or desk | Monthly | Finance |
| PEN-003 *(Example)* | Report fails by reason, client and counterparty | Weekly | Head of operations |

### 9.3 Settlement efficiency

*Example:* on a sample day the firm sent 12,000 instructions due to
settle; 11,820 settled on the intended settlement date and 180 failed.
Settlement efficiency is 11,820 / 12,000 = 98.5 percent by count.
Report the same measure by value, because a few large fails can matter
more than many small ones.

Mandatory buy-in rules: the CSDR Refit (Regulation (EU) 2023/2845) made
mandatory buy-ins a measure that applies only if the Commission
activates it. Check the current status of the regime and any
infrastructure rules on buy-ins before designing the process.

## 10. Reference data

<!-- Guidance: List every reference data item post-trade relies on, its golden source and how fast a change reaches the settlement engine. Wrong SSIs are the most common cause of unmatched instructions. -->

| ID | Data item | Standard | Golden source | Update latency | Owner |
|---|---|---|---|---|---|
| REF-001 *(Example)* | Instrument identifier | ISIN (ISO 6166) | Security master | Real time from vendor feed | Reference data team |
| REF-002 *(Example)* | Instrument classification | CFI (ISO 10962) | Security master | Real time | Reference data team |
| REF-003 *(Example)* | Legal entity identifier of clients and counterparties | LEI (ISO 17442) | Client master, validated against the global LEI index | Daily | Client onboarding |
| REF-004 *(Example)* | Venue identifier | MIC (ISO 10383) | Venue table | Monthly | Reference data team |
| REF-005 *(Example)* | Standing settlement instructions | Internal model aligned with the SSI utility | SSI database fed by the utility | Real time | Settlement operations |
| REF-006 *(Example)* | Business-day calendars per market and currency | Internal | Calendar service | Yearly with ad hoc changes | Reference data team |
| REF-007 *(Example)* | Settlement cycle per market and instrument | Internal | Market register (section 2) | On each regulatory change | Post-trade architecture |

Controls: changes to SSIs require four-eyes approval and an audit
trail; a new SSI applies only to trades confirmed after the change; and
the settlement cycle per market is a data item with an effective date,
so the T+1 switch is a reference data change, not a code release.
Master data governance: master data management design
(`architecture/master-data-management-design`).

## 11. Funding, FX and securities financing

<!-- Guidance: Describe how cash and securities are made available in time for settlement. T+1 removes the extra day that FX, recalls and inventory movements relied on. -->

| ID | Need | Today | T+1 design | Owner |
|---|---|---|---|---|
| FND-001 *(Example)* | Cash in settlement currency for client purchases in a foreign currency | FX booked the day after trade | FX booked at allocation, same-day value where available | Treasury |
| FND-002 *(Example)* | Securities lent out but sold by the client | Recall the next day | Recall triggered at sale execution; lending agent notified in real time | Securities finance |
| FND-003 *(Example)* | Inventory in the wrong CSD | Realignment on settlement date | Inventory positioning plan by CSD on trade date | Settlement operations |
| FND-004 *(Example)* | CCP margin calls | Next-morning funding | Intraday funding line with alerts | Treasury |

## 12. Reconciliation and operational controls

<!-- Guidance: Name each reconciliation, its keys, its timing and who clears the breaks. Under T+1, end-of-day reconciliations leave no time to fix a break before settlement; move them intraday where you can. -->

| ID | Match | Keys | Frequency | Break owner |
|---|---|---|---|---|
| RCN-001 *(Example)* | Trades in OMS to trades in post-trade hub | Execution identifier, quantity, price | Intraday, continuous | Middle office |
| RCN-002 *(Example)* | Allocations to block trade | Block identifier, total quantity, average price | Per allocation | Middle office |
| RCN-003 *(Example)* | Settlement instructions to CSD status | Instruction reference, ISIN, quantity | Intraday | Settlement operations |
| RCN-004 *(Example)* | Positions to CSD and custodian holdings | Account, ISIN, quantity | Daily, from semt.002 | Asset servicing |
| RCN-005 *(Example)* | Cash movements to cash statements | Reference, amount, value date | Intraday and end of day | Treasury operations |
| RCN-006 *(Example)* | Penalties to CSD penalty report | Instruction reference, amount | Daily | Settlement operations |

General ledger and break management process: account reconciliation
(`finance/account-reconciliation`).

## 13. Non-functional design, testing and cutover

<!-- Guidance: Give measurable targets for throughput, latency and recovery, then the test and cutover plan. Industry T+1 test windows are set by the CSDs and industry groups; book them early. -->

### 13.1 Non-functional requirements

| ID | Area | Requirement | Target | Evidence |
|---|---|---|---|---|
| NFR-001 *(Example)* | Capture latency | Fill to post-trade hub | 99th percentile under 2 seconds | Performance test |
| NFR-002 *(Example)* | Peak volume | Trades per day at peak (3 times average) | 600,000 trades without backlog | Load test |
| NFR-003 *(Example)* | Availability | Post-trade hub during trade date and night-time settlement | 99.9 percent, extended hours | SLO report |
| NFR-004 *(Example)* | Recovery | Recovery time objective | Under 1 hour, no lost trade (RPO zero) | DR test |
| NFR-005 *(Example)* | Audit | Every change to a trade, SSI or instruction | Immutable audit trail kept for the regulatory retention period | Audit log review |

### 13.2 Testing and cutover

| ID | Test | Scope | Exit criterion |
|---|---|---|---|
| TST-001 *(Example)* | Settlement date calculation | All markets, holidays, both cycles | Every sample date correct before and after the switch date |
| TST-002 *(Example)* | End-to-end flows | FLW-001 to FLW-005 | All pass, including fails |
| TST-003 *(Example)* | Client allocation | Every client channel | Same-day affirmation rate above target in a test week |
| TST-004 *(Example)* | Industry testing | CSD and CCP T+1 test cycles | Infrastructure test reports passed |
| TST-005 *(Example)* | Switch weekend rehearsal | Trades executed on the last T+2 day and the first T+1 day | Correct settlement dates; no double settlement on the transition day |

Cutover approach: [*Example:* switch the settlement cycle as a
reference data change effective on the migration date; trades executed
before the date keep T+2; monitor the first T+1 week with a war room;
keep fails and penalties under daily review for one month.] Runbook:
cutover plan (`project/cutover-plan`).

## 14. Deadline register

<!-- Guidance: Keep every external date that drives the design, with its source and the date you last checked it. Infrastructure release dates and industry test windows move; re-check them each month. -->

| ID | Date | Event | Source to check | Last checked |
|---|---|---|---|---|
| DLN-001 | 2024-05-28 | US T+1 compliance date under amended SEC Rule 15c6-1 | SEC Release 34-96930 | YYYY-MM-DD |
| DLN-002 | 2025-11-03 | Regulation (EU) 2025/2075 in force | EUR-Lex | YYYY-MM-DD |
| DLN-003 | 2027-10-11 | EU T+1 applies to transactions executed on trading venues | Regulation (EU) 2025/2075, consolidated CSDR | YYYY-MM-DD |
| DLN-004 | 2027-10-11 | UK T+1 (announced) | UK legislation and FCA publications | YYYY-MM-DD |
| DLN-005 | [Date] | CSD and CCP T+1 industry test windows | Infrastructure notices | YYYY-MM-DD |
| DLN-006 | [Date] | Next CSD message release | CSD release calendar | YYYY-MM-DD |

## 15. Traceability matrix

<!-- Guidance: Link each driver to design elements and tests. A regulatory driver without a passing test is a delivery risk to report to the steering committee. -->

| Driver | Design elements | Tests | Status |
|---|---|---|---|
| DRV-001 | TL-001 to TL-008, BTE-001 to BTE-004, REF-007 | TST-001, TST-004, TST-005 | [Open / Passed] |
| DRV-002 | TZ-001, FND-001, ALC-001 to ALC-003 | TST-002, TST-003 | [Open / Passed] |
| DRV-003 | DLN-004, REF-007 | TST-001 | [Open / Passed] |
| DRV-004 | FPR-001 to FPR-004, PEN-001 to PEN-003 | TST-002 | [Open / Passed] |
| DRV-005 | ALC-004, AFM-002 | TST-003 | [Open / Passed] |

## 16. Glossary and references

<!-- Guidance: Define terms for non-specialist reviewers and list the exact versions of rulebooks and specifications used. -->

### 16.1 Glossary

| Term | Meaning |
|---|---|
| T+1 | Settlement one business day after the trade date |
| Allocation | Split of a block trade across the client's funds or accounts |
| Affirmation | Client's agreement that the confirmed trade details are correct |
| CCP | Central counterparty that becomes buyer to every seller and seller to every buyer |
| CSD | Central securities depository that holds securities and settles transactions |
| DvP | Delivery versus payment: securities move only if cash moves |
| SSI | Standing settlement instruction: the accounts and agents a party uses to settle |
| Settlement fail | Instruction not settled on the intended settlement date |
| FIX | Financial Information eXchange protocol for trading and post-trade messages |

### 16.2 References

| Reference | Version or date | Use |
|---|---|---|
| SEC, Shortening the Securities Transaction Settlement Cycle, Release 34-96930, sec.gov | Adopted 2023-02-15; compliance 2024-05-28 | Sections 1, 2, 14 |
| Regulation (EU) 2025/2075 amending Regulation (EU) No 909/2014 as regards a shorter settlement cycle, eur-lex.europa.eu/eli/reg/2025/2075/oj | OJ 2025-10-14; applies 2027-10-11 | Sections 1, 2, 14 |
| Regulation (EU) No 909/2014 (CSDR), consolidated, and Regulation (EU) 2023/2845 (CSDR Refit) | Consolidated text as checked YYYY-MM-DD | Section 9 |
| Commission Delegated Regulation (EU) 2017/389 on penalty parameters | As amended, checked YYYY-MM-DD | Section 9 |
| FIX Protocol, FIX 5.0 SP2 and FIX Latest, fixtrading.org | As used with each counterparty | Sections 3, 5, 7 |
| ISO 20022 securities settlement and management messages, iso20022.org | Versions per infrastructure usage guidelines | Section 7 |
| [CSD and CCP rulebooks] | [Version] | Sections 2, 8 |

## Standard and licence note

Based on public legal texts (SEC Rule 15c6-1 as amended by Release
34-96930, Regulation (EU) 2025/2075 and the CSDR), the FIX Protocol
message names published by the FIX Trading Community and ISO 20022
message identifiers. Message names and identifiers are used for
reference only; no specification, rulebook or legal text is reproduced,
and all descriptions are original text written for this collection.
Check the current official texts, infrastructure rulebooks and usage
guidelines before use, because settlement rules and dates change. This
is a documentation format, not legal or financial advice; consult a
qualified professional. FIX and the infrastructure names are trademarks
of their owners; this template is not affiliated with or endorsed by
them. Template licence: MIT.