ediverse Explore the platform

Spotlight PEPPOL BIS Billing 3.0 The EU e-invoicing mandate is here — France Sept 2026, Belgium Jan 2026, Germany 2025.

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:

TagNameFormatUsage
:20:Sender's Reference16xUnique reference on the sender side, no // nor leading/trailing /.
:23B:Bank Operation Code4!cCRED (credit), CRTS (cheque), SPAY (priority paid), SPRI (priority sent), SSTD (standard).
:32A:Value Date / Currency / Interbank Settled Amount6!n3!a15dDate YYMMDD + ISO 4217 + amount (comma as decimal separator, max 15 digits).
:50a:Ordering Customeroption A/F/K50A = BIC; 50F = structured identifier and address; 50K = account number (IBAN) + name and address.
:59a:Beneficiary Customeroption "or" 59 / 59A / 59F59 = account + name/address; 59A = BIC; 59F = structured identifier and address.
:71A:Details of Charges3!aOUR (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:

text mt103-anonymized.txt
{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, BIC BNPAFRPP.
  • {2:I103DEUTDEFFXXXXN} — receiver Deutsche Bank Frankfurt, BIC DEUTDEFF, 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 the BICFI element strictly expects 8 or 11 characters but without an implicit XXX — 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:

MT103pacs.008Note
:20:PmtId/InstrIdSender's reference.
Block 3 :121:PmtId/UETRUUID v4 mandatory in both formats.
:23B:Category + service levelCRED implies no special service; SLEV → SvcLvl/Cd=SEPA.
:32A: dateIntrBkSttlmDtISO date YYYY-MM-DD.
:32A: currency + amountIntrBkSttlmAmt Ccy=...Interbank settled amount.
:33B:InstdAmtInstructed amount (before FX).
:50a:Dbtr + DbtrAcctStructured name and account.
:52a:DbtrAgtOrdering bank (BIC into BICFI).
:57a:CdtrAgtBeneficiary's bank.
:59a:Cdtr + CdtrAcctStructured name and account.
:70:RmtInf/Ustrd or StrdUnstructured (Ustrd) or structured (Strd with ISO 11649 creditor reference) remittance.
:71A:ChrgBrOUR → DEBT, BEN → CRED, SHA → SHAR, SLEV → SLEV.

See the detail page pacs.008 for the XSD and a complete example.

  • 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, return pacs.004, cancellation camt.056.