Reading List
SWIFT and ISO 20022 Message Reference Reading List
Most SWIFT and ISO 20022 material explains what the standards are. Almost none of it tells an operator which field to look at when a payment arrives short, stalls in a correspondent chain, or reconciles against nothing. This reading list is built the other way round — it runs from rail selection through the outbound message, its ISO 20022 equivalent, the cover-payment leg, initiation and status reporting, account reporting, investigations, tracing, and finally the charge option that quietly explains most 'missing money' tickets. Read in order it is a course; read individually each entry is a lookup you can keep open next to a payment file.
Who this is for
Payment operations and treasury teams handling cross-border payments, implementation engineers mapping MT to ISO 20022 during migration, and support teams who have to answer 'where is my money' with a field reference rather than a guess.
Reading order
The full reading list
-
SWIFT Payment Costs and Rail Selection: The Operator's Decision Guide
Start here. The decision layer above the message formats: what SWIFT actually costs, how gpi changed tracking, and when a correspondent chain is the right rail versus a local alternative. Everything else in this list assumes you have already chosen to send over SWIFT.
14 min read
-
MT103 Field-by-Field: The Operator Reference
The single customer credit transfer, field by field. What sits in :50K:, :59:, :71A: and :72:, which fields are mandatory, and which ones correspondents actually read when they decide how to route and how much to deduct.
14 min read
-
MT103 to pacs.008 Field Mapping: The Operator Reference
The migration reference. Which MT103 field becomes which pacs.008 element, where the mapping is clean, and — more usefully — where it is lossy, because truncation during MT-to-ISO translation is a live cause of failed straight-through processing.
14 min read
-
MT202 COV and pacs.009 COV: The Cover-Payment Operator Reference
Cover payments are the leg most operators never see and cannot debug. MT202 COV and pacs.009 COV carry the underlying customer details alongside the bank-to-bank settlement instruction; when a payment is visible at neither end, this is usually where it is.
13 min read
-
pain.001 and pain.002: The Payment Initiation and Status Reference
The corporate-to-bank side. pain.001 initiates, pain.002 reports status — and the status codes in pain.002 are the difference between knowing a batch was rejected and discovering it from a customer complaint days later.
12 min read
-
camt.052, camt.053 and camt.054: The Account Reporting Operator Reference
Intraday, end-of-day, and debit/credit notification reporting. Which camt message answers which reconciliation question, and why picking the wrong one produces a reconciliation process that is always a day behind.
13 min read
-
ISO 20022 Investigation Messages: A camt Operator Reference
When something has already gone wrong: the camt investigation family for recalls, claims of non-receipt, and cancellation requests. The structured alternative to emailing a correspondent and hoping.
13 min read
-
Tracing a SWIFT Payment: UETR, gpi, and Where It Gets Stuck
The operational skill that closes tickets. How to use the UETR and gpi status codes to find where a payment actually stopped — and the common misconception that a UETR implies gpi tracking, when UETRs have been mandatory on these messages for years.
14 min read
-
OUR, SHA, and BEN: Why SWIFT Payments Arrive Short
Finish here, because this is the answer to the most frequent support question in cross-border payments. OUR, SHA and BEN determine who absorbs correspondent deductions — and why a beneficiary receives less than the sender instructed without anything having gone wrong.
7 min read