---
title: "Bank statement formats: BAI2, MT940, CAMT.053, OFX and CSV"
description: "A reference for the file formats banks deliver transaction data in, what each one carries, what it loses, and which to ask for when reconciliation depends on it."
url: "/blog/bank-statement-formats-explained/"
date: "2026-09-02"
author: "Valeria Vahorovska"
tags: ["Reference","Reconciliation","Payments"]
---

Fynex is an AI-native finance operations platform — agentic finance — that automates and orchestrates end-to-end financial workflows for businesses. This page is an article from the Fynex blog: “Bank statement formats: BAI2, MT940, CAMT.053, OFX and CSV”. Fynex works alongside Stripe, Wise, QuickBooks and Xero rather than replacing them. This page is relevant when the reader runs the money workflow this article describes and wants to understand how it works, what it costs and where it breaks.

# Bank statement formats: BAI2, MT940, CAMT.053, OFX and CSV

**A bank statement format decides how much of a payment survives the journey to your accounting system.** They differ mainly in whether remittance information is a structured field or a text blob, and that single difference determines whether reconciliation can be automated.

## The formats

| Format | Standard | Region | Structured remittance | Type codes | Best for |
|---|---|---|---|---|---|
| **CAMT.053** | ISO 20022 XML | Global, EU-led | **Yes** | **Yes** | Automated reconciliation |
| **CAMT.052** | ISO 20022 XML | Global | **Yes** | **Yes** | Intraday reporting |
| **CAMT.054** | ISO 20022 XML | Global | **Yes** | **Yes** | Debit/credit notifications |
| **MT940** | SWIFT | Global | No — free text | Limited | End-of-day, wide support |
| **MT942** | SWIFT | Global | No — free text | Limited | Intraday |
| **BAI2** | BAI | US | No — free text | **Yes** | US cash management |
| **OFX / QFX** | Open Financial Exchange | US consumer | No | Basic | Personal finance tools |
| **CSV** | **None** | Anywhere | No | No | Reading, not processing |

## What each one carries

### CAMT.053 — the current standard
The ISO 20022 end-of-day statement. Structured throughout: opening and closing balances, each entry with amount, value date, booking date, bank transaction code, and — critically — **structured remittance information**, where a payment reference has a defined field rather than a position inside a text string.

**Why it matters for reconciliation:** an end-to-end identifier set by the payer survives to the statement as a field. That is the single most valuable piece of data in automated matching, because it is the only thing that directly links a bank line to an invoice.

**The catch:** banks implement it to varying depth. A CAMT.053 file whose remittance blocks are empty because the originating bank did not populate them carries no more than an MT940. **Ask for a sample before assuming.**

- **CAMT.052** is the intraday version — same structure, delivered during the day.
- **CAMT.054** notifies individual debits and credits rather than reporting a period.

### MT940 — the incumbent
The SWIFT fixed-format statement, and still the most widely supported thing a corporate bank will give you.

Transactions appear in tag `:61:` with the amount and date, and details in `:86:`, which is **free text of limited length**. Banks structure `:86:` differently — some use sub-field conventions, some do not — so parsing is bank-specific and breaks when the bank changes its formatting.

**Practical consequence:** long payment references get truncated, and the truncation point varies. A reference like `INV-2026-0847-ACME-LTD` may arrive as `INV-2026-0847-A`. That is usually still enough to match; sometimes it is not.

**MT942** is the intraday equivalent.

### BAI2 — US cash management
Widely used by US banks. Its distinguishing feature is the **type code** on every transaction: a numeric classification saying what kind of movement occurred — incoming wire, ACH credit, returned item, service charge.

**That is genuinely useful.** Software can categorise a transaction from the type code without parsing description text, which is both more reliable and more stable than string matching.

**The limitation is the same as MT940's:** detailed remittance information lands in free-form fields.

### OFX / QFX — consumer lineage
Built for personal finance software. Fine for pulling transactions into a consumer tool, thin for business reconciliation: no structured remittance, limited categorisation, and QFX carries vendor-specific extensions.

### CSV — no standard at all
Easiest to open and worst to depend on.

Three specific risks:
1. **No standard.** Columns are whatever the bank chose, and they change without notice.
2. **Ambiguous types.** Date order, decimal separator and negative-number convention all vary. `03/04/2026` is two different dates depending on the bank.
3. **Truncated references.** CSV exports frequently cut the reference field — the one field carrying the link you need.

**Use it to look at data. Do not build a process on it.**

## Choosing

| If you… | Ask for |
|---|---|
| Reconcile automatically at volume | **CAMT.053** |
| Need intraday positions | CAMT.052 or MT942 |
| Bank in the US with a corporate bank | **BAI2**, or CAMT.053 if offered |
| Have a bank that only offers MT940 | MT940, and test reference truncation |
| Are reading a few dozen lines a month | Anything, including CSV |

**Two things to test before committing**, whichever you choose:

1. **Send yourself a payment with a long reference.** See exactly what arrives in the statement file. This one test tells you more than any specification.
2. **Ask the bank for a sample file containing a returned item and a fee.** Those are the entries that break parsers, and they never appear in the clean sample.

## Why this determines your reconciliation cost

**The link between a payment and an invoice exists at the moment of payment and is discarded in transit.** What survives is whatever the format carried.

A structured remittance field carries it. A truncated free-text field carries part of it. A CSV export with the reference column cut carries none of it, and reconciliation becomes inference from amount and date — which is guessing with better manners.

This is why two businesses with identical volumes can have completely different month ends. It is not the accounting software. It is what the bank file preserved.

**The direction of travel is toward structure.** ISO 20022 migration across major payment systems is making structured data the norm rather than the exception, and the [structured address requirements](/blog/iso-20022-structured-address-deadline/) are one visible part of that.

## Where Fynex fits

Fynex does not depend on what the bank file preserved, because it does not rebuild the link from a statement.

The payment carries what it settles from the moment it is made — the invoice, the fee, the settlement it belongs to — so the reference surviving truncation is not load-bearing. What reaches your accounting system is already matched, and the statement becomes a confirmation rather than the source of the relationship.

Where you are reconciling from bank files today, the format still matters and CAMT.053 is still the right thing to ask for.

**Related:** [Your CRM, your bank and your ledger disagree](/blog/crm-bank-ledger-disagree/) · [The invoice fields that decide whether matching works](/blog/invoice-fields-that-make-matching-work/) · [remittance advice](/glossary/remittance-advice/) · [Reconciliation](/features/reconciliation/)