RTGS on ISO 20022: T2, CHAPS, and Fedwire Compared

RTGS means every payment settles individually and finally in central bank money, which is why liquidity, queueing, and prioritisation are design concerns rather than treasury details. T2, CHAPS, and Fedwire all run ISO 20022 and all constrain it differently, so a message built for one is not valid for another. And enhanced data mandates make these implementations a standing obligation, not a project.

A payment of 40 million euro leaves at 14:32 and is final at 14:32. Not provisionally, not subject to end-of-day netting, not recoverable. The receiving bank has central bank money and the sending bank does not.

That finality is the whole point of real-time gross settlement, and it is the property from which every other characteristic follows. This continues the scheme track of The ISO 20022 Reference, after Verification of Payee.

What gross settlement actually changes

Two words carry the design.

Real-time: settlement happens when the payment is processed, not at a batch cycle.

Gross: each payment settles on its own, in full. Nothing is netted against anything else.

The consequences follow directly:

• Finality is immediate and irrevocable. There is no unwind. Like instant payments, every control must run before settlement.
• Liquidity must be present at the moment of settlement. A bank sending 40 million needs 40 million in its central bank account then, not at end of day. It cannot rely on incoming payments arriving first.
• Queues exist, and position in them matters. When liquidity is insufficient, payments queue. Systems provide prioritisation, reservations, and optimisation mechanisms so that critical payments settle ahead of routine ones.
• Timing is operational. Cut-offs, the order in which you release payments, and how much liquidity you pre-position are daily decisions with real cost.

For an analyst this is the shift that matters: on a low-value scheme, settlement is background infrastructure. On an RTGS, settlement is a feature your system must participate in, with prioritisation flags, liquidity checks, queue visibility, and a treasury interface.

The three systems, and how they differ

	T2 (euro)	CHAPS (sterling)	Fedwire Funds (US dollar)
Operator	Eurosystem	Bank of England	Federal Reserve
ISO 20022 since	March 2023	June 2023	July 2025
Migration style	Consolidated launch	Migration then phased data mandates	Single-day cutover
Distinctive feature	Separate liquidity management layer	Progressive enhanced data mandates	Big-bang, no coexistence

T2 replaced TARGET2 in a consolidation that did more than change formats. It separated liquidity management from settlement: a Central Liquidity Management component holds main cash accounts and moves liquidity, while the RTGS component settles on dedicated cash accounts. For a participating bank, that means monitoring and moving liquidity between components is now an explicit operational task, and a payment can fail to settle because liquidity sits in the wrong account rather than because the bank lacks funds.

CHAPS migrated and then kept going. The Bank of England has progressively required richer content: purpose codes on defined payment types, Legal Entity Identifiers for certain financial institution payments, structured addresses. Fields move from optional to mandatory on a published timetable. Because that timetable evolves, read the current mandates from the Bank of England’s own scheme documentation rather than from any article, including this one.

Fedwire did something different: a single-day cutover in July 2025 with no coexistence period. Everyone had to be ready on the same date. That concentrates risk rather than spreading it, and it changes the testing strategy completely, which is the point worth extracting.

What the migration styles teach

The three approaches fail in different ways, and if you are planning a migration to any scheme, this is the transferable part.

Phased mandates (CHAPS style) spread effort, which sounds kind and creates a specific trap: a team treats the first mandate as the project, declares success, and disbands. The second and third mandates then arrive with no owner and no budget. If your scheme uses phased mandates, the deliverable is not an implementation, it is a standing capability with a named owner watching the timetable, exactly as with the SEPA rulebook cycle.

Big-bang cutover (Fedwire style) removes ambiguity: one date, one format, everyone moves. It also removes your fallback. There is no period of accepting both formats while you fix an edge case, so contingency has to be real, rehearsed, and decided in advance. The analyst deliverables that actually matter for a big-bang are the cutover runbook, the go/no-go criteria agreed weeks ahead, and the rollback position, which for a scheme cutover is usually “there is none, so the criteria must be conservative.” The go/no-go call covers making that defensible.

Coexistence (the CBPR+ approach, where MT and ISO ran in parallel until the coexistence period ended in November 2025) is gentlest and longest, and its trap is that coexistence makes it easy to postpone. Teams translate rather than migrate, keep the legacy path alive, and lose the data benefits the whole exercise was for. The truncation ledger is what that costs.

One standard, three profiles

The most expensive assumption in multi-scheme work: that ISO 20022 makes the message portable.

It does not. All three systems use pacs.008, pacs.009, and the camt family, and each constrains them through its own usage guidelines. Differences appear in field optionality, permitted code values, character sets, identification requirements, maximum lengths, and which structural elements are allowed at all.

So a bank operating across euro, sterling, and dollar high-value systems needs a per-scheme profile, with the net rule per field determined from that scheme’s guidelines. The four layers method is exactly the tool, applied three times.

The design implication worth flagging early: build the scheme profile as configuration, not as branching code. Three schemes today becomes five schemes in two years, and a codebase with if (scheme == "CHAPS") scattered through it becomes unmaintainable at about the fourth. The field rules belong in a rules table with a version and an owner.

What enhanced data actually demands

Purpose codes, LEIs, and structured addresses are the three recurring mandates, and each has a data problem behind it that is not a messaging problem.

Purpose codes need to come from somewhere. The customer must supply them, or a product rule must derive them, and neither exists by default. See purpose codes, including why you must never infer them from free text.

LEIs need to be held, kept current, and validated. That is a reference data programme touching customer onboarding, not a field mapping.

Structured addresses need address data that was captured as components. Most banks hold addresses as free-text lines because that is what legacy systems accepted, so the mandate becomes a data remediation exercise across the whole customer base. Structured addresses covers the scale of that, and it is consistently the most underestimated item in these programmes.

The pattern: the message change is small, the data change is large. When scoping, put the data remediation on the critical path, because it has the longest lead time and it cannot be compressed by adding developers.

What to specify and test

Specification:

1. The per-scheme field profile, as versioned configuration with an owner.
2. Liquidity checking before release, and behaviour when funds are insufficient: queue, reject, or hold.
3. Payment prioritisation: who sets priority, on what basis, and whether it can be changed once queued.
4. Cut-off handling, including what happens to a payment submitted after cut-off.
5. The enhanced data sources: where the purpose code, the LEI, and the structured address come from, per payment type.
6. The mandate watch: named owner, timetable source, assessment cadence.

Test conditions worth the effort:

• A payment that queues for insufficient liquidity, then settles when liquidity arrives, asserting the status progression the customer sees.
• A high-priority payment overtaking queued lower-priority ones.
• A payment submitted after cut-off, asserting the resulting value date.
• The same logical payment built for two different schemes, asserting each matches its own profile and would fail the other’s validation. This one proves the profile mechanism actually works.
• A payment missing a newly mandatory enhanced data field, rejected by your own validation before the scheme sees it.
• A structured address assembled from a legacy free-text record, asserting the transformation rule rather than hoping.

The takeaway

RTGS settles each payment individually and finally in central bank money, which makes liquidity, queueing, and prioritisation part of your system design rather than someone else’s problem. Finality means every control runs before settlement, with no unwind.

T2, CHAPS, and Fedwire all run ISO 20022 and all constrain it differently, so build per-scheme profiles as configuration and assume nothing is portable. The migration styles teach different lessons: phased mandates need a standing owner rather than a project, and a big-bang cutover needs conservative go/no-go criteria because there is no fallback.

And in every case, the messaging change is small while the data remediation behind purpose codes, LEIs, and structured addresses is large. Put that on the critical path.

Next: which payment rail to use, which pulls the whole scheme track into one decision. The full map is on The ISO 20022 Reference.

Ahmed is a Senior Technical Business Analyst with 10+ years in banking and payments. He builds practical guides and tools for analysts at The Tech BA Toolkit.

Tags: ISO 20022, RTGS, Payments, Banking, Systems Analysis