ANNOTATED SAMPLE

MT101 request for transfer

A fictional corporate request for transfer — the customer-side instruction that precedes the interbank MT103.

Contributor Shubham Mathure16 July 2026

Illustrative, non-production example. Values are fictional and the message is not validated for any specific network, scheme, or implementation guide.

 1{1:F01DEMODEFFAXXX0000000000}
 2{2:I101DEMODEFFXXXXN}
 3{3:{108:DEMO-ONLY}}
 4{4:
 5
 6
 7:50H:/DE02120300000000202051
 8DEMO TRADING LTD
 99 EXAMPLE QUAY
10FRANKFURT DE
11
12
13
14:57A:DEMOGB2LXXX
15
16
17
18
19:70:DEMO INVOICE 1001
20
21-}

EVERY ANNOTATED FIELD

:20: Sender's Reference (sequence A) — mandatory

The sender's own reference for the whole request — the number quoted in any later query about it.

One reference covers the full message, which may contain many transactions; individual transactions are identified by field 21 in each sequence B.

⚠ Reusing references defeats duplicate detection and muddies investigation trails.

:28D: Message Index / Total (sequence A) — mandatory

Says which message this is in a set, such as 1 of 3, when a large request is split across several MT101s.

All messages in a chained set share the sender's reference and must arrive as a complete set before execution.

⚠ Broken chaining — a missing index or inconsistent totals — leaves the executing bank with a partial batch it cannot safely process.

:30: Requested Execution Date (sequence A) — mandatory

The date the customer wants the executing bank to start processing all the transactions in the message.

It is a requested date: cut-off times, funding, and the executing bank's calendar decide the actual debit and value dates.

:50a: Ordering Customer — conditional

The account owner whose account will be debited.

The standard allows it once in sequence A (covering every transaction) or in each sequence B (transaction by transaction), but it must be present in exactly one of those places — hence conditional.

⚠ Supplying it in both sequences, or in neither, fails network validation.

:21: Transaction Reference (sequence B) — mandatory

A unique reference for each individual transaction inside the request.

This is the reference the executing bank will echo in status advice and that reconciliation teams match against the resulting debits.

:32B: Currency / Transaction Amount (sequence B) — mandatory

How much to pay, and in which currency, for this transaction.

Amounts use a comma as the decimal separator, and the currency must be one the debit account and service agreement actually support.

⚠ A currency outside the account agreement is a common rejection reason at the executing bank.

:57a: Account With Institution (sequence B) — conditional

The bank that holds the beneficiary's account.

Conditional per the message's usage rules; a BIC (option A) gives the executing bank the best chance of straight-through routing. Where routing is ambiguous, execution slows or fails.

⚠ Free-text bank names instead of BICs push transactions into manual repair.

:59a: Beneficiary (sequence B) — mandatory

Who should receive this transaction, with their account.

Account, name, and address quality here flows straight into the onward payment the executing bank creates — errors reappear downstream as returns.

:71A: Details of Charges (sequence B) — mandatory

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

The choice constrains the charging of the onward payment; some corridors restrict BEN by regulation or scheme rule.

FULL MT101 REFERENCE →