Articles / Learning brief
Other Payment Message Standards Beyond SWIFT
Your notes
In simple terms / 01
What this means in plain language
A short map of payment message families that sit outside the SWIFT world: card-transaction messaging with International Organization for Standardization (ISO) 8583, the trade-oriented UN/EDIFACT, North American ANSI ASC X12, and the United Kingdom's Bacs Standard 18 file layout.
SWIFT Message Type (MT) and International Organization for Standardization (ISO) 20022 are the standards most payments courses focus on, but they are not the whole picture. Several other message standards move value or instructions between systems every day. Some describe card-originated transactions, some carry trade and business documents between companies and banks, and some are fixed-format files submitted in national clearing schemes. Recognising the family each message belongs to tells you what shape to expect, who the sender and receiver are, and which rulebook governs it. This guide gives a plain map of four standards you will meet alongside SWIFT.
Complete lesson / 02
Understand the full idea, step by step
By now SWIFT MT and ISO 20022 feel like the whole alphabet of payment messages. They are the two this course teaches in depth — but they are not the only families out there. It helps to recognise the others by name, so that when one turns up in a system diagram you know what it is and, just as usefully, what it is not.
ISO 8583 — the international standard for card-originated transaction messages
ISO 8583 defines the messages behind a card transaction — an authorisation or a clearing record. Each message is built from a message type indicator, one or more bitmaps that flag which fields are present, and a set of numbered data elements. For this academy, recognise it as a distinct message standard only: the card ecosystem itself is out of scope, so we do not teach card-scheme mechanics here.
UN/EDIFACT — UN rules for Electronic Data Interchange for Administration, Commerce and Transport
UN/EDIFACT is an Electronic Data Interchange (EDI) standard — a way for organisations to exchange structured business documents without human re-keying. It is used in international trade and in some bank-to-corporate messaging. Think of it as a language for business documents, of which a payment instruction can be one.
ANSI ASC X12 — the North American EDI standard, including the 820 payment/remittance set
ANSI ASC X12 is the North American EDI standard. Its 820 transaction set carries a payment order or remittance advice — the message that tells a receiver what an incoming payment is for. Where UN/EDIFACT is the international EDI dialect, X12 is the North American one.
Bacs Standard 18 — a fixed-format United Kingdom file layout
Not every standard is a single message — some are file layouts. Bacs Standard 18 is a fixed-format file used to submit Direct Credits and Direct Debits into Bacs, the United Kingdom system that clears on a three-day deferred, netted basis. Positions in each record are defined precisely, so validation checks field placement rather than free-form content.
| Standard | Where you meet it | Shape |
|---|---|---|
| ISO 8583 | Card authorisation and clearing | Message: type indicator, bitmaps, numbered elements |
| UN/EDIFACT | International trade, some bank-to-corporate | EDI business documents |
| ANSI ASC X12 (820) | North American remittance / payment order | EDI transaction set |
| Bacs Standard 18 | United Kingdom Direct Credits/Debits | Fixed-position file layout |
COMMON CONFUSION
“A payment message and a payment file are the same kind of thing.”
They are not. A message, like an ISO 8583 authorisation or an ISO 20022 pacs.008, is a single structured instruction. A file, like Bacs Standard 18, is a batch layout where meaning is carried by the exact position of characters in each record. Both are standards; they solve the problem at different grain — one message versus a whole submission.
STRICTLY SPEAKING
Strictly speaking, this is a map, not a manual. Each of these standards is a large subject with its own versions, code lists, and rulebooks, and several overlap in scope. The goal here is only recognition — enough to place a name correctly and know it sits outside the SWIFT MT and ISO 20022 families this course teaches in depth.
FOR NOW, REMEMBER
- ISO 8583 is the card-transaction message standard — recognise it by name; cards are out of scope here.
- UN/EDIFACT (international) and ANSI ASC X12 (North American, the 820 set) are EDI standards for business documents, including payment and remittance advice.
- Bacs Standard 18 is a fixed-position United Kingdom file layout, not a single message — validation checks field placement.
- These sit alongside SWIFT MT and ISO 20022 as other members of the payment message standards family.
TRY IT YOURSELF
A systems diagram for Asha Traders shows a nightly United Kingdom batch of Direct Credits leaving for its bank, with meaning carried by the exact character position in each record. Which standard is that most likely to be?
One more market-practice layer completes the picture — this time on the corporate-to-bank leg. CGI-MP lets a company like Asha Traders build one ISO 20022 profile instead of a different variant for every bank.
KEEP GOINGKey takeaways / 03
Three things to remember
- 01
International Organization for Standardization (ISO) 8583 is the standard for card-originated financial transaction messages, built from a message type indicator, bitmaps, and numbered data elements. Treat it only as a message standard to recognise, not as the card ecosystem, which is out of scope here.
- 02
UN/EDIFACT and ANSI ASC X12 are Electronic Data Interchange (EDI) standards. UN/EDIFACT is used in international trade and some bank-to-corporate messaging, while X12 is North American, and its 820 transaction set carries a payment order or remittance advice.
- 03
United Kingdom Bacs Standard 18 is a fixed-format file layout for submitting Direct Credits and Direct Debits into the Bacs deferred-net scheme, sitting alongside the message families rather than inside SWIFT.
Practical use cases / 04
Where you would use this
An analyst reconciling a corporate payment run recognises an ANSI ASC X12 820 file as remittance data rather than a settlement instruction, and routes it to the accounts team.
An onboarding engineer at a bank supporting corporate clients maps incoming UN/EDIFACT trade messages so that the payment details can be re-expressed as a SWIFT or ISO 20022 instruction.
A payments operations team validating a Bacs submission checks the fixed field positions defined by Standard 18 before the file is sent for the three-day deferred-net cycle.
Worked example / 05
Put the idea into a real situation
Illustrative example: Northwind Traders Ltd asks its bank, Meridian Bank, to pay 240 suppliers. Northwind sends a Bacs Standard 18 file with 240 fixed-format Direct Credit records for the deferred-net cycle. One overseas supplier, however, invoices through a trade portal that emits a UN/EDIFACT message, so Meridian re-expresses that single payment as a separate cross-border instruction. None of these are SWIFT MT messages, yet all belong to the same wider family of payment message standards.
Evidence & review / 07
Evidence & review
Orientation across payment and business-document message standards outside the SWIFT MT and ISO 20022 families (ISO 8583, UN/EDIFACT, ANSI ASC X12, Bacs Standard 18).
What this brief simplifies: Each standard is summarised for recognition only; versions, code lists, and detailed rulebooks are out of scope, and cards are named as a standard but not taught. Named parties are fictional teaching cast.
Sources for this brief1
- Simplified educational illustration
Payments Signal editorial teaching models — Payments Signal
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.