A bank selects an authorized correspondent route, proves that messaging permission and settlement reach are separate, and stops safely when either control is missing.
The instruction identifies the beneficiary, amount, currency and requested date. It does not yet choose the next SWIFT hop or prove that the bank can settle USD to Cassia.
Step 1 of 8: Treasury asks Bank Alfa to pay a USD supplier
01Message
Treasury asks Bank Alfa to pay a USD supplierAsha Traders treasury → Bank Alfa (ordering bank)
02Processing
Bank Alfa proves the route before releasing valueBank Alfa (ordering bank)
03Posting
Bank Alfa debits the customer after route acceptanceBank Alfa (ordering bank)
04Message
The MT103 goes to the authorized correspondentBank Alfa (ordering bank) → Meridian Bank (USD correspondent) · MT103
05Processing
Meridian performs its own controlsMeridian Bank (USD correspondent)
06Settlement
Meridian settles across the correspondent accountsMeridian Bank (USD correspondent)
07Message
Meridian forwards the customer paymentMeridian Bank (USD correspondent) → Cassia Bank (beneficiary bank) · MT103
08Posting
Cassia credits Northstar ComponentsCassia Bank (beneficiary bank) → Northstar Components
MESSAGECLEARING OBLIGATIONSETTLEMENTPOSTING
Full step-by-step text (works without JavaScript)
01Message
Treasury asks Bank Alfa to pay a USD supplierAsha Traders treasury → Bank Alfa (ordering bank)
The instruction identifies the beneficiary, amount, currency and requested date. It does not yet choose the next SWIFT hop or prove that the bank can settle USD to Cassia.
02Processing
Bank Alfa proves the route before releasing valueBank Alfa (ordering bank)
Bank Alfa has no direct RMA with Cassia. Its routing engine selects Meridian and checks three separate facts: the required RMA authorizations exist, the current SSI names the right USD correspondent and account, and Meridian can settle onward to Cassia.
03Posting
Bank Alfa debits the customer after route acceptanceBank Alfa (ordering bank)
Only after the route and controls pass does Bank Alfa book the customer debit and release the interbank payment.
DR Asha Traders USD operating account — USD 85,000.00
04Message
The MT103 goes to the authorized correspondentBank Alfa (ordering bank) → Meridian Bank (USD correspondent) · MT103
The lack of direct RMA with Cassia is not bypassed. Bank Alfa sends to Meridian because that bilateral hop is authorized and Meridian is the agreed account and routing provider for USD.
05Processing
Meridian performs its own controlsMeridian Bank (USD correspondent)
Meridian validates the message, checks Bank Alfa's balance and authority, screens the payment and confirms its route to Cassia. Bank Alfa's checks do not replace Meridian's responsibility.
06Settlement
Meridian settles across the correspondent accountsMeridian Bank (USD correspondent)
The RMA allowed messages to arrive; the account relationship is what allows value to move. Meridian debits Bank Alfa's USD account and credits Cassia's USD account.
DR Bank Alfa USD account at Meridian — USD 85,000.00
CR Cassia USD account at Meridian — USD 85,000.00
07Message
Meridian forwards the customer paymentMeridian Bank (USD correspondent) → Cassia Bank (beneficiary bank) · MT103
Meridian sends the payment to Cassia under their authorized relationship, preserving the payment references and party information needed for validation and reconciliation.
08Posting
Cassia credits Northstar ComponentsCassia Bank (beneficiary bank) → Northstar Components
Cassia matches the incoming instruction and funds, completes its screening and account checks, and posts the supplier credit.
CR Northstar Components account at Cassia — USD 85,000.00
What this simplifies: One USD correspondent stands in for a governed routing table. RMA scope, SSI approval and account reachability are shown as one checkpoint but are owned by different controls in many banks.
EVIDENCE AT ARM'S REACH
MESSAGES, SAMPLES, AND GOVERNING SOURCES
These resources cover the message conversations explicitly authored in this flow. Scheme-neutral teaching files still require validation against the profile used in production.
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.
Usage guidelineSwift MTcurrent
Swift Standards MT release material
The annual MT standard and release information. Full field specifications may require an authenticated Swift account.
Owner
Swift
Checked
2026-07-18
Access
Login required · Swift login and the organisation's permissions may be required.
Field 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.
Owner
Payments Signal
Checked
2026-07-19
Integrity
crc32:47a46ccb
Access
Payments Signal download · Original, source-backed teaching asset; no login required.
Field correspondence, transformation treatment, and data-loss notes for Legacy negative-status convention compared with a structured FI-to-FI status report. This is a business-semantic comparison, not a claim that pacs.002 has a standalone MT equivalent.
Owner
Payments Signal
Checked
2026-07-19
Integrity
crc32:a90c5f46
Access
Payments Signal download · Original, source-backed teaching asset; no login required.
Field correspondence, transformation treatment, and data-loss notes for Legacy return-payment convention compared with the structured ISO 20022 payment return.
Owner
Payments Signal
Checked
2026-07-19
Integrity
crc32:a221a68d
Access
Payments Signal download · Original, source-backed teaching asset; no login required.
Positive and negative test cases across validation, rejection, return, recall, reversal, investigation, reconciliation, migration, instant payments, and screening.
Owner
Payments Signal
Checked
2026-07-19
Integrity
crc32:98c48cc7
Access
Payments Signal download · Original, source-backed teaching asset; no login required.
Describes Swift's messaging, connectivity, global payments innovation, platform, and compliance services offered to member institutions. · Checked 2026-07-13
Used for the public overview of product details documented behind swift.com.
Defines the MT message standards (including MT101, MT103, MT202/202 COV, and the MT9xx statement messages) exchanged over the Swift FIN network, maintained through annual standards releases. · Checked 2026-07-18
Full field-level specifications live in the Swift Knowledge Centre User Handbook behind a swift.com login. Coexistence for in-scope FI-to-FI payment instructions ended on 22 November 2025, but treatment differs by MT: some instructions are NAKed and selected messages can enter temporary, chargeable contingency conversion. Reporting, initiation, investigations and correspondence follow separate roadmaps.
Defines correspondent banking arrangements, including nostro/vostro account relationships, and analyses the decline in correspondent relationships and its drivers. · Checked 2026-07-12
Published in July 2016; its statistics cover 2011-2015 and are dated, but the definitions and arrangement types remain widely used.
Simplified educational illustration
Payments Signal editorial teaching models — Payments Signal
This site's own simplified teaching models. · Checked 2026-07-12
What this simplifies: One currency and one correspondent. Real routing tables can select among several correspondents, services and market infrastructures. Parties, accounts and amounts are fictional.
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.
COMMUNITY SIGNAL
Discuss this learning page
Share an operational observation or ask a concrete payments question. Your name and message are public; your email remains private.
NEXT QUESTION REVIEWMonday, 27 Jul, 8:00 amMonday answer runs use source-supported educational material. Some questions may need owner review.