MT103 Field-by-Field: The Operator Reference

MT103 was retired from SWIFT's cross-border FINplus network on 22 November 2025. Operators still search for MT103 field meanings constantly in 2026 — because the field structure governs every pre-cutover archive, most bank-issued documentation, most training material, and the vocabulary correspondent banking teams still use out of habit. If you're reading a payment record from before the migration, working at an institution still on contingency MT processing, or just trying to understand what a specific field tag on a wire confirmation actually means, the MT field numbers are still the reference point — even though the live cross-border message today is ISO 20022 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.

MT103 is the baseline — flexible field formats, usable by any SWIFT participant with no special registration. MT103+, which SWIFT's own documentation formally labels MT103 STP, restricts the same fields to structured, network-validated formats: BIC-based party identification wherever a structured option exists, no free-text fallback in fields where STP compliance requires one. The "+" naming predates SWIFT's later "STP" documentation and both are still used interchangeably by banks — a wire confirmation or SSI document that says "MT103+" and one that says "MT103 STP" are describing the same variant. MT103 REMIT solves a different problem: field 70's 140 characters aren't enough for high-volume invoice or bulk-billing remittance detail, so REMIT drops it for field 77T, a much larger structured envelope — but using it requires joining a dedicated SWIFT message user group, which most institutions haven't done.

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).

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,00

This 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 (single-currency payment, no conversion), no field 72 (no special routing instructions needed). A payment with FX conversion, a longer correspondent chain, or a regulatory reporting requirement would carry several more of the 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. This is one of the reasons SWIFT pushed structured formats starting around the November 2020 Standards Release, even though industry adoption of the structured options stayed low.

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 against each other where they overlap. The canonical text lives in SWIFT's own Standards MT documentation and MyStandards portal; direct fetches of SWIFT-hosted PDFs during this article's research were repeatedly blocked or timed out, consistent with the access pattern already documented in PaymentBrief's other MT103/CBPR+ references.
• The structured-data adoption claim (low uptake of 50F/59F relative to 50K/59 despite SWIFT's 2020-era push) is sourced at market-practice tier, not confirmed from a directly-read primary text — see the sources list for the specific hedge.
• 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.