Payments Academy

Message Explorer

Explore 27 MT and ISO 20022 messages field by field. Pick a message to see its business purpose, participants, structure, every field with whether it is mandatory, optional or conditional, scheme-specific rules, a valid and an invalid example, validation errors, related messages, and the processing and accounting implications. Where a message has several versions, pick a version to see which one applies. Base ISO 20022 messages are shown separately from scheme-specific implementations: the base message defines the structure, the scheme rules add or restrict elements for a rail.

Showing 27 messages. Pick one to see every field, the valid and invalid examples, and the processing and accounting implications.

MT103: Single Customer Credit Transfer

14 fields · Single version · Related messages listed below

MT103 carries a single customer credit transfer instruction from one bank to another through SWIFT. It tells the receiving bank to pay a named beneficiary a stated amount in a stated currency. Banks use it for cross-border customer payments, including trade, salary, invoice and personal transfers. The message holds ordering customer, beneficiary, value date, charges and remittance details needed for straight through processing.

Base message vs scheme implementation. This is a SWIFT MT (FIN) message. There is no single global scheme rulebook for MT messages: each bank and market practice defines its own format limits, cut-off times and usage rules on top of the SWIFT standard.

Sending and receiving participants. The sending participant is the bank holding the ordering customer account (the debtor agent). The receiving participant is the bank that will pay the beneficiary, either the beneficiary bank itself or the next bank in the correspondent chain.

Message structure. MT103 is a SWIFT MT (FIN) message made of blocks: header blocks 1 and 2, text block 4 with the tagged fields :20: to :77B:, and trailer block 5. Field :59a: names the beneficiary, :32A: carries value date, currency and amount, and :71A: states who pays the charges.

FieldNameM/O/CMeaning
:20:Transaction ReferenceMA unique reference assigned by the sending bank to identify this payment through its whole life. It must not repeat for the same sender within the same business day in most banks. Operations teams use it to trace the payment, match confirmations and answer customer queries about status and value date.
:23B:Bank Operation CodeMA four character code that tells the receiving bank how to handle the transfer. CRED means a normal credit transfer, SPAY means a SWIFT payment, SSTD means a standard payment and CRTS means a transfer related to a cheque. The code guides processing priority and the way charges and settlement are applied.
:32A:Value Date, Currency Code, AmountMThe value date on which funds become available to the beneficiary, the three letter ISO currency code and the amount to be paid. For USD 25,000 on 5 November 2026 the field reads 261105USD25000,00. Value date, currency and amount must match the debit and the settlement instruction exactly.
:33B:Currency Code, AmountOThe currency and amount in which the ordering customer instructed the payment, when that differs from the settlement currency in field 32A. It preserves the original instruction amount for reconciliation and customer reporting. It is used when a bank converts currency before sending the payment onward.
:50a:Ordering CustomerMThe customer who ordered the payment, identified by account number and name and address. Option K gives account, name and address in free text. Option F gives structured party details. Accurate ordering customer data is essential for sanctions screening, anti money laundering checks and beneficiary bank verification.
:52a:Ordering InstitutionOThe financial institution that ordered the transfer when it is not the sender of the message. It is normally the bank holding the ordering customer account in a chain of banks. The field helps the receiver identify the true originator bank and route any return or query to the correct institution.
:53a:Sender's CorrespondentOThe account held by the sender with the receiver, or the correspondent bank through which settlement will occur. It tells the receiving bank where to debit the funds for this payment. Correct correspondent details prevent settlement delays and avoid the payment being held for account identification.
:54a:Receiver's CorrespondentOThe account held by the receiver with another bank, used when the receiver does not hold the sender account directly. It identifies the next bank in the settlement chain. The field is common in multi hop correspondent chains where funds pass through an intermediary before reaching the beneficiary bank.
:57a:Account With InstitutionOThe bank where the beneficiary holds an account, when it is not the receiver of the MT103. It directs the receiving bank to forward the payment to the correct account with institution. Option A gives the BIC, option D gives name and address when no BIC is available.
:59a:Beneficiary CustomerMThe final recipient of the funds, identified by account number and name and address. Option A gives the account and BIC, option F gives structured name and address, and no letter option gives free text. The beneficiary bank credits this account on the value date after passing its own screening checks.
:70:Remittance InformationOFree text information for the beneficiary explaining what the payment is for, such as an invoice number, contract reference or salary month. It is limited to four lines of 35 characters. Clear remittance information helps the beneficiary reconcile the receipt against open invoices and reduces queries to the sending bank.
:71A:Details of ChargesMA three letter code stating who pays the transfer charges. OUR means the ordering customer pays all charges, BEN means the beneficiary pays all charges, and SHA means charges are shared between sender and receiver. The code drives fee deduction at each bank in the chain and must match the customer instruction.
:72:Sender to Receiver InformationOCoded or free text instructions from the sender to the receiver, such as cover payment indicators, regulatory reporting codes or special handling notes. It can carry the phrase /INS/ for intermediary details or /ACC/ for account instructions. Operations teams read it before releasing the payment for further processing.
:77B:Regulatory ReportingORegulatory information required by the authorities of the sending or receiving country, such as balance of payments codes or central bank reporting data. It is mandatory in some corridors and must follow local format rules. Missing regulatory data can cause the payment to be delayed or rejected by the receiving bank.

Scheme-specific rules. MT103 is a SWIFT MT (FIN) message, not a base ISO 20022 message: there is no single global scheme rulebook, and each bank and market practice sets its own format limits and cut-off times on top of the SWIFT standard. Under SWIFT rules the ordering customer and beneficiary must be identified clearly enough for sanctions screening, and field :71A: must state OUR, BEN or SHA so every bank in the chain knows who bears the charges. Under CBPR+ new cross-border customer payments use pacs.008 instead of MT103, so MT103 now survives mainly on corridors not yet migrated.

Valid example. Meridian Bank London sends an MT103, reference MER1035521, for USD 25,000 value 5 November 2024 to Harbour Bank Singapore to pay Bright Logistics for invoice INV-1187. This is a pre-migration example, from before coexistence ended on 22 November 2025. Field :71A: is SHA, the beneficiary account is given in :59a:, and the payment settles on the value date.

Invalid example. An MT103 arrives with field :32A: showing a value date in the past and no beneficiary account in field :59a:. The receiving bank cannot identify where to credit the funds and rejects the message for repair (error: missing mandatory beneficiary account).

Validation errors.

  • Missing mandatory field :59a: beneficiary customer: the receiving bank cannot identify the account to credit and rejects the message.
  • Invalid value date in field :32A:: a past or non-business-day value date fails validation and the payment is repaired or rejected.
  • Missing or invalid charge code in field :71A:: without OUR, BEN or SHA the banks in the chain cannot agree who pays the charges.

Related messages. MT202, pacs.008, MT900, pacs.002

Processing implications. The receiving bank validates the beneficiary, screens the ordering customer and beneficiary against sanctions lists, and checks the value date and charges code before crediting. A payment that fails screening is held for compliance review, and the sender is told the reason so it can correct and resend.

Accounting implications. The sending bank debits the ordering customer account and credits its nostro or settlement account on the value date. The receiving bank credits the beneficiary account and debits its nostro account with the sender. Charges are posted separately to the party named in field :71A:.