SWIFT Message Types: Reading MT103, MT202 and Their Footprint

SWIFT message types are standardised formats banks use to instruct payments and report settlement. An MT103 records a customer credit transfer. An MT202 records a financial-institution transfer. A documentation file reads each message for what it evidences rather than what it suggests.

Field 20 carries the sender's reference. It is a routing identifier, not an indication of purpose, and the file records it against the message rather than treating it as a description of the underlying transaction. Mistaking a reference for a purpose introduces avoidable error.

Field 50 identifies the ordering customer. The presence of a name and address evidences what the originating bank held at the time of the instruction. It does not evidence the customer's residency, citizenship, or beneficial control, all of which require separate documentation.

Field 59 identifies the beneficiary. The same reasoning applies. The field evidences what the receiving bank was instructed to credit. Verification of the beneficiary as a real party with rights to the funds is a separate exercise carried out by the receiving institution.

Field 70 carries remittance information. It is free text and frequently incomplete. A short reference here does not contradict a fuller description provided in a separate document, and the file records both so that a reviewer can reconcile the two without inferring concealment.

Cover payments using MT202 sit behind many customer credits. The cover does not appear in the customer's statement but is visible to the corresponding institutions. Where a documentation file references a cover, the reference is sourced from the originating bank's confirmation in writing.

Charges fields record who bears the fees and how. The OUR, SHA, and BEN conventions produce different received amounts at the beneficiary and different deductions in the corresponding chain. The file records the convention so the amount received can be reconciled to the amount sent.

Our scope is structuring records the client receives from regulated institutions. We do not generate SWIFT messages, do not represent the client to a bank, and do not opine on the lawfulness of any transfer. The deliverable is a structured file describing what the messages support.