MT103 — Single Customer Credit Transfer
Instructs a transfer of funds where the ordering party, the beneficiary, or both are non-bank customers. It is the classic cross-border customer credit transfer: one message per payment, carrying the parties, amounts, charging arrangement, and remittance detail from the ordering customer's bank toward the beneficiary's bank.
DIRECTION: Sent by or on behalf of the ordering customer's bank to the beneficiary's bank — directly, hop by hop through correspondents in the serial method, or straight to the beneficiary's bank with a separate MT202 COV carrying the funds in the cover method.
WHO IS INVOLVED
- Ordering customer (debtor)Initiates and funds the payment; appears in field 50a.
- Sending bank (ordering institution)Debits the customer, applies its controls, formats and sends the MT103.
- Correspondent / intermediaryIn a serial chain, receives the message, screens it, and passes it to the next bank.
- Beneficiary's bank (account-with institution)Runs its own screening and validation, then credits the beneficiary.
- Beneficiary customer (creditor)Receives the funds; appears in field 59a.
KEY FIELDS
Curated subset of the fields practitioners meet first — the official SWIFT Standards MT documentation is the complete specification.
| FIELD | NAME | PRESENCE | WHAT IT MEANS |
|---|---|---|---|
:20: | Sender's Reference | MANDATORYSWIFT Standards MT | 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 | MANDATORYSWIFT Standards MT | 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 | MANDATORYSWIFT Standards MT | 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 | CONDITIONALSWIFT Standards MT | 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 | CONDITIONALSWIFT Standards MT | 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 | MANDATORYSWIFT Standards MT | 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 | OPTIONALSWIFT Standards MT | 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 | CONDITIONALSWIFT Standards MT | 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 | MANDATORYSWIFT Standards MT | 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 | OPTIONALSWIFT Standards MT | 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 | MANDATORYSWIFT Standards MT | 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 | OPTIONALSWIFT Standards MT | 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. |
FIELD BY FIELD — FULL STRUCTURE
The whole MT103 laid out as a parent-child tree: every field in its nesting, with a sample value and what it means. Expand a branch to drill in. Values are fictional (SYNTHETIC / TRAINING ONLY); this is a curated practitioner view, not the full schema.
Block 1F01DEMOUS33AXXX0000000000MandatoryBasic header — identifies the sender and the session (application id, service id, the sender's logical-terminal address built on its BIC, session and sequence numbers).Block 2I103DEMOGB2LXXXXNMandatoryApplication header — the message type, the counterparty address, whether it is input or output, and the priority.Block 3—User header — optional service data; most importantly field 121, the UETR.108DEMO-ONLYMessage User Reference (MUR) — a sender's reference in the user header the sender can reconcile against.
Block 4—MandatoryText — the business content, as numbered :tag: fields. The only block whose shape changes by message type.:20:DEMO20260712MandatoryThe sender's own reference for this payment — the number everyone quotes when questions come up later.- Use case
- 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.
- Example
:20:DEMO20260712- Watch out
- Reused references break duplicate detection and confuse investigations.
:23B:CREDMandatoryTells the receiving bank what kind of transfer this is; CRED marks an ordinary credit transfer.- Use case
- 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:260712EUR1250,00MandatoryWhen the money moves between the banks, in which currency, and how much settles between them.- Use case
- 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.
- Example
:32A:260712EUR1250,00- Watch out
- Amounts use a comma as the decimal separator with no thousands separators; malformed amounts are rejected at network level.
:33B:EUR1250,00ConditionalWhat the ordering customer originally asked to send, before charges or currency conversion.- Use case
- 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.
- Watch out
- If 33B, the exchange rate in 36, and the charge fields do not reconcile to 32A, receiving banks raise repairs or investigations.
:50K:/DEMO-ORIGINATOR ⏎ JANE EXAMPLE ⏎ 1 SAMPLE STREET ⏎ DUBLIN IEMandatoryWho the payment is from — the debtor, with account and address depending on the option used.- Use case
- 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.
- Watch out
- Vague, truncated, or abbreviated originator data drives sanctions alerts and requests for information from downstream banks.
:52A:DEMODEFFXXXOptionalThe bank acting for the ordering customer when that bank is not the sender of this message.- Use case
- Appears mainly in relay and multi-bank structures; identify it with a BIC (option A) wherever possible.
:57A:DEMOGB2LXXXConditionalThe bank that holds the beneficiary's account, when it is not the receiver of the message.- Use case
- 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.
- Watch out
- Name-and-address options force manual routing decisions at intermediaries.
:59:/DEMO-BENEFICIARY ⏎ JOHN EXAMPLE ⏎ 2 TEST ROAD ⏎ LONDON GBMandatoryWho ultimately gets the money, with their account.- Use case
- 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.
- Watch out
- A name that does not match the account holder at the beneficiary bank can trigger repair, delay, or return depending on local practice.
:70:NON-PRODUCTION EXAMPLEOptionalFree text telling the beneficiary what the payment is for — invoice numbers and similar.- Use case
- Limited to four lines of 35 characters, far less than ISO 20022 allows — which is why translating rich remittance data into MT format truncates.
- Watch out
- Screening engines scan this free text: place names, vessel names, or goods descriptions connected to sanctioned activity generate hits here.
:71A:SHAMandatoryWho pays the banks' fees: OUR (sender pays all), SHA (shared), or BEN (beneficiary pays).- Use case
- 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.
- Example
:71A:SHA
:72:/INS/NON-PRODUCTION EXAMPLEOptionalBank-to-bank instructions that fit nowhere else, often using coded keywords.- Use case
- 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.
- Watch out
- Instructions hidden in 72 that contradict the structured fields cause processing disputes between banks.
Sources for the field structure4
- Official requirement
ISO 20022 Catalogue of messages ↗ — ISO 20022 Registration Authority · pain/pacs/camt message-definition elements
Each message set is described by a Message Definition Report; earlier versions remain available in the ISO 20022 messages archive.
- Official requirement
Cross-Border Payments and Reporting Plus (CBPR+) usage guidelines ↗ — Swift (CBPR+ working group) · cross-border agent chain and structured-data usage
Full guidelines require MyStandards access; content here relies on public summaries. MT-to-CBPR+ translation rules are published on Swift's translation portal.
- Official requirement
Swift Standards MT (annual standards releases) ↗ — Swift · FIN block structure
Full field-level specifications live in the Swift Knowledge Centre User Handbook behind a swift.com login; content here relies on public summaries. Swift ended MT-to-ISO 20022 coexistence for in-scope cross-border payment instructions (for example MT103 and MT202) in November 2025; MT statement messages are being phased out on a separate timeline.
- Simplified educational illustration
Payments Signal editorial teaching models — Payments Signal
What this simplifies: One-line plain-language descriptions of the commonly-populated elements — a practitioner view, not the authoritative ISO 20022 / MT schema, which defines many more optional elements.
Used wherever diagrams, scenarios, figures, or example values are didactic constructions rather than sourced facts; every such use carries a simplifications disclosure. All people, companies, banks, and list entries in examples are fictional.
COMMON ERRORS
- Charging option in 71A inconsistent with the charge fields present (71F/71G).Consequence: Network validation failure, or downstream repair and disputes about who bears the fees.Avoid it: Enforce the 71A/71F/71G consistency rules in the payment engine rather than relying on manual entry.
- Missing or invalid beneficiary IBAN in 59a where the corridor requires one.Consequence: Repair at an intermediary, delayed credit, or a return with charges deducted.Avoid it: Validate IBAN structure and country requirements at capture time, before the payment leaves the sending bank.
- Amounts that do not reconcile: 33B adjusted by 36 and the charge fields does not equal 32A.Consequence: The beneficiary receives an unexpected amount and an investigation case opens between the banks.Avoid it: Compute the interbank settled amount from the instructed amount, rate, and charges in one place, and populate all related fields from that single calculation.
- Unstructured, abbreviated party data in 50a or 59a.Consequence: Sanctions-screening false positives at every bank in the chain, each adding delay.Avoid it: Use the structured field options with full legal names and addresses, and keep customer reference data clean at source.
USAGE CONTEXTS
- Cross-border correspondent banking (historic core)For decades the MT103 was the workhorse of cross-border customer payments over the Swift FIN network — sent serially bank to bank, or paired with an MT202 COV in the cover method.
- ISO 20022 migrationThe MT/ISO 20022 coexistence period for cross-border payment instructions ended in November 2025, and pacs.008 replaced the MT103 for interbank exchange in Swift's cross-border (CBPR+) space. Practitioners still meet MT103s in archives, translation tooling, and domestic or bilateral contexts that kept MT formats on their own timelines — which is why the format remains worth learning.
- gpi tracking and the UETRSince November 2018 every MT103 must carry a unique end-to-end transaction reference (UETR) in header block 3, field 121. The Swift gpi Tracker uses it to follow the payment across the chain, and receiving banks expect it regardless of whether the sender is a gpi member.
- Sanctions screeningThe party and free-text fields (50a, 59a, 70, 72) are exactly what transaction-screening engines examine. Data quality in these fields directly drives alert volumes and false positives.
SEE IT IN A PLAYABLE FLOW
Sources for this reference2
- Official requirement
Swift Standards MT (annual standards releases) ↗ — Swift · Category 1 — MT 103
Full field-level specifications live in the Swift Knowledge Centre User Handbook behind a swift.com login; content here relies on public summaries. Swift ended MT-to-ISO 20022 coexistence for in-scope cross-border payment instructions (for example MT103 and MT202) in November 2025; MT statement messages are being phased out on a separate timeline.
- Simplified educational illustration
Payments Signal editorial teaching models — Payments Signal
What this simplifies: Field list curated for learning; national and bilateral usage rules omitted.
Used wherever diagrams, scenarios, figures, or example values are didactic constructions rather than sourced facts; every such use carries a simplifications disclosure. All people, companies, banks, and list entries in examples are fictional.