Last reviewed: · Curated by Ohmyfin Organisation editorial.
MT103 is the most important SWIFT message type for individuals and businesses. It instructs a single customer credit transfer between two banks across borders. Draft a valid MT103 now → · Verify an MT103 UETR free →
An MT103 message is structured into five blocks. Block 1 (basic header): identifies the sending SWIFT institution and the message type. Block 2 (application header): the receiving institution's BIC, the priority (N=normal, U=urgent, S=system), and the input/output reference. Block 3 (user header): optional fields including field 113 (banking priority code), field 108 (MUR — message user reference), and crucially field 121 (the UETR — the 36-character GPI tracking ID mandatory since November 2018). Block 4 (text block): the actual payment data. Block 5 (trailer): authentication checksum (MAC) and possible PDE/DLM markers.
Key fields in Block 4: field 20 (Sender's Reference / TRN — up to 16 characters, your bank's internal payment ID); field 23B (Bank Operation Code — almost always CRED for a credit transfer); field 32A (Value Date + Currency + Amount — e.g. 260101USD25000,00 for $25,000 USD on 1 January 2026); field 50A/F/K (Ordering Customer — the sender's account and name, three variants depending on data format); field 52A/D (Ordering Institution — the sender's bank BIC); field 53A/B/D (Sender's Correspondent — the sender bank's USD correspondent, for example); field 54A/B/D (Receiver's Correspondent); field 56A/C/D (Intermediary Bank — optional, for an extra hop in the chain); field 57A/B/C/D (Account With Institution — the beneficiary's bank BIC); field 59/59A/59F (Beneficiary Customer — account number or IBAN, and name); field 70 (Remittance Information — up to 4 lines × 35 characters); field 71A (Details of Charges — OUR, SHA or BEN); field 72 (Sender to Receiver Information — optional notes between banks).
UETR deep dive: field 121 in block 3 contains the UETR, a UUID v4 string in the format xxxxxxxx-xxxx-4xxx-xxxx-xxxxxxxxxxxx. The originating bank generates this value once, and it is passed unchanged through every correspondent bank in the chain until funds are credited. Every SWIFT GPI member bank (covering ~95% of cross-border payment value) logs a status update against this UETR at each processing step, giving live tracking visibility. The UETR is the primary lookup key on Ohmyfin.
Common MT103 rejection reasons: (1) Missing or invalid BIC in field 57A — the payment cannot be routed to the beneficiary bank. Fix: confirm the correct 8 or 11 character BIC. (2) Incomplete beneficiary data in field 59 — fails AML/sanctions screening at a correspondent bank because the name or address is too generic. Fix: include full legal name and complete address. (3) Field 70 remittance information triggers a compliance alert — e.g. contains words like "oil", "arms", or a sanctioned country name. Fix: use neutral invoice references. (4) Sending bank SWIFT BIC not registered or suspended — the message is rejected at entry. (5) Incorrect field 71A charges code — the beneficiary may receive less than expected if SHA or BEN was specified unintentionally.
MT103 STP (Straight-Through Processing): to qualify for STP, all fields must be correctly formatted, the beneficiary bank BIC must be present in field 57A, and all mandatory fields must be complete. STP payments are processed automatically at every correspondent bank with no human intervention, which means faster settlement and lower per-hop fees. Non-STP payments enter a manual queue at each correspondent, which can add hours or days.
Fraud warning — MT103 PDFs: because MT103 confirmation PDFs circulate widely in trade finance and advance-fee fraud schemes, it is critically important to verify any received MT103 document before releasing goods, services or funds. The UETR in field 121 is the only reliable verification mechanism — if the UETR returns no result or a "not found" status on Ohmyfin, the document is almost certainly forged. See /help for the full MT103 fraud guide.
ISO 20022 migration: MT103 is being replaced by pacs.008 as part of the SWIFT CBPR+ migration. The coexistence period ran from March 2023 to November 2025. After November 2025, all new cross-border SWIFT customer credit transfers must originate as pacs.008. During the coexistence period, SWIFT's translation service automatically converted MT103 to pacs.008 and vice versa. Ohmyfin tracks both formats via UETR with no difference to the user experience.
Paste the UETR from field 121 into Ohmyfin at ohmyfin.org. A genuine MT103 will return a real-time SWIFT GPI status (ACSP, ACSC, RJCT, etc.). If Ohmyfin cannot find the UETR, the document is almost certainly forged. Do not release goods, services or further funds until your own bank confirms an incoming credit.
They are closely related but technically different. An "international wire transfer" or "cross-border wire" is the financial transaction. The MT103 is the SWIFT messaging format that instructs that transfer between banks. The same transaction is also described by a pacs.008 message in ISO 20022 format.
Mandatory fields in Block 4 are: 20 (sender's reference), 23B (bank operation code), 32A (value date / currency / amount), 50A, 50F, or 50K (ordering customer), 59 or 59A or 59F (beneficiary), 71A (details of charges). Field 121 (UETR) in Block 3 is mandatory for all GPI-enabled messages since November 2018.
Your bank can send an MT192 cancellation request, which asks every bank in the chain to stop the payment. Under SWIFT GPI there is also a Stop-and-Recall feature. However, once funds have been credited to the beneficiary account, the beneficiary bank cannot unilaterally reverse the credit — the beneficiary must consent. Cancellations take 1–10 business days and are not guaranteed to succeed.
MT103 STP (Straight-Through Processing) is a variant of MT103 that must contain all data required for automatic processing at every correspondent bank. STP eligibility requires a full BIC in field 57A, correctly formatted beneficiary address in field 59, and all mandatory fields present. STP payments process faster (automated queues) and are cheaper (lower per-hop fees).
Common rejection reasons: missing or wrong BIC in field 57A (routing failure); incomplete beneficiary name/address in field 59 (AML screening hold); suspicious remittance text in field 70 (compliance alert); incorrect charges code in field 71A (beneficiary receives less). Ohmyfin will show a RJCT (rejected) status with a rejection reason code — see /status for full code explanations.
No card needed. Free for ordinary users — completely free for individuals — no daily limit, no card required. Track any international wire across 11,000+ banks.
Track a payment now — completely free Or try the tracker now →