ISO 20022 message definitions and XSDs
Choose the exact message definition in the official catalogue. The base XSD checks XML structure; it does not prove compliance with a scheme profile.
OPEN OFFICIAL SOURCEIn a cover payment, the announcement and the money take different paths — reimbursement agents are the named correspondents that carry it, and there can be more than one.
Analogy: calling ahead, and a separate delivery. Imagine you call a friend abroad to say "a parcel is coming for you, here is everything about it" — then the parcel itself travels through one or two courier depots you never mentioned on the call, before it reaches your friend's local depot. The call went straight to the destination; the parcel took its own route through whichever depots could actually carry it. A cover payment works the same way: the pacs.008 announcement goes directly to the creditor's bank, while the money travels separately through however many correspondent banks it takes to get there — and those correspondents have their own name in the message: reimbursement agents.
A reimbursement agent is a correspondent bank that carries the cover value between the debtor agent and the creditor agent — distinct from the creditor agent itself, which only receives the announcement. The instructing reimbursement agent is the correspondent the debtor agent's cover payment goes to first; the instructed reimbursement agent is the correspondent that ultimately credits the creditor agent's account, completing the reimbursement. When one bank happens to serve both roles — the debtor agent's and creditor agent's shared correspondent — a single reimbursement agent is enough. When it does not, the cover has to pass through more than one.
The reimbursement agent role exists because the announcement and the cover are not required to travel the same path. The creditor agent needs to know, from the announcement alone, which correspondent to expect the cover value from — otherwise a credit notification arriving from an unnamed bank is just money with no context. Naming the instructing and instructed reimbursement agents in the pacs.008 gives every bank that later reads the message the same answer to "who is actually carrying the funds", independent of whichever bank happens to be the creditor agent for this payment.
Illustrative chain: Asha Traders pays a supplier who banks with Nordbank. Asha Traders' bank, Bank Alfa, has no shared correspondent with Nordbank in the transfer currency, so the cover has to pass through two correspondents: Meridian Bank first, then Cassia Bank, which holds an account for Nordbank. Bank Alfa's pacs.008 announcement names Meridian as instructing reimbursement agent and Cassia as instructed reimbursement agent — telling Nordbank exactly which two correspondents to expect the value from, even though neither of them is the creditor agent. Where a chain needs a third correspondent, the message adds a third reimbursement agent element — but only alongside the first two, never instead of them.
ISO 20022's pacs.008 Group Header carries InstructingReimbursementAgent, InstructedReimbursementAgent and ThirdReimbursementAgent as distinct elements, with a cross-element rule: if a third reimbursement agent is present, the first two must both be present as well — a chain cannot skip straight to naming a third correspondent without naming the two it necessarily passes through first. Presence of any reimbursement agent element is itself a signal that this pacs.008 is travelling the cover method, and CBPR+ usage guidance ties this to the settlement method element carrying the value COVE. The worked flow linked below uses a single shared correspondent, so it shows one reimbursement agent playing both roles at once — the simplest case, not the only one.
ISO 20022 Catalogue of messages ↗ — ISO 20022 Registration Authority · pacs.008 GroupHeader InstructingReimbursementAgent, InstructedReimbursementAgent, ThirdReimbursementAgent elements and their cross-element presence rule
Each message set is described by a Message Definition Report; earlier versions remain available in the ISO 20022 messages archive.
Cross-Border Payments and Reporting Plus (CBPR+) usage guidelines ↗ — Swift (CBPR+ working group) · reimbursement agent usage and settlement method COVE for the cover method
Full guidelines require MyStandards access. Public guidance states that after 14 November 2026 fully unstructured addresses are removed for in-scope CBPR+ traffic, with explicit message exceptions including admi.024, camt.025, camt.052, camt.053, camt.054 and camt.060.
After checks and screening on the structured fields, the customer account is debited and the bank chooses the cover method: announce directly to the creditor agent, and fund through correspondents.
Screening checkpoint: Outbound cross-border screening — Both the direct instruction and the cover leg are screened by every bank that touches them.
As in the serial flow, settlement is a book transfer between the two banks' USD accounts held at Meridian, the shared correspondent.
A credit notification tells Cassia the money side is complete on its account at Meridian. Now it has both halves of the payment: the instruction and the funds.
The creditor agent pairs the pacs.008 with the incoming cover by UETR, references, and amount. Crediting on the pacs.008 alone would be paying before being paid.
With instruction and funds matched, Cassia credits its customer. The cover method gives the creditor agent the details sooner, but the credit still waits for the money to actually arrive.
EVIDENCE AT ARM'S REACH
Apply the base message definition first, then the scheme or infrastructure profile that governs this topic.
An XSD checks XML structure. A usage guideline adds profile rules, conditional fields, code restrictions, and business controls. XSD-valid does not mean scheme-compliant.
Choose the exact message definition in the official catalogue. The base XSD checks XML structure; it does not prove compliance with a scheme profile.
OPEN OFFICIAL SOURCEThe network profile that restricts how ISO 20022 payment and reporting messages are used for cross-border traffic.
OPEN OFFICIAL SOURCEThe common high-value ISO 20022 market-practice layer used as a starting point by T2, CHAPS, Fedwire, CHIPS, and other payment infrastructures.
OPEN OFFICIAL SOURCENon-binding market practice for structured party data, cover payments, investigations, and the transition between MT and ISO 20022 reporting.
OPEN OFFICIAL SOURCEThe current scheme obligations, datasets, time cycles, and exception rules for a SEPA Credit Transfer.
OPEN OFFICIAL SOURCEThe EPC profile describing how the ISO 20022 messages implement the SCT rulebook between payment service providers.
OPEN OFFICIAL SOURCEThe current scheme rules for round-the-clock euro instant credit transfers and their exception handling.
OPEN OFFICIAL SOURCECustomer-to-PSP and Inter-PSP profiles for SCT Inst. EPC XSDs are technical validation subsets, not production artefacts or proof of full scheme compliance.
OPEN OFFICIAL SOURCEThe ECB release library for T2 RTGS and central-liquidity messaging, including public user specifications, business validation rules, and binding schemas.
OPEN OFFICIAL SOURCEThe ECB release library for TIPS UDFS/UHB specifications, message examples, implementation guidance, and MyStandards message-version links.
OPEN OFFICIAL SOURCEThe Bank of England handbook for CHAPS message scope, enhanced data, returns, testing, and the MyStandards location of controlling schemas.
OPEN OFFICIAL SOURCEFedwire message versions, usage guidelines, implementation guidance, testing material, and the controlled route to proprietary schemas.
OPEN OFFICIAL SOURCEThe public CHIPS ISO 20022 resource hub, legal notes, rules, change summaries, and participant material access points.
OPEN OFFICIAL SOURCEA fictional serial interbank customer credit transfer. SYNTHETIC / TRAINING ONLY; illustrative unvalidated.
DOWNLOADInitiation, customer and interbank status, payment, notification, intraday report, and statement.
DOWNLOADField correspondence, transformation treatment, and data-loss notes for Cross-border customer credit transfer translation, in the spirit of public CBPR+ and PMPG translation guidance. Educational summary — the applicable usage guideline is the rule.
DOWNLOADCurated field requirements, contexts, operational meaning, and implementation cautions.
DOWNLOADPositive and negative test cases across validation, rejection, return, recall, reversal, investigation, reconciliation, migration, instant payments, and screening.
DOWNLOADA practical control list for semantic transformation and coexistence risk.
DOWNLOADVerified profile constraints with versioned evidence and explicit operating conditions.
DOWNLOADPositive and negative lifecycle tests linked to verified profile rules.
DOWNLOADDiscovery, controls, testing and operational-readiness checks for the profile.
DOWNLOADOutcome-focused profile acceptance criteria with honest release gates.
DOWNLOADVersion, transformation, cutover and reconciliation controls.
DOWNLOADEvidence that must be obtained from the owner before production readiness can be claimed.
DOWNLOADVerified profile constraints with versioned evidence and explicit operating conditions.
DOWNLOADPositive and negative lifecycle tests linked to verified profile rules.
DOWNLOADDiscovery, controls, testing and operational-readiness checks for the profile.
DOWNLOADOutcome-focused profile acceptance criteria with honest release gates.
DOWNLOADVersion, transformation, cutover and reconciliation controls.
DOWNLOADEvidence that must be obtained from the owner before production readiness can be claimed.
DOWNLOADVerified profile constraints with versioned evidence and explicit operating conditions.
DOWNLOADPositive and negative lifecycle tests linked to verified profile rules.
DOWNLOADDiscovery, controls, testing and operational-readiness checks for the profile.
DOWNLOADOutcome-focused profile acceptance criteria with honest release gates.
DOWNLOADVersion, transformation, cutover and reconciliation controls.
DOWNLOADEvidence that must be obtained from the owner before production readiness can be claimed.
DOWNLOADVerified profile constraints with versioned evidence and explicit operating conditions.
DOWNLOADPositive and negative lifecycle tests linked to verified profile rules.
DOWNLOADDiscovery, controls, testing and operational-readiness checks for the profile.
DOWNLOADOutcome-focused profile acceptance criteria with honest release gates.
DOWNLOADVersion, transformation, cutover and reconciliation controls.
DOWNLOADEvidence that must be obtained from the owner before production readiness can be claimed.
DOWNLOADVerified profile constraints with versioned evidence and explicit operating conditions.
DOWNLOADPositive and negative lifecycle tests linked to verified profile rules.
DOWNLOADDiscovery, controls, testing and operational-readiness checks for the profile.
DOWNLOADOutcome-focused profile acceptance criteria with honest release gates.
DOWNLOADVersion, transformation, cutover and reconciliation controls.
DOWNLOADEvidence that must be obtained from the owner before production readiness can be claimed.
DOWNLOADGenerated mapping, field-matrix, test, checklist, acceptance-criteria, migration, manifest, checksum, and source-inventory bundle.
DOWNLOADGenerated mapping, field-matrix, test, checklist, acceptance-criteria, migration, manifest, checksum, and source-inventory bundle.
DOWNLOADGenerated mapping, field-matrix, test, checklist, acceptance-criteria, migration, manifest, checksum, and source-inventory bundle.
DOWNLOADGenerated mapping, field-matrix, test, checklist, acceptance-criteria, migration, manifest, checksum, and source-inventory bundle.
DOWNLOADGenerated mapping, field-matrix, test, checklist, acceptance-criteria, migration, manifest, checksum, and source-inventory bundle.
DOWNLOADGenerated mapping, field-matrix, test, checklist, acceptance-criteria, migration, manifest, checksum, and source-inventory bundle.
DOWNLOADGenerated mapping, field-matrix, test, checklist, acceptance-criteria, migration, manifest, checksum, and source-inventory bundle.
DOWNLOADGenerated mapping, field-matrix, test, checklist, acceptance-criteria, migration, manifest, checksum, and source-inventory bundle.
DOWNLOADISO 20022 Catalogue of messages ↗ — ISO 20022 Registration Authority · pacs.008 GroupHeader reimbursement agent elements
Each message set is described by a Message Definition Report; earlier versions remain available in the ISO 20022 messages archive.
Cross-Border Payments and Reporting Plus (CBPR+) usage guidelines ↗ — Swift (CBPR+ working group) · reimbursement agent usage in the CBPR+ correspondent-banking profile
Full guidelines require MyStandards access. Public guidance states that after 14 November 2026 fully unstructured addresses are removed for in-scope CBPR+ traffic, with explicit message exceptions including admi.024, camt.025, camt.052, camt.053, camt.054 and camt.060.
Payments Signal editorial teaching models — Payments Signal
What this simplifies: The two- and three-correspondent chains are invented illustrations with no real institutions, references, or amounts; real reimbursement chains are set by whichever account relationships actually exist for the currency in question.
Used wherever diagrams, scenarios, figures, or example values are didactic constructions rather than sourced facts; every such use carries a simplifications disclosure. All people, companies, banks, and list entries in examples are fictional.
Deepest material on this page: L4 — Standards & sources. Where a topic stops short of implementation depth, that is a deliberate coverage decision, not an oversight — see coverage.
Share an operational observation or ask a concrete payments question. Your name and message are public; your email remains private.
Loading the discussion…