MT103 customer credit transfer

EVERY ANNOTATED FIELD

:20: Sender's Reference — mandatory

The sender's own reference for this payment — the number everyone quotes when questions come up later.

It anchors queries, cancellations, and reconciliation between adjacent banks; end-to-end tracking across the whole chain relies on the UETR in the header instead.

⚠ Reused references break duplicate detection and confuse investigations.

:23B: Bank Operation Code — mandatory

Tells the receiving bank what kind of transfer this is; CRED marks an ordinary credit transfer.

CRED is the everyday value. Other codes are rare, tied to specific service arrangements, and some legacy values have been withdrawn over successive standards releases.

:32A: Value Date / Currency / Interbank Settled Amount — mandatory

When the money moves between the banks, in which currency, and how much settles between them.

This is the interbank settled amount — after any deducted charges — which is not necessarily what the customer instructed. The original instructed amount lives in 33B.

⚠ Amounts use a comma as the decimal separator with no thousands separators; malformed amounts are rejected at network level.

:33B: Currency / Instructed Amount — conditional

What the ordering customer originally asked to send, before charges or currency conversion.

Network-validated rules make 33B mandatory in defined situations — for example when a currency conversion happened on the sender's side, and in certain intra-European payments. Once present, it must travel unchanged along the chain.

⚠ If 33B, the exchange rate in 36, and the charge fields do not reconcile to 32A, receiving banks raise repairs or investigations.

:36: Exchange Rate — conditional

The rate applied when the instructed currency differs from the settlement currency.

Required when 33B is present with a different currency than 32A, and must be absent otherwise — one of the arithmetic consistency rules validated by the network.

:50a: Ordering Customer — mandatory

Who the payment is from — the debtor, with account and address depending on the option used.

Option F carries structured name, address, and identity elements that screening systems and regulators strongly prefer; the free-text option K is a major source of screening noise.

⚠ Vague, truncated, or abbreviated originator data drives sanctions alerts and requests for information from downstream banks.

:52a: Ordering Institution — optional

The bank acting for the ordering customer when that bank is not the sender of this message.

Appears mainly in relay and multi-bank structures; identify it with a BIC (option A) wherever possible.

:57a: Account With Institution — conditional

The bank that holds the beneficiary's account, when it is not the receiver of the message.

Presence depends on the routing and is tied to other routing fields by conditional rules. A BIC in option A is the safest choice for straight-through processing.

⚠ Name-and-address options force manual routing decisions at intermediaries.

:59a: Beneficiary Customer — mandatory

Who ultimately gets the money, with their account.

In many corridors — including payments between EU/EEA countries — the account must be a valid IBAN. Missing or invalid beneficiary account data is a leading cause of returns.

⚠ A name that does not match the account holder at the beneficiary bank can trigger repair, delay, or return depending on local practice.

:70: Remittance Information — optional

Free text telling the beneficiary what the payment is for — invoice numbers and similar.

Limited to four lines of 35 characters, far less than ISO 20022 allows — which is why translating rich remittance data into MT format truncates.

⚠ Screening engines scan this free text: place names, vessel names, or goods descriptions connected to sanctioned activity generate hits here.

:71A: Details of Charges — mandatory

Who pays the banks' fees: OUR (sender pays all), SHA (shared), or BEN (beneficiary pays).

The option constrains whether sender's charges (71F) or receiver's charges (71G) may appear, under network-validated rules; several corridors restrict BEN by regulation or scheme rule.

:72: Sender to Receiver Information — optional

Bank-to-bank instructions that fit nowhere else, often using coded keywords.

Structured codes such as /INS/ or /ACC/ are machine-readable by some receivers; free text almost always lands in a manual repair queue, so use it sparingly.

⚠ Instructions hidden in 72 that contradict the structured fields cause processing disputes between banks.