SWIFT Messages
SWIFT messages mainly include MT messages and MX messages. A SWIFT message must conform to SWIFT standards and structure requirements.
MT Messages
All SWIFT MT messages start with the literal MT followed by a 3-digit number.
The first digit represents the message category, the second digit represents a group of related parts in a transaction life cycle, and the third digit represents the message type.
SWIFT MT messages mainly include the following types:
| • | System messages |
These messages are sent by a user to the SWIFT system (delivery notifications, retrievals) or by the SWIFT system to the user (retrieved messages, non-delivery warnings).
System messages are represented by MT0nn, and used for system-level information, such as delivery notifications and non-delivery warnings.
| • | User-to-user messages |
These messages are sent from one user to another. You can use them to conduct financial transactions. These messages are represented by MT1nn through MT9nn.
| • | Service messages |
These messages are also known as control messages, and are related either to system commands, for example, LOGIN, SELECT, or QUIT; or to message acknowledgments. For example, when you send a message to the SWIFT network, SWIFT accepts the message and sends you an ACK if the syntax of the message is correct. If not, it returns a NAK.
All SWIFT MT messages are ASCII text messages and, in general, have the following structure:
| • | Basic header block |
This block is represented by {1:} and includes details, such as the application ID, service ID, address of the logical terminal, session number, sequence number, and so on.
The application ID in this block helps you identify whether a message is a GPA message (system message) or an MT message (user-to-user message). For example, M indicates that the message is an MT message, and A indicates that the message is a GPA message.
| • | Application header block |
This block is represented by {2:}. Application headers include two types: input and output. The structure of the block varies depending on the type of the application header. This header block typically includes details, such as the message type, message priority, delivery monitoring, and so on.
| • | User header block |
This block is represented by {3:} and includes details, such as the banking priority code, and so on. This is an optional block.
| • | Text block |
This block is represented by {4:} and contains the actual MTnnn message. This block includes details, such as the ordering customer, beneficiary customer, amount, currency code, date, and so on.
This block consists of field tags of the format :nna:. nn is a number, and a is an optional letter which might be present on selected tags. The symbol CrLf is a control character and represents Carriage Return/Line Feed. The symbol CrLf is a mandatory delimiter in this block.
| • | Trailer block |
This block is represented by {5:}. A message always ends in a trailer block, which is used for control purposes. A trailer block includes details, such as message authentication code and checksum calculated for all message types.
The following figure shows the structure of a typical SWIFT MT message:
MX Messages
SWIFT MX messages mainly include the following types:
| • | InterAct messages |
These messages are MX messages using the InterAct messaging service. The structure of the InterAct messages mainly includes the transport, header, and document.
| • | SAA messages |
These messages are MX messages delivered to SWIFT Alliance Access (SAA). The structure of the SAA messages mainly includes the transport, header, and document.
The following figure shows the structure of InterAct MX message blocks with Application Header:
The following figure shows the structure of InterAct MX message blocks with Business Application Header:
For more details about MX messages, see www.swift.com > Support > Documentation (User Handbook) > Standards MX > General Information.
CBPR+ Message
Cross-Border Payments and Reporting Plus (CBPR+) specifications define how the plug-in uses ISO 20022 for cross-border payments and cash reporting on the SWIFT network.
Basic Message Flow
The basic SWIFT message flow involves syntax validation and confirmation of receipt and acceptance.
When you send a message to the SWIFT network, SWIFT validates the syntax of the message. If the message is correct, SWIFT accepts the message, sends you an ACK, and attempts to deliver the message to the receiver. If the message does not comply with the standards, SWIFT rejects it and returns a NAK. The NAK contains an error code, which helps the sender identify the type of error and its location. The sender can then correct the message before resending it to SWIFT.
SWIFT delivers the message as soon as the receiver is logging in to the SWIFT network. The interface at the receiver's end automatically confirms the receipt and acceptance of the message by sending a UAK. When a UAK is received by SWIFT, the message is considered to be delivered. If the message received is corrupted, the interface of the receiver sends a UNK to SWIFT, and SWIFT attempts to redeliver the message.