Field structure, how to read an MT message

An MT message is divided into blocks, and the text block contains tagged fields. Each field starts with a colon, a two digit number, an optional letter, and a colon, for example colon 20 colon for the transaction reference, or colon 32A colon for the value date, currency, and amount. The tag tells the reader what the field contains, and the format tells the reader how to interpret it. Field 20 is a 16 character reference assigned by the sender, and it must be unique. Field 32A contains the value date in YYMMDD format, the three letter currency code, and the amount with a comma as the decimal separator. Field 50K contains the ordering customer name and address, and field 59 contains the beneficiary name and address. Other important fields in an MT103 include field 70 for remittance information, which is free text of up to 140 characters that tells the beneficiary what the payment is for, and field 71A for details of charges, which can be OUR, where the sender bears all charges, BEN, where the beneficiary bears all charges, or SHA, where charges are shared. Field 52A identifies the ordering institution, field 56A identifies an intermediary, field 57A identifies the account with institution, and field 72 contains sender to receiver information. Each field has a specific format, a maximum length, and a set of validation rules, and a message that violates those rules will be rejected by the SWIFT network or by the receiving bank. Reading an MT103 is a skill that improves with practice. Start with the header to identify the sender and receiver BICs and the message type. Then read field 20 for the reference, field 32A for the amount and value date, field 50K for the debtor, field 59 for the creditor, field 70 for the reason, and field 71A for the charges. That sequence gives you the core of the payment in under a minute. More detailed fields, such as the intermediary and the account with institution, tell you the routing. A business analyst who can read an MT103 can investigate a payment delay, can explain a deduction to a customer, and can write test cases that reflect real payment data. Start with the blocks that wrap every MT message. Block 1 is the basic header, and it identifies the sender. It carries the application identifier, the service identifier, the sender BIC, a session number, and a sequence number. Block 2 is the application header, and it says where the message is going and how urgent it is. For an incoming message it carries the letter I, the message type, the destination BIC, a priority of U for urgent or N for normal, and delivery monitoring information. Block 3 is the user header, and it is optional. It can carry a transaction reference, a UETR for end to end tracking, a service identifier, and a validation flag. Block 4 is the text block, and it holds the tagged fields that carry the payment itself. Block 5 is the trailer, and it holds the checksum that proves the message was not altered in transit, plus optional trailers for delivery information. A raw MT103 therefore reads as a set of blocks in braces, each block starting with a number and a colon. Field formats have their own short notation, and it is worth learning to read it. The letter x means any character from the SWIFT character set, n means a digit, a means a letter, and d means a decimal number with a comma. A number before the letter gives the maximum length, and an exclamation mark means the length is exact. A field can also have several lines, written as 4x35x, which means up to four lines of up to 35 characters each. Subfields inside a field are separated by line breaks or slashes, and the order of the subfields is fixed by the standard. Validation happens in layers, and each layer can stop the message. The SWIFT network checks the format, the mandatory fields, and the field lengths, and rejects anything that breaks the rules with a negative acknowledgement. The receiving bank then checks the business content, the BICs, the currency code, the value date, and the amount. A value date that is not a business day, a currency code that does not exist, or an amount with the wrong decimal format will all cause a reject or a repair. Common errors are a missing mandatory field, a field that is too long, and a reference that has already been used. The analyst who can read a reject message and point to the field that caused it saves the operations team a lot of time. Worked example with real numbers: field 72, sender to receiver information, carries different content on an MT103 and on an MT202 COV, and the difference matters. On an MT103 for EUR 60,000 from Paris to Singapore, field 72 carries a code for the charges, such as /REC/ for a payment that must be received in full, or a free-text instruction to the receiver, such as a request to advise the beneficiary by phone. A bank that copies the field 72 from the MT103 to the MT202 COV will send the wrong instruction, and the cover will be processed as if it were a customer payment, or the settlement method will be wrong, and the payment will be held. Source: SWIFT MT103 and MT202 COV format specifications; Paiementor reader discussion on field 72 differences. Failure and recovery: field 72 fails when it carries a code the receiving bank does not recognise, or when it carries free text that contradicts the structured fields, so the receiving bank holds the payment for manual review, and the payment is delayed by a day. The recovery is to correct field 72, resend the message, and to check the code against the SWIFT code list before sending, because a code that is not in the list will always be held. A bank that lets operators type free text into field 72 will create holds, and the BA must require the field 72 content to be selected from a defined list, not typed freely, because free text is where the errors live. For a business analyst, product owner or subject matter expert, the field 72 requirement must name what goes in field 72 on an MT103 and what goes in field 72 on an MT202 COV, with a side-by-side comparison, and must state why they differ: the MT103 field 72 is an instruction to the receiver about the customer payment, while the MT202 COV field 72 is a settlement instruction about the cover. In ISO 20022 the equivalent information is carried in structured fields, such as the settlement information and the charge bearer, and the requirement must map field 72 to those fields, so the instruction survives migration. A field 72 that is copied without understanding is a payment that will be held.