MT103 Viewer SWIFT
Paste or drop an MT103 and see it field by field — blocks 1 to 5, ordering customer, beneficiary, charges and UETR. Entirely in your browser.
What is an MT103 and is it still used in 2026?
An MT103 is the SWIFT Single Customer Credit Transfer: the text message a bank sends to move money from one customer to another, and the most widely used payment order in the world. It is a chain of braced blocks — {1:} basic header, {2:} application header, {3:} user header, {4:} the message itself, {5:} trailer — with the payment carried in block 4 as tagged fields (:20: reference, :32A: value date, currency and amount, :50a: ordering customer, :59a: beneficiary, :71A: charges). Since the MT/ISO 20022 coexistence on CBPR+ ended on 22 November 2025, the MT103 is retired from cross-border interbank traffic on that rail, where pacs.008 replaces it — but it is still generated and consumed every day domestically, bank-to-corporate and host-to-host, which is exactly the traffic this free offline viewer reads.
About the MT103 viewer
The MT103 is a flat text message, not XML, and that is why it is so hard to read by eye: a line such as ":32A:261120USD125000,00" packs a value date, a currency and an amount into a single unbroken string, and ":50K:" and ":50A:" mean two entirely different things — a name and address in one case, a BIC in the other. This viewer takes the file apart for you: it splits the five SWIFT blocks, reads the basic header (the sender's logical terminal and BIC), the application header (input or output, message type, priority), the user header (the service type identifier and the UETR of tag 121), and then lists every field of block 4 in the order it appears, each with a plain-English label.
On top of the decoding it runs the checks that can honestly be run offline. It verifies that the six mandatory fields are present (:20:, :23B:, :32A:, :50a:, :59a:, :71A:), that :32A: has the shape of a value date followed by a three-letter currency and an amount, that :71A: carries one of the only three charge codes that exist (OUR, SHA, BEN), that a BIC given under option A is well formed, that the UETR in tag 121 is a genuine version-4 UUID, and — because it is pure arithmetic and a failure is therefore certain — that a beneficiary account that looks like an IBAN passes the mod-97 check. The exchange-rate rule stated in the ECB documentation is applied too: if :33B: is in a different currency from :32A:, then :36: must be present.
What it does not do, it says out loud. The SWIFT Network Validated Rules (C1 to C18) — how :71A: interacts with :71F: and :71G:, when :33B: becomes mandatory inside the EEA, what :23B:=SPRI allows in :56a: and :57a: — are published in the SWIFT User Handbook, which is not freely available; they are not implemented, and this tool never claims network conformance it cannot verify. TARGET2's own restrictions are deliberately not applied either: they would reject perfectly valid messages sent over other rails. Nothing is uploaded — the file is read in your browser and never leaves it.
What to know about MT103 in 2026
- The MT/ISO 20022 coexistence on CBPR+ ended on 22 November 2025: cross-border interbank credit transfers now travel as pacs.008, not MT103.
- The MT103 has not disappeared. It is still generated in domestic schemes, in bank-to-corporate reporting and in host-to-host and treasury file exchanges — and those files still have to be read.
- Every MT103 field has a direct counterpart in pacs.008: :20: becomes the instruction identification, :32A: the interbank settlement date, currency and amount, :71A: the charge bearer, and tag 121 becomes the UETR — the one element the two formats already share.
- The migration loses nothing structurally, but it gains a great deal: pacs.008 carries structured parties and structured remittance information where the MT103 has four free-text lines in :70:.
- An MT103 contains account numbers, names and addresses. Decoding it locally in the browser avoids sending a payment order to a third-party service.
MT103 vs pacs.008: field by field
| MT103 field | What it carries | pacs.008 (ISO 20022) equivalent |
|---|---|---|
| :20: | The sender's own reference for the transfer | InstrId / PmtId |
| :23B: | The bank operation code (CRED, SPAY, SPRI, SSTD, CRTS) | No direct equivalent — expressed through the service level and local instrument |
| :32A: | Value date, currency and interbank settled amount | IntrBkSttlmDt + IntrBkSttlmAmt |
| :33B: | The currency and amount instructed by the ordering customer | InstdAmt |
| :36: | The exchange rate, when the two currencies differ | XchgRate |
| :50a: | The ordering customer (name and address, or a BIC) | Dbtr + DbtrAcct |
| :52a: | The ordering customer's bank | DbtrAgt |
| :57a: | The beneficiary's bank | CdtrAgt |
| :59a: | The beneficiary customer and their account | Cdtr + CdtrAcct |
| :70: | The reason for payment, as up to four free-text lines | RmtInf — which can be structured |
| :71A: | Who pays the charges: OUR, SHA or BEN | ChrgBr: DEBT, SHAR or CRED |
| {3:{121:}} | The UETR, the end-to-end transaction reference | UETR — identical, and carried across both formats |
The mapping above is the practical bridge most teams need when a bank switches a feed from MT103 to pacs.008. Field semantics are sourced from the European Central Bank's TARGET2 User Detailed Functional Specifications, Book 1, v15.0 (26 March 2021), §9.1.2 — the only freely available public specification of the MT103 layout.
Frequently asked questions
What is an MT103?
An MT103 is the SWIFT Single Customer Credit Transfer: the message a bank uses to instruct a payment from one customer to another. It is a text file made of braced blocks, with the payment itself in block 4 as tagged fields such as :20: (reference), :32A: (value date, currency and amount), :50a: (ordering customer), :59a: (beneficiary) and :71A: (charges).
Is MT103 still used in 2026?
Yes, but not everywhere. The MT/ISO 20022 coexistence on the CBPR+ cross-border rail ended on 22 November 2025, so cross-border interbank credit transfers now use pacs.008 instead. MT103 remains in wide use in domestic schemes, in bank-to-corporate exchanges and in host-to-host integrations, which is why reading one is still an everyday need.
What replaces the MT103?
pacs.008 (FIToFICustomerCreditTransfer), the ISO 20022 XML message. Every MT103 field maps onto it: :20: becomes the instruction identification, :32A: the interbank settlement date, currency and amount, :71A: the charge bearer, and the UETR of tag 121 is carried unchanged. The MT103-to-pacs.008 comparison table on this page gives the full mapping.
Which fields are mandatory in an MT103?
Six: :20: (sender's reference), :23B: (bank operation code), :32A: (value date, currency and interbank settled amount), :50a: (ordering customer), :59a: (beneficiary customer) and :71A: (details of charges). This viewer refuses to read a message that is missing any of them, and tells you which one.
What does :71A: OUR, SHA or BEN mean?
It says who pays the transfer charges. OUR means the ordering customer pays them all, so the beneficiary receives the full amount. BEN means the beneficiary bears them, and they are deducted from the amount received. SHA means each side pays its own bank's charges. Those three codes are the entire list — anything else is invalid, and this tool rejects it.
What is the UETR in an MT103?
The Unique End-to-end Transaction Reference: a version-4 UUID carried in tag 121 of the user header, block 3. It identifies one payment from origin to destination across every bank that touches it, and it is the same identifier in the ISO 20022 world — which is what makes it the natural key when a payment crosses from MT103 into pacs.008. This viewer checks that it is a well-formed version-4 UUID in lowercase hexadecimal.
Does this tool validate an MT103 against SWIFT's network rules?
No, and it will not pretend to. The Network Validated Rules (C1 to C18) live in the SWIFT User Handbook, which is not freely available. This viewer checks the structure, the mandatory fields, the format of :32A:, the closed charge-code list of :71A:, the shape of an option-A BIC, the UETR and the IBAN check digits — everything that can be verified offline from public documentation. What it cannot check, it lists on screen rather than hiding behind a green badge.
Is my payment file uploaded anywhere?
No. The MT103 is read and decoded entirely in your browser in JavaScript. No part of the message — no account number, no name, no amount — is ever sent to a server.
Source
The field layout used by this viewer is sourced from the European Central Bank, TARGET2 User Detailed Functional Specifications (UDFS), Book 1, v15.0 (26 March 2021), §9.1.2 — a publicly and freely available document. Only the "SWIFT standard" column is applied; the TARGET2-specific restrictions of the "SSP Specifications" column are deliberately ignored, because they would reject valid messages sent over other rails. TARGET2 UDFS Book 1 v15.0 (PDF, ecb.europa.eu)
Legal notice
ValidateFin is an independent tool and is not affiliated with, endorsed by or connected to Swift. "SWIFT" is a trademark of S.W.I.F.T. SC and is used here nominatively, solely to identify the message format being read. This viewer does not verify conformance with the SWIFT network: the Network Validated Rules published in the SWIFT User Handbook are not implemented, and no text from the SWIFT MT Message Reference Guide is reproduced here — every field description on this page was written independently, from the European Central Bank's publicly available TARGET2 UDFS.