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.

Document control

Approvals

Revision history

Contents

1. Scope and drivers
2. Scheme and infrastructure register
3. Message set and versions
4. End-to-end flows
5. Canonical payment model
6. Party and postal address data
7. Identifiers, remittance and enrichment
8. Translation, truncation and coexistence
9. Screening, fraud and verification of payee
10. Liquidity, settlement and reconciliation
11. Exceptions and investigations
12. Non-functional and operational design
13. Testing, certification and cutover
14. Deadline register
15. Traceability matrix
16. Glossary and references

1. Scope and drivers

1.1 Scope

1.2 Drivers

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

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

3.1 Message catalogue

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

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.

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.

4.3 Flow inventory

5. Canonical payment model

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

6.1 Address formats

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

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

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

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

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

10.1 Liquidity

10.2 Reconciliation

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

11. Exceptions and investigations

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

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

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

15. Traceability matrix

16. Glossary and references

16.1 Glossary

16.2 References

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.