ISO 20022 testing requirements

Artifacts a network, partner bank, or examiner requests

Evidence requests for an ISO 20022 implementation come from the payment network during onboarding and release testing, from correspondent or sponsor banks, and from internal audit or an examiner who reviews payment change management. For the Fedwire Funds Service migration, Federal Reserve Financial Services published a Testing Attestation Form for MyStandards Readiness Portal testing, and Wholesale Testing Services confirmed DIT2 certification testing without a form.

• Message inventory: each message identifier, version, and direction per network, for example pacs.008.001.08 outbound on CBPR+.
• Usage guideline validation results: pass and fail per rule, with the guideline release and the test date.
• Field mapping specification: the internal data model mapped to ISO 20022 elements, with truncation, default, and transliteration rules.
• Address data evidence: parties grouped by structured, hybrid, and unstructured format, with the remediation plan before 14 November 2026.
• Return, reject, and recall test cases: each reason code with the expected customer status and ledger entry.
• Statement reconciliation evidence: camt.053 and camt.054 entries matched to ledger balances for a defined test period.
• Release regression results: a rerun after each Swift Standards MX release, including the release in the second full weekend of November 2026.
• Code set version record: the external code set version that the platform maps and the date of the last update.

Common findings

• Remittance cut to fit one line. A platform writes a list of twelve invoice numbers into one unstructured remittance line and cuts the text at 140 characters. The payee receives a partial reference and cannot match the invoices. The defect breaks the remittance mapping: the ISO 20022 message definition carries a list of invoices as Structured Remittance Information, with one Referred Document Information entry per invoice, and the platform never uses it.
• Address stored as one text field. Customer addresses sit in one free-text column, so the mapping can only produce Address Line elements. Swift rejects these CBPR+ payments at network level from 14 November 2026, and EPC schemes stop accepting unstructured addresses from 15 November 2026.
• New UETR on a return. The platform generates a new UETR for a pacs.004 return instead of referring to the original UETR. The pacs.004 message has an Original UETR element for this reference, and the CBPR+ pacs.004 usage guideline makes it mandatory. Operations cannot link the return to the payment, and the customer stays debited until a manual investigation.
• Header and namespace out of step. After a version upgrade, the header message definition identifier keeps the old version while the document uses the new namespace. CBPR+ requires an exact match.
• Timestamp in Z format. The platform writes the header creation time as 2026-09-16T09:30:00Z. The CBPR+ date and time pattern requires a numeric offset such as +00:00, so the message fails validation.
• Credit booked twice. The ledger posts a credit from a camt.054 notification and posts the same credit again from the end-of-day camt.053 statement. A bank can report the same booked entry in camt.054 and again in camt.053. Account Servicer Reference is an optional element of the entry, so the deduplication key comes from the bank's implementation guide: that reference when the bank fills it in, otherwise amount, booking date, and entry reference. The available balance overstates funds until a reconciliation run finds the duplicate.
• Reason codes frozen at go-live. Return reason codes sit in a static table from the launch date. The ISO 20022 Registration Authority publishes external code sets outside the message schema and updates them on a quarterly cycle, so a new code arrives without a message version change and falls into a generic failure path.