Banking File Formats 102: What These Files Actually Do?
In Part 1, we said every banking file has three things going on:
· A container (text, CSV, XML, JSON),
· A language (MT, camt, pain, BAI2, NACHA, local), and
· A job (either “please move this money” or “here’s what happened”).
Now instead of just looking at formats in isolation, let’s walk through a regular working day and see where these files actually show up.
Payment files: from “approved” to money moving
Picture this. It’s end of month. You’re in your ERP or payout tool, you’ve approved the vendor batch, and you click Pay.
On your screen, you’re done.
But under the hood, that one click just triggered something. Your system picks up every invoice in that batch, organizes them into a single structured file in whatever format your bank agreed to accept, and sends it over a secure channel.
That file is basically saying one thing to the bank:
“Please move this money. Here are the details. Don’t miss anyone.”
At the bank’s end, their system reads that file, validates it against the format rules, checks limits and approvals, and then routes each payment to the right rail: ACH, RTGS, internal transfer, card network and so on.
The format might differ, pain.001, MT101, NACHA, or a local batch format but the structure is almost always the same:
Different markets put different labels on that structure, but the job is the same: a structured way to say, “Please move this money for these N payments.”
2) Statement files: what actually hit your account
Now flip the story.
The payment file captured what you asked the bank to do.
· But did it actually happen?
· Were there bounces?
· What fees apply?
· Does the closing balance match what your system expected?
That’s where statement files come in. Every morning, your ops or finance team is looking at what actually landed on the account overnight. That information arrives in a statement file and depending on your setup, it could look like any of these:
- MT940 — the long-running classic. Text-based, widely supported, most ERPs already know how to read it
- camt.053 — the newer ISO 20022 XML version. More structured, more detail, better for automated reconciliation if your tools handle XML well
- BAI2 — also text, but built around codes and summaries that corporate treasury teams and multi-bank cash management tools are designed around
- CSV or XLS exports — simpler, manual, usually pulled from a bank portal
They all look different. Some are fairly readable, some… not so much.
But they’re all trying to give you the same core things: opening and closing balances, a list of debits and credits, and enough reference information to match each line back to something in your own system.
So Which Format Should You Use?
This is where most teams tend to overthink things.
The honest answer is the right format is the one that creates the least friction in your specific setup. A few simple rules cover most situations:
- If your current tools and banks are aligned around MT940 or BAI2 and your recon works, there’s no need to change just for the sake of it.
- If you’re building newer recon flows and your bank also offers camt.053, that extra structure is often worth using.
- If you’re in a classic treasury setup, especially with US banks, you’ll almost certainly see BAI2 and it will fit that use case well.
In practice, the “right” choice is usually the one that reduces manual work in your setup with the least friction.
Where APIs Fit In
Most teams today work with both files and APIs and understanding how they complement each other removes a lot of confusion.
Files (in all these formats) still carry the heavy scheduled jobs: salary runs, vendor payouts, bulk collections, daily statements. APIs and webhooks sit alongside that, giving you live behavior like instant balances, on‑demand mini‑statements, or immediate status on important payments.
A useful way to think about it: files handle the big, predictable jobs; APIs handle the small, live questions.
ISO 20022 is simply the newer language a lot of this data is moving towards, whether it arrives as a camt.053 file or as structured data from an API. The underlying information is the same, only the packaging and timing change.
Putting It Together
If Part 1 gave you the model: container, language, job. Part 2 is what that model looks like in motion.
Payment files are how you tell the bank to move money. Statement files are how the bank tells you what actually happened. And the formats: MT940, camt.053, BAI2 are just different ways of writing that story down.
Next time someone says, “we support MT940, BAI2 and camt.053”, you won’t just nod along. You’ll know exactly what they mean, why the differences matter, and which one fits your situation.
P.S: What topic do you think we should explore next? Let us know in the comments.
