MT103 — Single Customer Credit Transfer
The international customer credit transfer that carried the bulk of SWIFT cross-border payments for forty years. Now superseded by pacs.008 on the network, but still in domestic use depending on the market.
Purpose
MT103 is sent by the ordering bank to the beneficiary's bank (potentially through an intermediary bank) to settle a single amount in favour of an identified beneficiary. It is the reference message for cross-border customer credit transfers: international supplier invoices, expat payroll, family transfers. It mandatorily carries an identifiable ordering party, an identifiable beneficiary, a single amount, a value date and a charge-bearing option (OUR / SHA / BEN).
MT103 has several variants: MT103 "Core" (general), MT103 STP (Straight Through Processing — stricter identification rules for automatic routing), and MT103+ (SWIFT Remit extension for structured RemittanceInfo). The CBPR+ retirement of November 2025 covers every variant for cross-border traffic.
Five-block structure
Like any FIN message, MT103 is made of five blocks (see also the SWIFT MT hub page):
- Block 1 — Basic Header:
{1:F01...}, FIN application, service 01, sender BIC, session, sequence. - Block 2 — Application Header:
{2:I103...}, direction (Input), MT103, receiver BIC, priority (N=Normal, U=Urgent). - Block 3 — User Header: carries the
{121:UETR}mandatory since November 2018 on every SWIFTNet MT103 (Unique End-to-end Transaction Reference, UUID v4 format). - Block 4 — Text: the business body, tag-structured (
:nn[a]:). - Block 5 — Trailer: checksums and network controls.
Mandatory Block 4 tags
The SWIFT User Handbook mandates seven tags for a valid MT103:
| Tag | Name | Format | Usage |
|---|---|---|---|
:20: | Sender's Reference | 16x | Unique reference on the sender side, no // nor leading/trailing /. |
:23B: | Bank Operation Code | 4!c | CRED (credit), CRTS (cheque), SPAY (priority paid), SPRI (priority sent), SSTD (standard). |
:32A: | Value Date / Currency / Interbank Settled Amount | 6!n3!a15d | Date YYMMDD + ISO 4217 + amount (comma as decimal separator, max 15 digits). |
:50a: | Ordering Customer | option A/F/K | 50A = BIC; 50F = structured identifier and address; 50K = account number (IBAN) + name and address. |
:59a: | Beneficiary Customer | option "or" 59 / 59A / 59F | 59 = account + name/address; 59A = BIC; 59F = structured identifier and address. |
:71A: | Details of Charges | 3!a | OUR (charges to ordering party), SHA (shared), BEN (to beneficiary). This is the tag SEPA forces to SLEV. |
Tag :70: — Remittance Information — is "optional" in the standard but
almost always carried in practice for receiver-side reconciliation. The most common
conditional tags: :33B: (Instructed Amount — needed whenever there is FX
conversion), :36: (Exchange Rate), :52a: (Ordering
Institution), :53a: / :54a: / :55a: (Sender's /
Receiver's / Third Reimbursement Institution), :56a: (Intermediary
Institution), :57a: (Account With Institution), :72: (Sender
to Receiver Information).
Real-world example
A EUR 12,500 transfer from ACME SARL (Lyon, BNP Paribas account) to Hans Mueller GmbH (Frankfurt, Deutsche Bank account), with UETR, charges to the ordering party, to settle invoice 2026-187:
{1:F01BNPAFRPPAXXX0000000000}{2:I103DEUTDEFFXXXXN}{3:{108:REF20260514001}{121:1a2b3c4d-5e6f-7890-abcd-ef1234567890}}{4:
:20:REF20260514001
:23B:CRED
:32A:260514EUR12500,00
:33B:EUR12500,00
:50K:/FR7630006000011234567890189
ACME SARL
12 RUE DE LA SOIE
69001 LYON
:52A:BNPAFRPPXXX
:57A:DEUTDEFFXXX
:59:/DE89370400440532013000
HANS MUELLER GMBH
HAUPTSTRASSE 12
60313 FRANKFURT
:70:INVOICE 2026-187
:71A:OUR
-}{5:{CHK:ABC123456789}} {1:F01BNPAFRPPAXXX...}— sender BNP Paribas Paris, BICBNPAFRPP.{2:I103DEUTDEFFXXXXN}— receiver Deutsche Bank Frankfurt, BICDEUTDEFF, priority N.{3:{121:1a2b3c4d-...}}— UETR as UUID v4, mandatory.:20:REF20260514001— sender's reference (max 16 characters).:23B:CRED— credit transfer, no special service.:32A:260514EUR12500,00— value date 14 May 2026, EUR, 12,500.00.:33B:EUR12500,00— instructed amount (equal to the settled amount here, so no FX).:50K:— ordering customer in option K: IBAN + name + unstructured address.:52A:BNPAFRPPXXX— ordering institution (the bank that debits, same as the sender here).:57A:DEUTDEFFXXX— account with institution (the bank that credits the beneficiary's account).:59:/DE89...— beneficiary with IBAN, name and address.:70:INVOICE 2026-187— wording for accounting reconciliation.:71A:OUR— charges fully borne by the ordering party.
Common pitfalls
- BIC vs BICFI — a BIC in MT is 8 or 11 characters. The final
XXX(branch code) is explicit in MT (BNPAFRPPXXX). In ISO 20022 theBICFIelement strictly expects 8 or 11 characters but without an implicitXXX— beware on an MT → MX translation. - IBAN vs proprietary account — the
/prefix before an account in:50K:or:59:means an IBAN. With no prefix, it is a proprietary identifier (RIB, BBAN, domestic account number). A classic source of rejections during pacs.008 migration. - FX and the 32A / 33B pair — when the ordering party instructs in one currency and the final settlement is in another,
:32A:carries the settled amount and:33B:carries the instructed amount. Tag:36:gives the applied exchange rate. Forgetting:33B:on an FX MT103 triggers an MT199 reject from the receiving bank. - Charges & SEPA — for a SEPA-area MT103, tag
:71A:must carry SLEV (Service Level — shared charges per the rulebook). Forcing OUR or BEN violates the EPC SCT Rulebook and is rejected. - Missing or ill-formed UETR — since SWIFT's Universal Confirmation (November 2018), any MT103 without
{121:UUID}in Block 3 is rejected at send time. The UUID must be v4 (RFC 4122), exactly 36 characters including dashes, lowercase. - Character set X (restricted) — SWIFT MT does not accept the full Unicode set. Block 4 allowed characters are defined by character set x (basic Latin, no accents). An
éwill be transliterated by the SWIFT gateway or rejected in strict mode — which is why pacs.008 (native UTF-8) is attractive for international names.
MX equivalent — pacs.008
In ISO 20022, MT103 maps to pacs.008.001.10 (FI to FI Customer Credit Transfer, version 10, as used by CBPR+). Main correspondences:
| MT103 | pacs.008 | Note |
|---|---|---|
:20: | PmtId/InstrId | Sender's reference. |
Block 3 :121: | PmtId/UETR | UUID v4 mandatory in both formats. |
:23B: | Category + service level | CRED implies no special service; SLEV → SvcLvl/Cd=SEPA. |
:32A: date | IntrBkSttlmDt | ISO date YYYY-MM-DD. |
:32A: currency + amount | IntrBkSttlmAmt Ccy=... | Interbank settled amount. |
:33B: | InstdAmt | Instructed amount (before FX). |
:50a: | Dbtr + DbtrAcct | Structured name and account. |
:52a: | DbtrAgt | Ordering bank (BIC into BICFI). |
:57a: | CdtrAgt | Beneficiary's bank. |
:59a: | Cdtr + CdtrAcct | Structured name and account. |
:70: | RmtInf/Ustrd or Strd | Unstructured (Ustrd) or structured (Strd with ISO 11649 creditor reference) remittance. |
:71A: | ChrgBr | OUR → DEBT, BEN → CRED, SHA → SHAR, SLEV → SLEV. |
See the detail page pacs.008 for the XSD and a complete example.
Related messages
- MT199 — Free Format Message, used for returns, queries, simple status messages.
- MT900 / MT910 — Debit / Credit Confirmation sent by correspondent banks after posting.
- MT202 / MT202 COV — General FI Transfer, used for the interbank settlement of the customer payment (MT103 is the customer-side instruction, MT202 is the correspondent-side settlement).
- MTn92 / MTn95 / MTn96 — Cancellation, Query, Answer for post-settlement investigations.
- ISO 20022 equivalent: pacs.008, with status
pacs.002, returnpacs.004, cancellationcamt.056.