Payment Message Types: SWIFT, ISO 20022 and Blockchain

1. Why This Topic Matters for the CAMS Exam

Every anti-money laundering (AML) and sanctions control that a financial institution applies to a payment depends on one thing: the data that travels with the payment. If the originator name is missing, the beneficiary address is truncated, or the remittance purpose is buried in a free-text field, the screening engine has nothing reliable to match against. This is why the ACAMS CAMS syllabus places payment message formats inside the domain of Data Onboarding and Screening Technology. You are expected to understand what information a payment message carries, where that information sits, how it is screened, and what happens when the message structure itself becomes a vulnerability.

The regulatory anchor is FATF Recommendation 16 (Wire Transfers) and its national implementations – the US Travel Rule (31 CFR 1010.410(f)), the EU Funds Transfer Regulation (Regulation 2015/847, extended to crypto-assets by Regulation 2023/1113), and similar rules worldwide. These require that originator and beneficiary information accompany transfers through the whole payment chain. Some of the largest enforcement actions in AML history – including multi-billion-dollar penalties against banks that engaged in wire stripping (deliberately removing the names of sanctioned parties from SWIFT messages) – were fundamentally about payment message content. Examiners therefore love this topic because it ties technology, regulation and typologies together.

2. What Payment Messages Are

A payment message is a standardised electronic instruction exchanged between financial institutions to move value. It is important to separate two concepts that candidates frequently confuse:

• Messaging – the transmission of the instruction and its data (what SWIFT does).
• Clearing and settlement – the actual movement of funds between accounts, carried out by correspondent banks, RTGS systems (such as Fedwire, CHAPS or TARGET2) or clearing houses (such as CHIPS).

SWIFT does not hold or move money. It carries the message; the settlement happens elsewhere. A question that describes SWIFT as a settlement or clearing system is describing it incorrectly.

3. SWIFT and the MT Message Family

What SWIFT is: The Society for Worldwide Interbank Financial Telecommunication is a member-owned cooperative headquartered in Belgium, founded in 1973. It connects more than 11,000 institutions in over 200 countries. Each participant is identified by a BIC (Business Identifier Code, ISO 9362), often called a SWIFT code.

MT message categories (know the first digit):
• MT 1xx – Customer payments and cheques (e.g., MT103).
• MT 2xx – Financial institution transfers (e.g., MT202, MT202 COV).
• MT 3xx – Treasury markets (FX, money markets, derivatives).
• MT 4xx – Collections and cash letters.
• MT 5xx – Securities.
• MT 7xx – Documentary credits and guarantees (trade finance – highly relevant to trade-based money laundering).
• MT 9xx – Cash management and account statements (e.g., MT940, MT950).

The three messages you must know in detail:

MT103 – Single Customer Credit Transfer. Used when at least one party (originator or beneficiary) is a customer, not a bank. Key fields: Field 50 (Ordering Customer – the originator), Field 52 (Ordering Institution), Field 56 (Intermediary Institution), Field 57 (Account With Institution – the beneficiary bank), Field 59 (Beneficiary Customer), Field 70 (Remittance Information – free text), Field 71 (Charges), Field 72 (Sender to Receiver Information – free text). Fields 50, 59, 70 and 72 are the primary targets for sanctions and AML screening because they contain names, addresses and narrative.

MT202 – General Financial Institution Transfer. A bank-to-bank message with no customer information. Appropriate for genuine interbank movements (e.g., settling an FX deal or funding a nostro account).

MT202 COV – Cover Payment. Introduced in 2009 in response to concerns raised by the Wolfsberg Group and The Clearing House. In a cover payment, the originating bank sends the MT103 directly to the beneficiary bank while sending a separate interbank message to its correspondent to fund the payment. Before 2009, the plain MT202 used for this purpose carried no originator or beneficiary details, so intermediary banks could not screen the underlying parties – a transparency gap that was exploited to move funds for sanctioned countries. The MT202 COV adds a mandatory sequence B that replicates the originator (Field 50) and beneficiary (Field 59) from the underlying MT103. Exam point: a bank that routinely uses plain MT202 messages for payments that actually have underlying customers is a red flag for deliberate concealment.

Serial vs cover method: In the serial method, a single MT103 passes sequentially through every bank in the chain, so each intermediary sees the full customer data. In the cover method, the customer message and the funding message travel separately – hence the need for MT202 COV.

Weaknesses of the MT format relevant to screening:
• Field lengths are limited (typically 4 lines of 35 characters), so names and addresses are truncated or abbreviated.
• Name, street, city and country are often jammed into unstructured lines, making it hard for a screening engine to know what is a name and what is a town.
• Free-text fields (70 and 72) can be used to hide party names or purposes, or to pass coded instructions.
• Data can be stripped, altered or omitted by a party in the chain.
• Unstructured data generates high false positive rates – a city called 'Cuba' in a New Mexico address, or a surname that matches a sanctioned entity's name.

SWIFT compliance tools you may see referenced: SWIFT KYC Registry (shared correspondent due diligence), Sanctions Screening and Sanctions Testing services, the Customer Security Programme (CSP) for cyber hygiene, and SWIFT gpi (global payments innovation), which introduced the UETR – Unique End-to-end Transaction Reference – allowing a payment to be tracked across every hop in the chain.

4. ISO 20022 and the MX Message Family

What it is: ISO 20022 is an open, international standard for financial messaging built on an XML data model. It is not owned by SWIFT; it is maintained by the International Organization for Standardization, although SWIFT is the registration authority. It is already used by SEPA, Fedwire, CHIPS, TARGET2, CHAPS and many domestic systems, and SWIFT is migrating cross-border payments from MT to MX under the CBPR+ (Cross-Border Payments and Reporting Plus) guidelines. The MT/MX coexistence period began in March 2023 and ends in November 2025, after which MT 1xx, 2xx and 9xx messages are retired for cross-border payments.

MT to MX mapping you should memorise:
• MT103 → pacs.008 (FI to FI Customer Credit Transfer).
• MT202 / MT202 COV → pacs.009 (Financial Institution Credit Transfer; the COV variant carries the underlying customer data).
• Payment return → pacs.004.
• MT940/950 statement → camt.053.
• Cancellation request (MT192/MT292) → camt.056.
• Customer-initiated payment instruction (corporate to bank) → pain.001.

The naming logic: pacs = payments clearing and settlement (bank-to-bank), pain = payments initiation (customer-to-bank), camt = cash management (reporting, investigations).

Why ISO 20022 is a step change for screening technology:
• Structured parties: dedicated elements for Debtor, Creditor, Ultimate Debtor, Ultimate Creditor, Debtor Agent, Creditor Agent and Intermediary Agents. 'Ultimate' parties expose the real originator or beneficiary behind a payment made on someone else's behalf – a critical AML enhancement.
• Structured addresses: separate tags for street name, building number, post code, town, country sub-division and country code. A screening engine can now apply country risk rules without guessing which part of a free-text line is the country.
• Identifiers: support for the LEI (Legal Entity Identifier), dates of birth, national IDs and passport numbers, allowing more precise name matching and fewer false positives.
• Purpose codes and structured remittance information replace narrative descriptions.
• Richer data capacity – far longer fields, reducing truncation.
• UETR carried natively for end-to-end tracking.

Challenges and risks during migration (frequent exam angle):
• Translation truncation: when a rich MX message is converted to a legacy MT message for a bank that has not migrated, data that does not fit is cut off. Institutions must ensure that compliance-relevant data is not lost and that screening is performed on the full MX message, not the truncated MT version.
• Screening engines, case management systems and rule libraries must be reconfigured to read XML elements rather than MT fields; otherwise, new structured data goes unscreened.
• More data elements mean more matching opportunities – both for genuine hits and, initially, for alerts that need tuning.
• Mixed-format environments make it harder to apply consistent rules across all payment rails.

5. Blockchain and Distributed Ledger Payments

What it is: A blockchain is a distributed, append-only ledger in which transactions are grouped into blocks, cryptographically linked and validated by a network of nodes rather than a central operator. Virtual assets such as Bitcoin, Ether and stablecoins move by transferring value between wallet addresses – alphanumeric strings controlled by private keys. Each transaction is identified by a transaction hash.

Key distinctions from SWIFT/ISO 20022:
• A blockchain transaction does settle value – it is messaging and settlement in one.
• The transaction record contains sending address, receiving address, amount, timestamp and (sometimes) a memo – but no built-in originator or beneficiary name, address or account number. Addresses are pseudonymous, not anonymous.
• Public blockchains are transparent and permanent; anyone can inspect the ledger. Permissioned (private) ledgers restrict who can read and write.
• Unhosted (self-hosted) wallets are controlled by individuals without an intermediary, so there is no regulated entity to perform CDD.

AML implications and the Travel Rule for virtual assets: In 2019 FATF extended Recommendation 16 to Virtual Asset Service Providers (VASPs), requiring that originator and beneficiary information be obtained, held and transmitted alongside virtual asset transfers above the threshold (USD/EUR 1,000 in FATF guidance; USD 3,000 under the US rule). Because the blockchain itself cannot carry this data in a structured, compliant way, the industry developed off-chain travel rule messaging solutions (examples include TRISA, OpenVASP/TRP, Notabene, Sygna Bridge and others) using the IVMS 101 data standard – effectively the ISO 20022 equivalent for VASP-to-VASP identity data. Interoperability between competing solutions and the sunrise issue (counterparties in jurisdictions that have not yet implemented the rule) remain major challenges.

Screening on blockchain rails – blockchain analytics: Instead of screening names in message fields, compliance teams screen wallet addresses and transaction histories. Analytics providers cluster addresses into entities, label them (exchanges, mixers, darknet markets, ransomware wallets, OFAC-sanctioned addresses) and compute risk scores based on direct and indirect exposure. OFAC now lists specific digital currency addresses on the SDN List, and sanctions screening must include them. Red flags include the use of mixers/tumblers, privacy coins, chain-hopping across multiple assets, rapid movement through many addresses (peel chains), interaction with high-risk or sanctioned addresses, and structuring just below the travel rule threshold.

6. How Screening Technology Processes Payment Messages

Regardless of format, the workflow is similar:
1. Ingestion – the payment system passes the message to the screening engine before execution (real-time, pre-settlement screening for sanctions) and/or after execution (post-event transaction monitoring for AML).
2. Parsing – the engine extracts the relevant fields: MT 50/52/56/57/59/70/72, MX Debtor/Creditor/Agents/Ultimate parties/Remittance, or blockchain addresses and counterparties.
3. Matching – names and identifiers are compared against sanctions lists, PEP lists, internal watchlists, embargoed countries and high-risk keywords using exact, fuzzy and phonetic algorithms. Structured data (ISO 20022) allows field-specific rules, e.g., matching country codes exactly while applying fuzzy logic to names.
4. Alert generation and disposition – potential hits stop the payment pending review; analysts investigate, escalate true matches and document false positives.
5. Tuning and testing – thresholds are calibrated, and test messages (including SWIFT Sanctions Testing) are run to prove coverage of all fields and formats.

Governance expectations include: screening all parties in a message (not just the customer), screening both inbound and outbound payments, ensuring that cover payments carry and are screened for underlying party data, monitoring for repeated use of free text to carry names, and having controls against data manipulation by employees.

7. Exam Tips: Answering Questions on Payment Message Types: SWIFT, ISO 20022 and Blockchain

Tip 1 – Separate messaging from settlement. If an answer option says SWIFT 'settles', 'clears' or 'holds' funds, it is wrong. SWIFT is a secure messaging network. Blockchain, by contrast, performs both functions.

Tip 2 – Know your message numbers and their purpose. Expect questions such as 'Which message is appropriate for a cover payment with an underlying customer?' The answer is MT202 COV (or pacs.009 COV in ISO 20022). MT103 = customer transfer; MT202 = pure bank-to-bank; MT 7xx = trade finance (documentary credits); MT 9xx = statements.

Tip 3 – Recognise the cover-payment transparency red flag. A correspondent bank that notices a respondent repeatedly sending plain MT202 messages when the volume and pattern suggest underlying customer payments should treat this as a potential concealment typology. The correct response in a scenario question is usually to investigate, request information and consider filing a report – not to assume a technical error.

Tip 4 – Identify the screening-relevant fields. When asked which fields are most important to screen in an MT103, select Field 50 (ordering customer), Field 59 (beneficiary customer), and the free-text Fields 70 and 72. Free text is where names and purposes are hidden.

Tip 5 – ISO 20022 questions are about structured, richer data. The 'best' benefit answer will mention structured addresses, country codes, Ultimate Debtor/Creditor, LEI or reduced false positives. The 'best' risk answer will mention truncation during MT/MX translation or screening engines not configured for XML elements. If a scenario describes a bank translating MX to MT and screening only the MT version, the problem is loss of data before screening.

Tip 6 – Memorise the key mappings. MT103 → pacs.008; MT202/202 COV → pacs.009; MT940 → camt.053; pain.001 = customer initiation. 'pacs' is bank-to-bank, 'pain' is customer-to-bank, 'camt' is reporting.

Tip 7 – Blockchain questions revolve around pseudonymity and the travel rule. The ledger does not carry originator/beneficiary identity, so VASPs need off-chain travel rule solutions and blockchain analytics. Remember that FATF extended Recommendation 16 to VASPs in 2019, that OFAC lists digital currency addresses, and that unhosted wallets, mixers and privacy coins are elevated-risk indicators. Blockchain is pseudonymous, not anonymous – an answer claiming transactions cannot be traced is usually a distractor.

Tip 8 – Apply the 'most complete control' principle. CAMS answers favour the option that addresses the root cause across the whole payment chain: screening all parties, ensuring data integrity end to end, and ensuring cover and serial payments are treated consistently. Options that fix only one message type, or rely solely on the originating bank, are typically incomplete.

Tip 9 – Watch for wire stripping scenarios. If a question describes employees altering or deleting party names, replacing a sanctioned bank's name with the correspondent's name, or instructing clients to omit information, the correct identification is sanctions evasion through message manipulation, and the appropriate response involves escalation, potential reporting and remediation of controls – never 'process the payment because it passed screening'.

Tip 10 – Read the scenario for the role of the institution. An intermediary bank's obligations differ from the originating bank's. Intermediaries must screen the data they receive and must not strip it; they are not expected to perform full CDD on the originator but are expected to detect missing or incomplete information and have procedures for handling it (reject, suspend, request information, or risk-based decision), consistent with FATF Recommendation 16.

8. Quick Revision Checklist

• SWIFT = messaging cooperative, Belgium, 1973, BIC codes, no settlement.
• MT103 customer transfer; MT202 bank-to-bank; MT202 COV cover payment carrying underlying parties (2009, Wolfsberg/Clearing House).
• Serial vs cover payment methods.
• Screen Fields 50, 59, 70, 72; weakness = truncation, free text, stripping, false positives.
• ISO 20022 = XML, structured, richer; pacs.008 / pacs.009 / pacs.004 / camt.053 / camt.056 / pain.001; coexistence March 2023 – November 2025 (CBPR+); UETR; LEI; Ultimate Debtor/Creditor; risk of translation truncation.
• Blockchain = distributed ledger, pseudonymous addresses, messaging plus settlement, no native party data; FATF 2019 VASP travel rule; IVMS 101; blockchain analytics; OFAC-listed addresses; red flags = mixers, privacy coins, unhosted wallets, chain-hopping.
• FATF R.16, US Travel Rule, EU Regulation 2015/847 and 2023/1113 require originator and beneficiary information to accompany transfers.

Master these points and you will be able to handle both the knowledge-recall and the scenario-based questions that CAMS uses to test payment message types and screening technology.