MT103 Field-by-Field: The Operator Reference
Field-by-field MT103 reference: mandatory/optional status, format specs, and failure modes for fields 20 through 77T, plus MT103 vs MT103+ vs REMIT.
The FI-to-FI cross-border MT/ISO coexistence period ended in November 2025, but qualifying MT103s can still enter limited contingency conversion. This is a field-by-field reference for legacy records and current MT-sender exceptions.
An MT103 is built from tagged fields. Fields 20, 23B, 32A, 50a, 59a, and 71A are mandatory; fields 33B, 36, 53a–57a, 71F, and 71G are conditional, with rules that depend on the transaction and corridor. Fields 13C, 26T, 70, 72, and 77B are optional. The FI-to-FI cross-border MT/ISO coexistence period ended on 22 November 2025. Qualifying MT103s sent on FIN can still pass through Swift's limited contingency conversion for delivery as ISO 20022 pacs.008 on FINplus. The field structure therefore remains relevant to archives and contingency senders. MT103 STP is a restricted variant built for straight-through processing; MT103 REMIT uses field 77T for extended remittance. MT101 is a separate request-for-transfer message.
The FI-to-FI cross-border MT/ISO coexistence period ended on 22 November 2025. Swift no longer delivers MT payment instructions as MT on FIN for those flows, but qualifying MT103s sent on FIN can still undergo limited contingency conversion for ISO 20022 delivery on FINplus. Operators continue to read MT103 tags in archives, documentation and contingency records, alongside native pacs.008.
This is a field-level reference, not a mapping table. For how each MT103 field translates to its pacs.008 element — the format PaymentBrief's other MT103 reference covers — see the MT103 to pacs.008 field mapping reference. This article assumes you're starting from the MT103 side and want to know: what does this field actually mean, is it required, what format does it take, and what goes wrong when it's populated incorrectly.
MT103, MT103+ (STP), and MT103 REMIT
"MT103" gets used loosely to mean three related but distinct message variants. All three carry the same core payment — same message type category — but differ in field flexibility and remittance capacity.
| Variant | Field flexibility | Registration required | Remittance capacity |
|---|---|---|---|
| MT103 | General use — every field except 77T, with free-format options throughout | None | Field 70: 4 lines × 35 characters |
| MT103+ (MT103 STP) | Network-validated, structured-field-only subset of the same fields, built for straight-through processing | None (general use) | Same field 70 constraint |
| MT103 REMIT (historical FI-to-FI cross-border use) | Same core fields, but 70 is replaced entirely | Extended Remittance Information message user group; Block 3 field 119 carried code REMIT | Field 77T: up to 9,000 characters; Swift now NAKs this variant for the scoped CBPR+ contingency flow |
MT103 is the baseline. MT103+, which Swift documents as MT103 STP, restricts field content for straight-through processing. Swift's current contingency list includes MT103 and MT103 STP. MT103 REMIT historically addressed field 70's 140-character limit by using field 77T, a larger envelope available under a dedicated message user group. Swift's current FAQ says FI-to-FI cross-border MT103 REMIT is NAKed after the 2025 coexistence end, so this variant is included here for interpreting older records, not as a live contingency option.
MT101 vs MT103: Different Messages, Common Confusion
MT101 and MT103 are frequently confused because both appear in the same payment lifecycle, but they are structurally different messages with different senders and different purposes.
MT101 (Request for Transfer) is an instruction, typically sent by a corporate customer or a bank acting on that customer's behalf, requesting that funds move out of an account. It is repetitive — a single MT101 can bundle multiple transaction sequences, instructing several payments (to different beneficiaries, in different amounts) in one message. This is the standard mechanism for centralized corporate treasury payment runs and multi-bank account management.
MT103 (Single Customer Credit Transfer) is the message that actually executes one specific interbank credit transfer — sender, receiver, amount, and routing for a single payment.
The relationship: a corporate's MT101 payment instruction is what generates the individual MT103 message(s) that carry each payment through the correspondent chain to its beneficiary. One MT101 batch of ten payments can produce ten separate MT103s. This distinction matters operationally — asking a receiving bank to trace "the MT103" using an MT101 batch reference will not work, because the receiving bank never sees the MT101 at all; it only sees the MT103 generated from it.
Field-by-Field Reference
The table below covers the fields operators encounter most often when reading an MT103. Status: M = mandatory on every MT103, O = optional, C = conditional (required only under specific circumstances — for example, when currency conversion occurred, or when a specific correspondent is involved).
| Field | Name | Status | Format | What It Carries / Operator Note |
|---|---|---|---|---|
| 20 | Sender's Reference | M | 16x | Unique reference assigned by the sending bank. Cannot start or end with a slash, and cannot contain two consecutive slashes — a common rejection cause for hand-keyed instructions. Changes at every bank hop; not an end-to-end reference. |
| 13C | Time Indication | O | /8c/4!n1!x4!n | Carries a code (e.g. CLSTIME, RNCTIME, SNDTIME), a time, and a UTC offset. Used for time-critical settlement — CLS-linked FX settlement is the most common case. |
| 23B | Bank Operation Code | M | 4!c | Almost always CRED (standard credit transfer, no SWIFT service level) in cross-border traffic. SPAY, SSTD, and SPRI signal SWIFTPay, Standard, or Priority service levels respectively — rare outside specific bilateral arrangements. |
| 23E | Instruction Code | C | 4!c[/30x] | Repeatable processing instructions: SDVA (same-day value required), INTC (intra-company payment), REPA (related e-payments reference), CORT (settling a trade), HOLD (beneficiary will call to collect). Some combinations are mutually exclusive — SDVA cannot pair with HOLD or CHQB. |
| 26T | Transaction Type Code | O | 3!c | Regulatory/statistical purpose category — salaries, pensions, dividends, and similar classifications. Must not be used to advise of a separately-completed transaction (e.g. a cheque collection). |
| 32A | Value Date/Currency/Interbank Settled Amount | M | 6!n3!a15d | The core settlement instruction: date, currency, amount actually settled between banks. Can differ from field 33B when FX conversion occurred along the chain. |
| 33B | Currency/Instructed Amount | C | 3!a15d | The instructed amount and currency when supplied. Swift's MT103 rules require 33B when the sender performed currency conversion, but it may also appear without conversion. Reconcile the invoice against the instructed amount and the actual beneficiary credit, rather than assuming 32A is the invoice amount. |
| 36 | Exchange Rate | C | 12d | Present only in cross-currency payments — mandatory alongside 33B whenever 32A and 33B carry different currencies. Compare against the mid-market rate at the time to quantify FX spread. |
| 50a | Ordering Customer | M | Options A / F / K | The ordering customer. 50A identifies the customer with an account or identifier and a BIC; 50F uses numbered lines for structured customer details; 50K carries free-format name and address. Check the applicable option and bank requirements rather than assuming every payer is a financial institution. |
| 51A | Sending Institution | O | 4!a2!a2!c[3!c] | Used only when the bank transmitting the message differs from the ordering customer's own bank — a technical/network field, rarely populated on a standard corridor. |
| 52a | Ordering Institution | C | Options A / D | The payer's own bank. Present whenever the sending institution transmitting the message isn't the payer's bank. Option A (BIC) is required for STP. |
| 53a | Sender's Correspondent | C | Options A / B / D | The correspondent used to settle between sender and receiver — a settlement-side field, not part of the visible party chain. See the cover payment reference for how this field's counterpart drives cover-payment routing. |
| 54a | Receiver's Correspondent | C | Options A / B / D | The bank through which the receiver will be reimbursed, when different from a direct relationship. Populated on longer correspondent chains. |
| 55a | Third Reimbursement Institution | C | Options A / B / D | Identifies a further reimbursement bank when funds reach the receiver's branch through an institution other than the one in field 53a. Option D (name/address rather than BIC) breaks straight-through processing and delays the payment. |
| 56a | Intermediary Institution | C | Options A / C / D | The correspondent between the ordering and beneficiary institutions. Present on any payment with more than two hops. This is the field most often confused with field 53a — they carry different roles. |
| 57a | Account With Institution | C | Options A / B / C / D | The beneficiary's own bank — required whenever it differs from the Receiver of the message itself. On most corridors this is effectively always present. |
| 59a | Beneficiary Customer | M | Options none / A / F | The final recipient. Plain 59: account plus free-format name/address (4×35 characters). 59A: BIC-identified beneficiary, used when the beneficiary is itself a financial institution. 59F: structured name/address by numbered qualifier — preferred for AML screening, since unstructured name/address strings are a documented driver of false-positive sanctions hits. |
| 70 | Remittance Information | O | 4*35x | Four lines of 35 characters — roughly 140 characters total — for invoice numbers, purchase order references, or a payment purpose narrative. This hard limit is the single biggest driver of truncated remittance data on MT-era payments; anything longer gets cut, not wrapped or rejected. |
| 71A | Details of Charges | M | 3!a | OUR, SHA, or BEN — who bears correspondent fees. Field-level mechanics only; see OUR, SHA, and BEN: SWIFT charge options for the full economic and reconciliation impact of each choice. |
| 71F | Sender's Charges | C | 3!a15d | Populated when charges were deducted along the chain under SHA or BEN — repeatable, one occurrence per deducting bank. This is where a "short arrival" amount is actually itemised, when the sending bank chooses to populate it. |
| 71G | Receiver's Charges | C | 3!a15d | Present under OUR: the prepaid charge amount already included in the 32A settlement amount. The arithmetic relationship is fixed — 32A equals 33B plus 71G under OUR — so a mismatch here is a hard validation failure, not a rounding quirk. |
| 72 | Sender to Receiver Information | O | 6*35x | Free-text bank-to-bank instructions, often using /CODEWORD/ conventions (e.g. /REJT/, /RETN/) for routing or return processing. Not intended for customer-facing content, but frequently misused as a catch-all for anything that didn't fit elsewhere — a common source of downstream parsing failures. |
| 77B | Regulatory Reporting | O | 3*35x | Statutory reporting codes required by the sender's or receiver's country. Line format is /8a/2!a[/33x] — a code, an ISO country code, then free text. ORDERRES and BENEFRES identify the country of residence of the ordering or beneficiary customer respectively. Corridors with capital controls or FX reporting requirements (several Latin American and Asian jurisdictions) commonly reject a payment missing this field, not because SWIFT requires it universally, but because the destination country does. |
| 77T | Envelope Contents | M (REMIT only) | 9000z | Exists only on MT103 REMIT, replacing field 70 entirely. Up to 9,000 characters, capable of carrying structured remittance data or non-SWIFT payload formats such as EDIFACT or ANSI X12. Not present on standard MT103 or MT103 STP. |
Where the UETR Lives
None of the fields above carry the UETR — it isn't a Block 4 text field at all. The UETR sits in field 121 of Block 3 (the User Header), generated once at origination and passed through every correspondent unchanged. It's the identifier that makes gpi tracking possible, and it's what to quote — not field 20 — when chasing a stalled payment. This article stays at the Block 4 field level; for the full tracking mechanics, status codes, and stall-triage runbook, see Tracing a SWIFT payment: UETR, gpi, and where it gets stuck.
Illustrative Example
A simplified MT103 for a $10,000 USD payment, OUR charges, one intermediary:
:20:REF20260815001
:23B:CRED
:32A:260817USD10000,00
:50K:/1234567890
ACME TRADING PTE LTD
1 RAFFLES PLACE, SINGAPORE
:52A:DBSSSGSG
:56A:CHASUS33
:57A:DEUTDEFF
:59:/DE89370400440532013000
GLOBAL SUPPLIES GMBH
HAUPTSTRASSE 1, BERLIN
:70:/INV/2026-4471
:71A:OUR
:71G:USD25,00This is illustrative, not a reproduction of any real institution's output — every reference, account, and BIC is fictional. Note what's absent: no UETR (it lives in Block 3, not shown here), no field 33B or 36 (no currency conversion is shown, although 33B could still be present), no field 72 (no special routing instructions shown). A payment with FX conversion, a longer correspondent chain, or a regulatory reporting requirement may carry more fields from the table above.
"GPI Semi-Automatic" and "KYC GPI": Not SWIFT Terms
Two search phrases worth addressing directly because they surface a genuine risk, not a field-format question: "MT103 GPI semi-automatic" and "MT103 KYC GPI."
Neither term appears in SWIFT's own gpi documentation, and neither describes any real step in how a gpi payment moves or is released. SWIFT gpi has no "semi-automatic" transmission mode, and it has no separate paid "KYC clearance" gate that must be satisfied — by the beneficiary, by a self-described bank official, or by any third party — before a payment completes. This specific phrasing is documented advance-fee fraud vocabulary: it typically appears in scripts claiming a large sum is "trapped" in the SWIFT/gpi system and that a payment (a "clearance fee," a "KYC fee," an "activation charge") is required to release it. The SWIFT KYC Registry is a real service, but it is a due-diligence directory correspondent banks use to exchange standardised institutional documentation with each other — it has no transaction-level fee, no role in releasing an individual payment, and no interaction with an individual payment's beneficiary at all.
If you encounter this vocabulary — in an email, a message from someone claiming to hold funds on your behalf, or a document purporting to show a stuck MT103 requiring a release payment — treat it as a fraud indicator. A legitimate stalled SWIFT payment is investigated through your own bank, using the UETR and the gpi Tracker, at no cost to you; see the tracing reference for the actual process.
Failure Modes Operators Actually Hit
Truncation in field 70. Four lines of 35 characters is not enough for a long invoice reference plus a purpose narrative. Content gets cut, not wrapped — a common cause of failed auto-reconciliation on the receiving end.
Sanctions-screening false positives from unstructured 50K/59. Free-format name and address strings are harder to screen cleanly than structured 50F/59F equivalents, and increase the odds of a phonetic or partial-match hold at a correspondent. PMPG urged a move to structured options in its 2017 whitepaper, observing at that time that the industry had not yet seen a significant shift to 50F/59F. Later field references continued to document both option families; they do not establish a measured adoption rate through 2025.
Missing 77B on a corridor that requires it. Field 77B is optional under the MT103 standard itself, but several jurisdictions with capital controls or FX reporting rules reject payments that omit the country-residency codes their own regulator requires. A rejected payment for "missing regulatory reporting" is a destination-country requirement showing up as a field-population failure, not a SWIFT rule.
Rejection on 71F/71G arithmetic. The relationship between 32A, 33B, and the charges fields is fixed by the charge instruction in 71A. Populating 71G under a SHA instruction, or leaving the settlement amount inconsistent with the instructed amount plus charges, is a hard validation failure at the receiving bank — not a soft warning.
Non-STP routing from Option D fields. Wherever a field offers both a BIC option (A) and a name/address option (D or K), choosing the name/address option on a field like 55a breaks straight-through processing and adds manual handling time, even when the payment is otherwise correctly formed.
Treating field 20 as a persistent reference. It changes at every bank in the chain. Using it to ask a downstream correspondent about "the payment" — instead of the UETR — is one of the most common reasons a bank enquiry comes back empty.
Related References
- MT103 to pacs.008 field mapping reference — the ISO 20022 equivalence for every field covered here, plus the post-migration investigation flow (pacs.002, camt.056, camt.110/111).
- Tracing a SWIFT payment: UETR, gpi, and where it gets stuck — the investigation runbook once you have a UETR in hand.
- Why SWIFT payments arrive short — the reconciliation and cost mechanics behind field 71A.
- MT202 COV and pacs.009 COV: the cover-payment operator reference — how the settlement-side fields (53a and its ISO equivalent) route funds separately from the customer instruction.
- SWIFT payment processing: MT103, ISO 20022, and gpi explained — the pillar reference for correspondent-chain mechanics and the migration context this article assumes.
Scope Note
- Field structure and format specifications (the reference table above) are drawn from practitioner reproductions of SWIFT's Category 1 Standards MT Message Reference Guide — Iota Finance, Paiementor, XMLdation, Euroclear — cross-checked where they overlap. Confirm consequential field use against the applicable SWIFT standard and bank implementation.
- Structured-data adoption is a dated observation: PMPG reported no significant industry shift to 50F/59F as of its 2017 whitepaper. The later field references document both option families but do not measure their subsequent use.
- MT103 retirement date (22 November 2025) is the same date already independently sourced and corroborated in PaymentBrief's MT103-to-pacs.008 mapping reference and MT202 COV reference.
- The "GPI semi-automatic" / "KYC GPI" section describes documented scam vocabulary patterns, not a SWIFT-published warning list — the underlying fact (SWIFT gpi has no such mechanism) follows directly from the gpi documentation already cited across PaymentBrief's SWIFT reference set.
For term definitions — SWIFT, UETR, correspondent banking, KYC — see the Payments Glossary.
Sources & methodology (12)
MT103 field-by-field structure and mandatory/optional/conditional status (fields 20, 13C, 23B, 23E, 26T, 32A, 33B, 36, 50a, 51A, 52a, 53a–57a, 59a, 70, 71A, 71F, 71G, 72, 77B) with format specifications
Reproduces the field table from SWIFT's Category 1 Standards MT Message Reference Guide. Same source tier already used and corroborated in PaymentBrief's MT202 COV reference for MT202 COV field structure.
Checked:
The historical MT103 REMIT format used field 77T (Envelope Contents) instead of field 70, format 9000z, with an Extended Remittance Information message user group and Block 3 field 119 code REMIT
Checked:
MT103 STP (informally MT103+) is a compatible, network-validated restricted subset of core MT103 fields and format options built for straight-through processing with minimal manual intervention; general-use message requiring no MUG registration
Checked:
MT101 is a Request for Transfer message — sent by financial institutions on behalf of non-financial customers, or by customers/authorized representatives — instructing the movement of funds from an account; it is repetitive (can carry multiple transaction sequences in one message), distinct from MT103 which executes a single credit transfer
Checked:
Field 71F/71G math logic: interbank settlement amount (32A) equals instructed amount (33B) plus receiver's prepaid charges (71G) under OUR; charge-bearer field 71A determines whether 71F (sender's deducted charges) or 71G (receiver's prepaid charges) is populated
Checked:
Field 23E (Instruction Code) values SDVA, INTC, REPA, CORT, HOLD, CHQB, PHOB, TELB, PHON, TELE, PHOI, TELI, with defined ordering and mutually exclusive combination rules (e.g. SDVA cannot combine with HOLD or CHQB)
Checked:
Field 23B (Bank Operation Code) values: CRED (credit transfer, no SWIFT service level), SPAY (SWIFTPay service level), SSTD (Standard service level), SPRI (Priority service level)
Checked:
Field 77B (Regulatory Reporting) format /8a/2!a[/33x] carries statutory/regulatory reporting codes required by the country of Sender or Receiver, including ORDERRES and BENEFRES codes identifying the country of residence of the ordering or beneficiary customer
Checked:
Field 26T (Transaction Type Code) identifies the nature/purpose/reason for the individual transaction for regulatory and statistical categorization (e.g. salaries, pensions, dividends); must not be used to advise of a separately-completed transaction
Checked:
Field 55a (Third Reimbursement Institution) identifies the bank sending cover funds to reimburse the Receiver when funds are made available through an institution other than the one in field 53a; Option D usage causes non-STP processing
Checked:
PMPG's September 2017 whitepaper reported that the industry had not yet seen a significant shift to structured 50F/59F and described a planned November 2020 removal of free-format 50a/59a; later MT103 field references cited above continue to document both option families
The PMPG observation is dated 2017, and its 2020 discussion describes a plan, not a verified implementation outcome. Later field references show option availability but do not quantify industry adoption through 2025.
Checked:
The FI-to-FI cross-border coexistence period ended on 22 November 2025; qualifying MT103s sent on FIN remain subject to limited contingency conversion for ISO delivery on FINplus, chargeable from 1 January 2026
Swift distinguishes MT-sender contingency conversion from ISO-to-MT in-flow translation.
Checked:
Source types explained in our Methodology.
By Shaun Toh · Director, Digital Payments · Razer