# ISO 20022 Payments Design: [Bank or payments hub name]

> Solution design for sending, receiving and reporting payments in
> ISO 20022 across the schemes and market infrastructures a bank uses:
> Swift CBPR+ for cross-border payments, HVPS+ based high-value systems,
> SEPA Credit Transfer and SEPA Instant, and national systems such as
> Fedwire and FedNow. It covers the message set and versions, end-to-end
> flows, the canonical payment model, structured and hybrid postal
> addresses (the CBPR+ removal of unstructured addresses, first set for
> 14 November 2026, was deferred by Swift on 27 August 2026; Swift will
> announce the new date by December 2026), data enrichment and truncation, translation for legacy systems, sanctions screening and
> verification of payee, liquidity and reconciliation, exceptions and
> investigations, testing and cutover. Replace every `[bracketed]` value
> and every row marked *Example*. Scheme deadlines and legal obligations
> are summarised for planning only: check the current scheme rulebooks,
> usage guidelines and consolidated legal texts. This is a documentation
> format, not legal advice.

<!--
Guidance: How to use this template
- Write one design per payments platform (hub, gateway or core payments
  module). Scheme-specific detail goes into the appendices of section 3,
  not into separate documents.
- Fill the scheme register (section 2) and the deadline register
  (section 14) first. They decide the message versions and the order of
  delivery.
- Treat the canonical model (section 5) as the contract between channels,
  the hub and the gateways. If a field is dropped there, it is dropped
  for every scheme.
- Never design to an older usage guideline. Swift, the EPC and each
  market infrastructure publish yearly releases; pin the release and its
  live date in section 3.
- Related documents: Banking solution design mapped to BIAN
  (`industry/banking-bian-solution-design`), Open banking API design
  (`industry/open-banking-api-design`), Payment ledger design
  (`system-design/design-payment-ledger`), Fraud detection design
  (`system-design/design-fraud-detection`), Integration design
  (`architecture/integration-design`), Cutover plan (`project/cutover-plan`).
-->

## Document control

<!-- Guidance: Record the scheme releases the design targets. A new yearly standards release adopted by the design is a new minor version; a new scheme is a new major version. -->

| Field | Value |
|---|---|
| Document ID | [IPD-001] |
| Platform | [Payments hub / Gateway / Core payments module] |
| Schemes and infrastructures in scope | [CBPR+, HVPS+ system names, SEPA SCT, SCT Inst, Fedwire, FedNow, domestic] |
| Standards releases targeted | [*Example:* Swift standards release in force (SR2026 payments changes deferred); EPC rulebooks in force; Fedwire current release] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@payments-architect] |
| Approvers/reviewers | [@head-of-payments-operations], [@financial-crime-lead], [@treasury-lead], [@ciso], [@enterprise-architect] |
| Classification | [Internal / Confidential] |
| Last updated | YYYY-MM-DD |
| Related documents | [BIAN solution design], [Payment ledger design], [Sanctions screening standard], [Cutover plan] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Head of payments | [@name] | [Approve / Approve with conditions / Reject] | YYYY-MM-DD |
| Payments operations | [@name] | [Decision] | YYYY-MM-DD |
| Financial crime compliance | [@name] | [Decision] | YYYY-MM-DD |
| Treasury and liquidity | [@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 hybrid address rules for the CBPR+ unstructured-address removal (date to be announced by Swift) |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Approved for build and scheme testing |

## Contents

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

1. [Scope and drivers](#1-scope-and-drivers)
2. [Scheme and infrastructure register](#2-scheme-and-infrastructure-register)
3. [Message set and versions](#3-message-set-and-versions)
4. [End-to-end flows](#4-end-to-end-flows)
5. [Canonical payment model](#5-canonical-payment-model)
6. [Party and postal address data](#6-party-and-postal-address-data)
7. [Identifiers, remittance and enrichment](#7-identifiers-remittance-and-enrichment)
8. [Translation, truncation and coexistence](#8-translation-truncation-and-coexistence)
9. [Screening, fraud and verification of payee](#9-screening-fraud-and-verification-of-payee)
10. [Liquidity, settlement and reconciliation](#10-liquidity-settlement-and-reconciliation)
11. [Exceptions and investigations](#11-exceptions-and-investigations)
12. [Non-functional and operational design](#12-non-functional-and-operational-design)
13. [Testing, certification and cutover](#13-testing-certification-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: Say which payment types, directions and channels are in scope, and what business or regulatory event forces the change. Regulatory deadlines are fixed; write the scope so that the minimum compliant scope can be separated from the optional enrichment work. -->

### 1.1 Scope

| ID | Payment type | Direction | Channel or source | In scope |
|---|---|---|---|---|
| SCP-001 *(Example)* | Cross-border customer credit transfer | Outgoing and incoming | Mobile, corporate file, branch | Yes |
| SCP-002 *(Example)* | Financial institution transfer and cover | Outgoing and incoming | Treasury system | Yes |
| SCP-003 *(Example)* | SEPA Credit Transfer | Outgoing and incoming | All channels | Yes |
| SCP-004 *(Example)* | SEPA Instant Credit Transfer | Outgoing and incoming | All channels, third-party initiation | Yes |
| SCP-005 *(Example)* | Account statements and notifications to corporates | Outgoing | Corporate host-to-host | Yes |
| SCP-006 *(Example)* | Direct debits | Both | Billers | No (later phase) |

### 1.2 Drivers

| ID | Driver | Consequence for the design |
|---|---|---|
| DRV-001 *(Example)* | CBPR+ will reject fully unstructured postal addresses from a date Swift will announce by December 2026 (originally 14 November 2026, deferred on 27 August 2026) | Party data in channels and core must supply at least town and country as structured fields; keep the remediation plan on track, because the new date may leave little notice |
| DRV-002 *(Example)* | Instant euro payments and payee verification required by Regulation (EU) 2024/886 | 24/7 processing inside a 10-second scheme limit; payee verification before authorisation |
| DRV-003 *(Example)* | Richer data improves straight-through processing and screening accuracy | Canonical model keeps all ISO 20022 data end to end |
| DRV-004 *(Example)* | Legacy core accepts only fixed-length fields | Translation layer and truncation controls (section 8) |

### 1.3 Principles

1. Keep the richest form of the data from capture to archive; only the
   last adapter towards a limited system may reduce it, and it must log
   what it reduced.
2. One canonical payment model for all schemes; scheme rules are
   validation profiles applied to it.
3. Every payment carries its identifiers unchanged from initiation to
   reconciliation.
4. Screening and fraud checks see the full message, never a truncated
   view.

## 2. Scheme and infrastructure register

<!-- Guidance: One row per scheme or market infrastructure the bank participates in, with the market practice, the release cycle and the participation model. This register drives the version table in section 3 and the deadlines in section 14. -->

| ID | Scheme or infrastructure | Market practice and guideline | Participation | Release cycle | Operating hours |
|---|---|---|---|---|---|
| SCH-001 *(Example)* | Swift cross-border payments | CBPR+ usage guidelines | Direct Swift member | Yearly standards release, normally live in November | Network 24/7; correspondent and settlement cut-offs apply |
| SCH-002 *(Example)* | Euro high-value RTGS | HVPS+ based guidelines of the operator | Direct participant | Operator release calendar | Operator hours |
| SCH-003 *(Example)* | SEPA Credit Transfer | EPC rulebook and implementation guidelines | Through a clearing mechanism | EPC rulebook cycle | Clearing windows |
| SCH-004 *(Example)* | SEPA Instant Credit Transfer | EPC rulebook and implementation guidelines | Through an instant clearing mechanism | EPC rulebook cycle | 24/7/365 |
| SCH-005 *(Example)* | Verification of payee | EPC Verification of Payee scheme rulebook | Requesting and responding PSP | EPC rulebook cycle | 24/7/365 |
| SCH-006 *(Example)* | Fedwire Funds Service (US) | Fedwire ISO 20022 specifications | Through a correspondent | Federal Reserve release calendar | Fedwire hours |
| SCH-007 *(Example)* | FedNow Service (US) | FedNow ISO 20022 specifications | Not participating | Federal Reserve release calendar | 24/7/365 |

Status notes to check at the source before use:

- Swift ended the MT and ISO 20022 coexistence period for cross-border
  payment instructions in November 2025; CBPR+ payment instructions now
  travel as ISO 20022 messages. Check Swift's current roadmap for the
  messages that follow separate timelines.
- On 27 August 2026 Swift deferred the payments-related changes of
  SR2026, including the end of unstructured postal addresses in CBPR+,
  after the community asked for more time. Swift will set the new
  timeline by December 2026 at the latest. The non-payments items of
  SR2026 follow a separate date: check Swift's current roadmap.
- The Bank of England deferred its November 2026 RTGS and CHAPS
  standards release in its entirety on the same day, to stay aligned
  with Swift, and will publish revised timelines on its ISO 20022 page.
- The Fedwire Funds Service moved to ISO 20022 in July 2025. On
  27 August 2026 the Federal Reserve announced that its release planned
  for November 2026 is rescheduled to November 2027, citing the Swift
  deferral.
- FedNow has used ISO 20022 since its launch.

## 3. Message set and versions

<!-- Guidance: List every message the platform sends or receives, per scheme, with the exact version identifier the usage guideline requires. Version numbers differ between schemes for the same message type, so one row per scheme and message. -->

### 3.1 Message catalogue

| ID | Message | Business purpose | Scheme | Version required | Direction |
|---|---|---|---|---|---|
| MSG-001 *(Example)* | pain.001 | Customer credit transfer initiation from corporates | Corporate channel | [Version agreed with clients, for example pain.001.001.09] | Inbound |
| MSG-002 *(Example)* | pain.002 | Status report to the initiating customer | Corporate channel | [Version] | Outbound |
| MSG-003 *(Example)* | pacs.008 | Customer credit transfer between banks | CBPR+, SEPA, SCT Inst | [Per guideline; check the usage guideline] | Both |
| MSG-004 *(Example)* | pacs.009 | Financial institution credit transfer, including cover | CBPR+, HVPS+ | [Per guideline] | Both |
| MSG-005 *(Example)* | pacs.002 | Payment status report (accept, reject, pending) | All | [Per guideline] | Both |
| MSG-006 *(Example)* | pacs.004 | Payment return | All | [Per guideline] | Both |
| MSG-007 *(Example)* | camt.056 | Request to cancel or recall a payment | All | [Per guideline] | Both |
| MSG-008 *(Example)* | camt.029 | Resolution of investigation (answer to a recall) | All | [Per guideline] | Both |
| MSG-009 *(Example)* | camt.052, camt.053, camt.054 | Intraday report, statement, debit and credit notification | CBPR+ reporting, corporate channel | [Per guideline] | Both |
| MSG-010 *(Example)* | pacs.028 | Status request for a payment | SEPA, SCT Inst | [Per guideline] | Outbound |

### 3.2 Version management

- Pin, per scheme, the standards release and its live date. *Example:*
  "CBPR+ usage guidelines for the next payments release, final version
  available [date]; live [date announced by Swift]". A deferral, such as
  the SR2026 payments deferral of 27 August 2026, keeps the release
  currently live in force: record both the pinned and the live release.
- Read the version from the usage guideline, not from the ISO 20022
  catalogue. The catalogue publishes later versions of most messages,
  while market practices keep an agreed version for several years.
- Keep one schema and validation profile per scheme and message version
  in a versioned artefact repository, with automated tests against the
  scheme's sample messages.
- Track the yearly release calendar for each scheme as a recurring work
  item with a fixed analysis, build and test window.

## 4. End-to-end flows

<!-- Guidance: Draw the main flows with the messages on each arrow. Show where status messages come back and which system tells the customer. Add one flow per exception type in section 11. -->

### 4.1 Outgoing cross-border customer payment

*Example:* a corporate client sends a file; the hub validates, screens,
reserves funds and sends the payment through the correspondent.

```mermaid
sequenceDiagram
  participant C as Corporate client
  participant H as Payments hub
  participant S as Screening and fraud
  participant G as Swift gateway
  participant K as Correspondent bank
  participant L as Ledger
  C->>H: pain.001 credit transfer initiation
  H->>H: validate against CBPR+ profile, enrich, assign UETR
  H->>S: screen parties, agents, remittance; score fraud
  S-->>H: clear
  H->>L: reserve funds and post debit
  H->>G: pacs.008 (and pacs.009 cover if needed)
  G->>K: pacs.008
  K-->>G: pacs.002 accepted or rejected
  G-->>H: status
  H-->>C: pain.002 status report
  K-->>G: camt.054 or camt.053 for nostro entries
  G-->>H: reporting
  H->>L: reconcile nostro
```

### 4.2 Outgoing SEPA Instant payment

*Example:* a retail customer pays a new payee from the mobile app; payee
verification runs before the customer authorises the payment.

```mermaid
sequenceDiagram
  participant P as Payer channel
  participant H as Payments hub
  participant V as Verification of payee service
  participant S as Screening and fraud
  participant M as Instant clearing mechanism
  participant B as Payee bank
  P->>H: payment order with payee name and IBAN
  H->>V: verify payee
  V-->>P: match, close match or no match shown before authorisation
  P->>H: authorise
  H->>S: fraud score; own customers already screened against EU sanctions lists
  H->>M: pacs.008
  M->>B: pacs.008
  B-->>M: pacs.002 accept or reject
  M-->>H: pacs.002 within the scheme time limit
  H-->>P: confirmation or failure, free of charge
```

### 4.3 Flow inventory

| ID | Flow | Trigger | Messages | Owner of customer notification |
|---|---|---|---|---|
| FLW-001 *(Example)* | Outgoing cross-border customer payment | Customer order | pain.001, pacs.008, pacs.009, pacs.002, pain.002 | Payments hub |
| FLW-002 *(Example)* | Incoming cross-border customer payment | Swift message | pacs.008, pacs.002, camt.054 | Core notification service |
| FLW-003 *(Example)* | Outgoing SCT Inst | Customer order | pacs.008, pacs.002 | Payments hub |
| FLW-004 *(Example)* | Return of an incoming payment | Operations decision or invalid account | pacs.004 | Payments hub |
| FLW-005 *(Example)* | Recall | Customer or bank request | camt.056, camt.029, pacs.004 | Payments operations |

## 5. Canonical payment model

<!-- Guidance: Define the internal payment object in ISO 20022 business terms. Keep the element names close to ISO 20022 so that mapping stays mechanical. Mark which fields each scheme makes mandatory, and which the bank always fills. -->

| ID | Canonical element | ISO 20022 element (pacs.008 path, short form) | CBPR+ | SEPA | Source in bank |
|---|---|---|---|---|---|
| CAN-001 *(Example)* | Instruction identification | PmtId/InstrId | Mandatory | Optional | Hub |
| CAN-002 *(Example)* | End-to-end identification | PmtId/EndToEndId | Mandatory | Mandatory | Customer or channel |
| CAN-003 *(Example)* | UETR | PmtId/UETR | Mandatory | [Check rulebook] | Hub, generated once |
| CAN-004 *(Example)* | Interbank settlement amount and currency | IntrBkSttlmAmt | Mandatory | Mandatory | Hub |
| CAN-005 *(Example)* | Instructed amount | InstdAmt | Conditional | Not used | Channel |
| CAN-006 *(Example)* | Charge bearer | ChrgBr | Mandatory | Fixed value | Channel or product rule |
| CAN-007 *(Example)* | Debtor (name, postal address, identification) | Dbtr | Mandatory | Mandatory | Customer master |
| CAN-008 *(Example)* | Debtor account | DbtrAcct | Mandatory | Mandatory (IBAN) | Core |
| CAN-009 *(Example)* | Debtor agent and creditor agent | DbtrAgt, CdtrAgt | Mandatory | Mandatory (BIC) in interbank messages | Reference data |
| CAN-010 *(Example)* | Creditor (name, postal address, identification) | Cdtr | Mandatory | Mandatory | Customer order |
| CAN-011 *(Example)* | Purpose and category purpose | Purp, PmtTpInf/CtgyPurp | Conditional | Optional | Customer order or rule |
| CAN-012 *(Example)* | Regulatory reporting | RgltryRptg | Conditional by corridor | Not used | Rule engine |
| CAN-013 *(Example)* | Remittance information, unstructured or structured | RmtInf | Optional | Optional, length limits apply | Customer order |
| CAN-014 *(Example)* | Ultimate debtor and ultimate creditor | UltmtDbtr, UltmtCdtr | Conditional | Optional | Customer order |

Model rules:

- Store all repeating and optional elements even when the current
  scheme does not use them, so a later scheme does not need a data model
  migration.
- Version the canonical model; a change that drops or narrows a field
  needs architecture review.
- Record the original inbound message alongside the canonical object for
  audit and investigation.

## 6. Party and postal address data

<!-- Guidance: This section usually carries most of the effort, because addresses live in channels, customer master data and legacy systems that were built for free-text lines. State the target format per party role and the remediation plan for stored data. -->

### 6.1 Address formats

| Format | Content | CBPR+ after the removal date (to be announced by Swift) |
|---|---|---|
| Fully structured | Separate elements such as street name, building number, post code, town name, country; town name and country as a minimum; no address lines | Accepted, preferred long term |
| Hybrid | Town name and country in structured elements, plus at most two free-text address lines that do not repeat structured content | Accepted |
| Unstructured | Address lines only | Rejected by the network (negative acknowledgement) |

Until the removal date applies, CBPR+ still carries unstructured
addresses; design to the target state now and do not relax the capture
controls because of the deferral. Check the current Swift CBPR+ usage
guidelines and Swift's address guidance for the exact element rules, and the rules of each other
scheme, which may set different dates and formats.

### 6.2 Address by party role

| ID | Party role | Source system | Current quality | Target format | Remediation |
|---|---|---|---|---|---|
| ADR-001 *(Example)* | Debtor (own customer) | Customer master | 92 percent with structured town and country | Fully structured | Cleanse remaining records using postal reference data; block new free-text entries |
| ADR-002 *(Example)* | Creditor (beneficiary) | Customer order in channels | Free text in mobile and branch | Hybrid at minimum | New input forms with town and country fields; corporate file validation |
| ADR-003 *(Example)* | Ultimate parties | Corporate files | Mixed | Hybrid at minimum | Client communication and file format change |
| ADR-004 *(Example)* | Agents | BIC reference data | BIC only | BIC, address not needed | None |

### 6.3 Data quality controls

- Validate town and country at capture, with a country code list and,
  where available, a postal reference service.
- Reject or repair before release; never let the gateway receive an
  address that the network would reject.
- Report daily on the share of payments with structured, hybrid and
  repaired addresses per channel.
- Avoid repeating structured content in address lines; some guidelines
  reject duplicated town or country.

## 7. Identifiers, remittance and enrichment

<!-- Guidance: Define how each identifier is created, where it is stored and who may change it (nobody, for the end-to-end ones). Describe enrichment rules that add data, such as purpose codes or LEIs, and who owns each rule. -->

| ID | Identifier or data | Created by | Rule |
|---|---|---|---|
| IDN-001 *(Example)* | UETR | Hub at first creation | UUID version 4; never regenerated on retry, repair or return |
| IDN-002 *(Example)* | End-to-end identification | Customer or channel | Passed unchanged to the creditor; the hub fills a value only when the customer gives none |
| IDN-003 *(Example)* | Instruction identification | Each instructing agent | Unique per message hop |
| IDN-004 *(Example)* | Transaction identification | Hub or clearing | Unique per scheme rules |
| IDN-005 *(Example)* | Legal entity identifier (LEI) of corporate parties | Customer master | Added when known; validated against the global LEI index |
| IDN-006 *(Example)* | Purpose code | Customer choice or rule | ISO 20022 external code set; required for some corridors |
| IDN-007 *(Example)* | Structured creditor reference | Customer | Validate check digits where the reference type allows |

Remittance design:

- Accept structured remittance from corporate files and keep it in full.
- Respect scheme length limits on outgoing messages; where a scheme
  allows less than the source, send the structured reference first and
  document the rule.
- Show remittance to the receiving customer in full in statements and
  camt.054 notifications.

## 8. Translation, truncation and coexistence

<!-- Guidance: Even after network coexistence ends, internal systems may still use legacy formats. List every translation point, what is lost there and how the loss is controlled. Untracked truncation creates screening gaps and reconciliation failures. -->

| ID | Translation point | From | To | Data at risk | Control |
|---|---|---|---|---|---|
| TRN-001 *(Example)* | Legacy core posting interface | Canonical | Fixed-length posting record | Long names, structured address, remittance | Store full data in the hub; post a reference; statements read from the hub |
| TRN-002 *(Example)* | Corporate clients still sending legacy files | Legacy file format | Canonical | Unstructured address, missing town | Reject or repair queue; client migration plan with end date |
| TRN-003 *(Example)* | Correspondent reporting still in legacy statements | Legacy statement | Canonical reporting | Missing references | Reconciliation by amount, date and partial reference; tracked exceptions |
| TRN-004 *(Example)* | Data warehouse feed | Canonical | Warehouse schema | None | Full canonical model loaded |

Truncation policy:

1. Truncation happens only in an adapter towards a named limited system.
2. Each truncation sets a flag in the canonical record and is counted on
   the operations dashboard.
3. Screening, fraud scoring, the ledger and the archive always receive
   the untruncated data.
4. Each translation point has an owner and a retirement date.

## 9. Screening, fraud and verification of payee

<!-- Guidance: Describe where each check runs in the flow, what data it sees and how long it may take. Instant payments leave very little time, so pre-screen own customers and keep in-flight checks fast. Link to the fraud design rather than repeating it. -->

| ID | Check | Position in flow | Data used | Time budget | Outcome handling |
|---|---|---|---|---|---|
| CHK-001 *(Example)* | Sanctions screening of the message | Before release, non-instant flows | All parties, agents, addresses, remittance, purpose | 2 seconds automated; manual review queue with cut-off | Hold, release or reject with reason |
| CHK-002 *(Example)* | Screening of own customers against EU targeted financial sanctions lists | Batch, at least daily and immediately after a new designation | Customer master | Not in the payment path | Block accounts of designated persons |
| CHK-003 *(Example)* | Fraud scoring | Before release, all outgoing flows | Payment, device, behaviour, payee history | 150 ms for instant | Allow, step-up, hold, reject |
| CHK-004 *(Example)* | Verification of payee (euro) | Before the payer authorises | Payee name and IBAN | Scheme time limit for the response | Show match, close match with suggested name, or no match; payer decides |
| CHK-005 *(Example)* | Incoming payment screening | After receipt, before crediting | Full message | Within scheme acceptance time for instant | Accept, reject, or credit with hold where rules allow |

Notes:

- Regulation (EU) 2024/886 inserts Articles 5a to 5d into Regulation
  (EU) No 260/2012. In brief, they cover instant credit transfers, their
  charges, the verification of the payee and the screening of the
  provider's own customers for targeted financial sanctions. Check the
  consolidated text for the binding wording and the dates for euro and
  non-euro Member States.
- Structured addresses reduce false positives in screening, which is one
  measurable benefit to report after the change.
- Details of scoring, features and model governance: fraud detection
  design (`system-design/design-fraud-detection`).

## 10. Liquidity, settlement and reconciliation

<!-- Guidance: Describe how the bank funds each scheme, how intraday liquidity is monitored for 24/7 instant flows, and how every payment is matched to settlement and nostro entries. Name the break categories and who clears them. -->

### 10.1 Liquidity

| ID | Scheme | Settlement model | Liquidity source | Monitoring | Alert threshold |
|---|---|---|---|---|---|
| LIQ-001 *(Example)* | SCT Inst | Prefunded position in the instant settlement service | Transfer from RTGS account | Real-time position feed | Below 30 percent of peak hourly outflow |
| LIQ-002 *(Example)* | CBPR+ via correspondent | Nostro account at correspondent | Treasury funding | Intraday camt.052, end-of-day camt.053 | Projected overdraft |
| LIQ-003 *(Example)* | SCT | Deferred net settlement via clearing | RTGS account | Clearing cycle reports | Settlement failure |

### 10.2 Reconciliation

| ID | Match | Keys | Frequency | Break owner |
|---|---|---|---|---|
| REC-001 *(Example)* | Outgoing payment to nostro debit | UETR, amount, value date | Intraday and end of day | Nostro reconciliation team |
| REC-002 *(Example)* | Scheme settlement to hub totals | Settlement cycle, totals by status | Each cycle | Payments operations |
| REC-003 *(Example)* | Hub postings to general ledger | Posting reference, amount | Daily | Finance operations |
| REC-004 *(Example)* | Instant position to hub balance | Position, transaction count | Continuous | Payments operations |

Posting and ledger design: payment ledger design
(`system-design/design-payment-ledger`).

## 11. Exceptions and investigations

<!-- Guidance: List the exception types, the ISO 20022 message used for each, the response time the scheme expects, and the queue that handles it. Investigation handling is where customer complaints come from; design it, do not leave it to operations alone. -->

| ID | Exception | Messages | Expected handling time | Queue | Customer communication |
|---|---|---|---|---|---|
| EXC-001 *(Example)* | Reject by the next agent | pacs.002 with reason code | Same day | Repair queue | Notify with reason in plain words |
| EXC-002 *(Example)* | Return after settlement | pacs.004 | Per scheme rule | Returns queue | Notify and credit back |
| EXC-003 *(Example)* | Customer recall request | camt.056, then camt.029 and possibly pacs.004 | Per scheme rule | Investigations | Track status in the app |
| EXC-004 *(Example)* | Status enquiry | pacs.028 or tracker query | Hours | Investigations | Status in the app |
| EXC-005 *(Example)* | Screening hold beyond cut-off | Internal | Before end of day | Financial crime | Notify of delay |

Reason codes: map each external ISO 20022 status reason code the schemes
use to an internal reason and a customer message; keep the mapping in
the reference data repository.

## 12. Non-functional and operational design

<!-- Guidance: Give measurable targets per flow and the operational controls around releases, certificates and keys. A payments platform fails in production mostly through reference data, certificates and cut-off handling, so cover those explicitly. -->

| ID | Area | Requirement | Target | Evidence |
|---|---|---|---|---|
| NFR-001 *(Example)* | Instant outgoing | Bank-internal processing time | 95th percentile under 1.5 seconds | Performance test |
| NFR-002 *(Example)* | Instant platform | Availability | 99.95 percent, 24/7/365 | SLO report |
| NFR-003 *(Example)* | All flows | No acknowledged payment lost | RPO zero | DR test |
| NFR-004 *(Example)* | Recovery | Region failover | Under 30 minutes | DR test |
| NFR-005 *(Example)* | Straight-through processing | Share of outgoing cross-border payments with no manual touch | Above 95 percent | Operations dashboard |
| NFR-006 *(Example)* | Address quality | Share of outgoing payments with structured or hybrid addresses | 100 percent before the CBPR+ removal date (to be announced by Swift) | Daily report |

Operational controls:

- Reference data (BIC directory, scheme reachability, holiday calendars,
  code sets) loaded automatically with validation and rollback.
- Certificates and keys for network connections tracked with expiry
  alerts and tested renewal procedures.
- Yearly scheme release prepared in a dedicated test environment with
  regression packs for every flow in section 4.
- Runbooks for cut-off handling, queue backlogs and scheme outages.

## 13. Testing, certification and cutover

<!-- Guidance: Plan internal tests, scheme or network certification and the cutover. Scheme testing windows are fixed and short; book them early. -->

| ID | Test | Scope | Environment | Exit criterion |
|---|---|---|---|---|
| TST-001 *(Example)* | Schema and rule validation | All messages, all versions | CI pipeline | All scheme sample messages pass; all negative samples fail |
| TST-002 *(Example)* | End-to-end flow tests | FLW-001 to FLW-005 | Integration | All pass, including exceptions |
| TST-003 *(Example)* | Address remediation | Customer master and channels | Pre-production | Unstructured rate zero on test day |
| TST-004 *(Example)* | Swift readiness testing | CBPR+ messages | Swift test network | Counterparty and network tests passed |
| TST-005 *(Example)* | Scheme certification | SCT Inst, verification of payee | Scheme test environment | Certificate issued |
| TST-006 *(Example)* | Performance | Instant flows at 3 times peak | Performance environment | NFR-001 met |
| TST-007 *(Example)* | Dress rehearsal | Full cutover | Production-like | Within planned window, rollback proven |

Cutover approach: [*Example:* switch flows scheme by scheme on a weekend;
keep the old route available for 48 hours behind a routing flag; stop
new payments on the old route at a fixed time; reconcile in-flight
payments by UETR.] Detail the runbook in the cutover plan
(`project/cutover-plan`).

## 14. Deadline register

<!-- Guidance: Keep every external date that drives the design here, with its source and the date you last checked it. Dates change: Swift, the EPC and central banks have moved dates before. -->

| ID | Date | Event | Source to check | Last checked |
|---|---|---|---|---|
| DLN-001 | 2025-01-09 | Euro-area PSPs must be able to receive instant euro credit transfers | Regulation (EU) 2024/886, consolidated text | YYYY-MM-DD |
| DLN-002 | 2025-10-09 | Euro-area PSPs must be able to send instant euro credit transfers and offer payee verification | Regulation (EU) 2024/886 | YYYY-MM-DD |
| DLN-003 | November 2025 | End of MT and ISO 20022 coexistence for CBPR+ payment instructions | Swift CBPR+ roadmap | YYYY-MM-DD |
| DLN-004 | [Date to be announced by Swift by December 2026; was 2026-11-14] | Unstructured postal addresses rejected in CBPR+; structured or hybrid required (deferred by Swift on 27 August 2026) | Swift CBPR+ roadmap and address guidance; Bank of England ISO 20022 page | YYYY-MM-DD |
| DLN-005 | November 2027 | Next Fedwire Funds Service release (moved from November 2026) | Federal Reserve Financial Services | YYYY-MM-DD |
| DLN-006 | 2027-01-09 (receive); 2027-07-09 (send, verification of payee) | Non-euro Member State deadlines under Regulation (EU) 2024/886, if the bank operates there | Consolidated text | YYYY-MM-DD |
| DLN-007 | [Date] | Next EPC rulebook versions in force | EPC website | YYYY-MM-DD |

## 15. Traceability matrix

<!-- Guidance: Link each driver to the design elements and tests that satisfy it. A deadline driver without a passing test is a delivery risk to report. -->

| Driver | Design elements | Tests | Status |
|---|---|---|---|
| DRV-001 | ADR-001 to ADR-003, section 6.3, NFR-006 | TST-001, TST-003, TST-004 | [Open / Passed] |
| DRV-002 | FLW-003, CHK-002, CHK-004, LIQ-001, NFR-001 | TST-005, TST-006 | [Open / Passed] |
| DRV-003 | CAN-001 to CAN-014, IDN-001 to IDN-007 | TST-002 | [Open / Passed] |
| DRV-004 | TRN-001, truncation policy | TST-002 | [Open / Passed] |

## 16. Glossary and references

<!-- Guidance: Define the payment terms for non-specialist reviewers, and list the exact guideline releases used. -->

### 16.1 Glossary

| Term | Meaning |
|---|---|
| ISO 20022 | International standard for financial messaging, with a repository of business components and message definitions |
| CBPR+ | Swift's market practice for cross-border payments and reporting in ISO 20022 |
| HVPS+ | Market practice for high-value payment systems that adopt ISO 20022 |
| SCT, SCT Inst | SEPA Credit Transfer and SEPA Instant Credit Transfer schemes run under EPC rulebooks |
| UETR | Unique end-to-end transaction reference, a UUID that follows a payment across all banks |
| Hybrid address | Postal address with town and country structured and at most two free-text lines |
| NAK | Negative acknowledgement: the network refuses the message |
| Verification of payee | Check, before authorisation, that the payee name matches the account holder of the IBAN |
| Nostro | Account the bank holds with a correspondent in another currency |

### 16.2 References

| Reference | Version or date | Use |
|---|---|---|
| ISO 20022 message definitions, iso20022.org | Catalogue as checked YYYY-MM-DD | Message names |
| Swift CBPR+ usage guidelines and address guidance, swift.com | SR2026 (final guidelines available since 20 February 2026); SR2026 payments changes, including the unstructured-address removal, deferred 27 August 2026, new date due by December 2026 | Sections 3, 6, 14 |
| Bank of England, delay to the November 2026 RTGS standards release, bankofengland.co.uk | 27 August 2026 | Sections 2, 14 |
| EPC SCT, SCT Inst and Verification of Payee rulebooks, europeanpaymentscouncil.eu | Versions in force on YYYY-MM-DD | Sections 2, 9 |
| Regulation (EU) 2024/886 on instant credit transfers, EUR-Lex | OJ 19 March 2024, consolidated text | Sections 9, 14 |
| Fedwire Funds Service ISO 20022 implementation center and release notice, frbservices.org | Notice of 27 August 2026; checked YYYY-MM-DD | Sections 2, 14 |
| [Market infrastructure guideline] | [Version] | [Use] |

## Standard and licence note

Based on the ISO 20022 message standard (message identifiers and
business element names), Swift CBPR+ market practice, EPC SEPA scheme
rulebooks, the Federal Reserve's published ISO 20022 information for
the Fedwire Funds Service and FedNow, and Regulation (EU) 2024/886 on
instant credit transfers. ISO 20022 element names and message
identifiers are used for reference only; no usage guideline, rulebook or
legal text is reproduced, and all descriptions are original text written
for this collection. Check the current usage guidelines, rulebooks and
the consolidated legal texts before use, because scheme releases change
every year. This is a documentation format, not legal advice. Swift,
SEPA and the scheme and infrastructure names are trademarks of their
owners; this template is not affiliated with or endorsed by them.
Template licence: MIT.