Banking File Formats 101: The Basics and the Big Buckets (Part 1)
If you work in banking or payments, you’ve probably sat in a call where someone says:
“We support MT940, BAI2 and camt.053 for statements, and pain.001 for payments.”
Everyone nods along. A few people secretly open a new tab.
This blog is to give you a simple way to think about banking file formats, so the jargon finally lands and sticks.
In Part 1, we’ll stay at the “mental model” level. Part 2 will get into actual flows, structures, and design choices.
What is a banking file format, really?
Strip away the acronyms and it’s quite simple: a banking file format is a standard layout for data in a file so two systems can talk without manual clean-up.
It answers questions like:
- Which fields must be present (account, currency, amount, value date, balances, references).
- Order they appear.
- How dates and value are recorded.
- How the file starts, ends, and shows totals so the receiver can check completeness.
Once both sides agree on that layout, you get straight through processing: files in, postings or payments out, minimal human intervention.
Layer 1: How the data is packaged (containers)
First: if you opened the file in a text editor, what would you see?
Most banking files use one of these containers under the hood:
Plain text / flat file
- Lines of text.
- Each line is a “record” (often one transaction).
- Fields are fixed‑width (positions 1–10, 11–22, etc.) or separated by a character like comma or pipe.
CSV
- Still plain text but structured to open nicely in Excel.
- One line per record, fields separated by commas.
XML
- Tag‑based: lots of <TagName>value</TagName>.
- Supports nested structures (a batch containing many payments).
JSON
- Key–value pairs with {} and [].
Shows up more in APIs/webhooks but sometimes as exported files too.
Layer 2: The banking languages (message standards)
The banking flavor comes from the message standard that sits inside the container. That’s the rulebook that says:
- Which fields exist
- What they mean
- How they’re grouped
This is where the famous acronyms live.
The main “languages” you’ll hear
SWIFT MT
- Legacy, text‑based standard used for cross‑border and bank‑to‑bank messages.
- MT1xx: payment messages (e.g., MT101).
- MT9xx: statements and confirmations (e.g., MT940 for end‑of‑day, MT942 for intraday).
ISO 20022
- Modern, richer, XML‑first (and now also JSON) standard.
- pain.* — customer payment initiation; pain.001 is the classic credit transfer batch.
- pacs.* — interbank clearing & settlement.
- camt.* — cash management and reporting; camt.053 is the ISO 20022 account statement.
BAI / BAI2
- Text‑based reporting format, popular in corporate treasury, especially in US‑centric setups.
NACHA / ACH (US)
- Batch payment file standard for ACH credits/debits.
- Very strict line lengths and positional fields; classic “mainframe‑era” feel.
Local formats
- Country‑specific layouts (e.g., CFONB, FEBRABAN 240).
- Usually flat text, with local account structures, tax IDs, scheme codes.
A simple way to hold this in your head:
Containers (text / CSV / XML / JSON) are the envelopes.
Message standards (MT, camt, pain, BAI2, NACHA, local) are the languages written inside the envelope.
The two big jobs banking files do
Most of the formats you’ll encounter are doing one of two jobs:
- Telling the bank what to do
- Telling you what the bank did
1) Payment initiation
These are files your system sends to the bank. Typical scenarios:
- Salary runs from an ERP
- Vendor payment batches
- Marketplace or platform settlements
Instead of keying each payment manually, your ERP or platform generates a file that says, in a very structured way:
“Debit this account and credit these 500 accounts, for these amounts, on this date, with these references.”
Common languages here:
- ISO 20022 pain.001 — credit transfer batches
- SWIFT MT101 — payment orders
- NACHA — ACH payments in the US
- Various local batch formats for domestic rails
You don’t need to remember all of them, the important bit is these are the files that ask the bank to move funds.
2) Reporting / statements
These are files the bank sends to you. They power reconciliation, liquidity, and accounting. Here’s a quick picture:
These formats tell you what actually hit your accounts: balances, transactions, dates, references.
One simple framework you can reuse
When someone drops “MT940”, “camt.053 XML”, or “pain.001 file” into a conversation, run it through three questions:
1) What’s the container?
(Text, CSV, XML, JSON)
2) What language is it speaking?
(MT, ISO 20022, BAI2, NACHA, local)
3) What job is it doing?
(Move money or report it?)
A few quick examples:
· MT940 file
Text → SWIFT MT → Reporting
· camt.053 XML
XML → ISO 20022 → Reporting
· pain.001 file
XML → ISO 20022 → Payment initiation
Same three questions, every time. After a few calls, your brain starts doing this automatically and the alphabet soup suddenly has structure.
What we’ll do in Part 2
In Part 2, we’ll go beyond the basics, how these files actually move, and why those differences matter in practice.
For now, if someone says,
“We’ll send MT940 today and migrate you to camt.053 later,”
you already know both are statement languages, in different envelopes, doing the same job for you.
P.S: What topic do you think we should explore next? Let us know in the comments.
