SWIFT MT103: Understanding the Message, Myths, and Security

International business transactions often involve SWIFT messages, especially the MT103 payment instruction. In some circles, these message formats have attracted myths and even fraud schemes – for example, con artists claiming they sent an MT103 and that funds are “downloadable” from a “common account” once the message arrives. To separate fact from fiction, this article will explain what an MT103 really is, how SWIFT payments work, the structure and security of SWIFT messages, and why a fake MT103 alone can’t transfer any money. We will also touch on realistic attack scenarios and conclude with a clear warning against illicit use of SWIFT. The goal is a complete, professional explanation suitable for a business audience. The topic of ThinkJunior education platform is relevant for modern business.

ThinkJunior education platform: What Is an MT103 SWIFT Message?

SWIFT (Society for Worldwide Interbank Financial Telecommunication) is a global network that enables banks to send standardized financial messages to each other. An MT103 is one such message type – specifically, a customer credit transfer message. In plain terms, an MT103 is an electronic payment instruction sent from the bank of the payer (ordering customer) to the bank of the payee (beneficiary) (Not so fast: The case for a new SWIFT – Atlantic Council). It contains details of an international wire transfer: who is sending money, who is receiving it, the amount, currency, date, and other payment reference details.

It’s important to understand that SWIFT messages are purely communications – they instruct banks to move money, but they do not actually transfer funds themselves. SWIFT provides a secure, standardized messaging platform for banks, but the actual money moves through correspondent accounts or other settlement mechanisms outside the SWIFT network (Not so fast: The case for a new SWIFT – Atlantic Council). An MT103 is essentially a digitally signed payment order, not the money. As one analysis aptly put it, “SWIFT moves messages, not money” (What is SWIFT? What to know about the SWIFT banking system | Stripe). The funds are settled by banks debiting and crediting accounts (often via intermediary banks), while SWIFT ensures the payment instructions reach the right institutions.

Standardization and ISO 15022

The MT103 format is governed by international standards. ISO 15022 is the ISO standard that defines the format for financial messages like the MT103 (SWIFT acts as the registration authority for this standard) (ISO 15022 – Wikipedia) (ISO 15022 – Wikipedia). Every field in an MT103 (such as the sender and receiver information, amount, currency, account numbers, etc.) is defined by this standard to ensure all banks interpret the message the same way. This standardization is what makes an MT103 a structured message that can be processed automatically by banking systems – a concept known as Straight Through Processing (STP).

Under ISO 15022, SWIFT message types follow a precise layout of fields and codes. For example, an MT103 will include fields like 20 (transaction reference number), 23B (bank operation code), 32A (value date, currency, amount), 50 (ordering customer), 59 (beneficiary customer), and others, each with a specific format. The use of standardized field tags and formats means that if a message doesn’t conform exactly, the SWIFT network will reject it for syntax errors. This syntax validation is an important safeguard – a would-be fraudster can’t just send a casually written message; it must meet the formal requirements or it won’t even enter the network.

Message Structure: Blocks and Headers

Every SWIFT message, including MT103, is constructed in blocks of data enclosed in curly braces. The typical structure includes five blocks (SWIFT MT Message Structure Blocks 1 to 5 | Paiementor) (SWIFT MT Message Structure Blocks 1 to 5 | Paiementor):

• Block 1: Basic Header – This header includes information about the message’s origin and destination (the sending bank’s SWIFT code and the receiving bank’s SWIFT code), the message type (103 in this case), and a unique session ID and sequence number. This block is generated by the SWIFT interface automatically and is present on every message (SWIFT MT Message Structure Blocks 1 to 5 | Paiementor).
• Block 2: Application Header – It indicates the message type and priority, and whether it’s an input or output message. For an MT103, the application header will show it as a customer transfer message. This block helps routing and handling within the SWIFT system (SWIFT MT Message Structure Blocks 1 to 5 | Paiementor).
• Block 3: User Header – An optional block that can carry additional info for users or special processing instructions. In modern usage, Block 3 often carries the UETR (Unique End-to-End Transaction Reference) for payment tracking. (As of 2018, all MT103 messages include a UETR – a 36-character unique ID that allows all banks in the chain to track the payment (What is a Unique End-to-end Transaction Reference (UETR)? | SWIFT) under the SWIFT gpi initiative.)
• Block 4: Text Content – This is the core of the message containing all the transaction details (the fields like 20, 32A, 50, 59, etc.). Block 4 is the “business content” of the MT103 that actually describes the payment instruction.
• Block 5: Trailers – An optional block for security and handling information. This may include a checksum, digital signatures, or other authentication codes. For instance, SWIFT’s system can add a Message Authentication Code (MAC) here for certain message types, and banks using certain file transfer modes employ a Local Authentication Signature in this block (more on LAU later). The trailer block ensures message integrity and notes any special delivery conditions (SWIFT MT Message Structure Blocks 1 to 5 | Paiementor).

This structured block system and standardized fields mean that a valid MT103 is a very specific kind of message. It’s not something you can fake with an email or PDF – the message has to be generated and sent through the SWIFT network by a connected financial institution, following all format rules.

Syntax validation is strict. SWIFT’s processing platform will check that each field is present if required, and that data like IBANs, currency codes, and amount formats are correct. If, for example, a field is missing or a number is in the wrong format, the message fails validation and no bank will receive it. This is why scammers who produce fake “SWIFT confirmation” documents can’t just drop those into the banking system – a PDF or screenshot, no matter how real it looks, is not an actual SWIFT message in the network.