Bank statement formats: the pitfalls CFONB, BAI2, OFX and CAMT.053 each create
Every bank speaks a slightly different dialect for its statement exports. The pitfalls aren't in the big differences — they're in the small ones that look compatible until they aren't.
"Just import the bank statement" sounds like a single, simple integration — until the statement in question could be CFONB 120, BAI2, OFX, CAMT.053, or a bank-specific CSV with its own column order and date format, and none of them agree on how to represent the same underlying transaction. This isn't about matching logic or bank-specific CSV quirks — that ground is covered elsewhere — it's one level lower: the format-specification pitfalls that break a parser before matching logic ever runs, including the two formats (CFONB and CAMT.053) that a US/UK-only reconciliation tool has never had to deal with at all.
CFONB 120 — France's legacy fixed-width format
CFONB 120 is a fixed-width record format historically transmitted via EBICS, with amounts represented in a "surfrappe" (overstrike) encoding inherited from mainframe-era systems — a character-level convention for representing the sign of an amount that has nothing to do with how any modern system naturally stores a number. A parser that treats CFONB amounts as plain decimal numbers will silently misread signs on a subset of transactions, because the sign isn't stored the way it's usually assumed to be stored.
CAMT.053 — the ISO 20022 standard for SEPA
CAMT.053 is the modern XML-based standard across the SEPA zone, structurally far cleaner than CFONB — but its flexibility is itself a pitfall. The standard allows optional fields and multiple valid ways to represent the same piece of information (a reference number can appear in several different XML elements depending on how the originating bank populated the file), so two banks' CAMT.053 exports can both be valid and still require different parsing logic to extract the same underlying detail.
BAI2 — the US cash-management standard
BAI2 (Bank Administration Institute format 2) is the common denominator for US commercial bank cash-management reporting, structured around transaction type codes that classify each line item. The pitfall here is that the SAME type code can be used by different banks to mean subtly different things in edge cases — a code nominally meaning "miscellaneous credit" covers a wide and bank-specific range of actual transaction types, and treating the code as a universal, self-explanatory classification rather than a starting point for further inspection misses real distinctions.
OFX/QFX — the consumer and small-business standard
OFX (and its QFX variant) is widely supported for consumer and small-business banking exports, but "widely supported" doesn't mean "consistently implemented" — different institutions' OFX exports vary in which optional fields they populate, and a reference number that one bank reliably includes is frequently blank from another, even though both files validate as well-formed OFX. Which specific US and UK institutions get this wrong in which specific ways is its own list, covered in detail separately — the point here is the general failure mode: format validity and data completeness are two different guarantees, and OFX only promises the first.
The CSV problem underneath all of it
Below every standard above sits the reality that a large share of actual bank exports are still bank-specific CSVs, with no schema to reject a malformed file — a parser tuned against one bank's export will often accept a different bank's file without error, and silently misread a date or an amount rather than failing loudly. CSV's complete lack of a schema is what makes it the format most likely to fail silently rather than obviously.
What a reconciliation engine actually needs to get right
| Format | The specific pitfall |
|--------|------------------------|
| CFONB 120 | Overstrike sign encoding, not a plain decimal amount |
| CAMT.053 | Valid files that place the same data in different XML elements |
| BAI2 | Transaction type codes that mean different things bank to bank |
| OFX/QFX | Optional fields inconsistently populated across institutions |
| Bank CSV | No schema — a malformed date or amount parses without error |
The common thread across every one of these is that the failure is silent. None of these formats reject a file for being misread — they just get misread, and the resulting reconciliation error looks like a genuine unmatched transaction rather than a parsing bug, which is exactly what makes it expensive to trace back to its actual cause.
Related reading
FAQ
Is one of these formats simply better than the others?
CAMT.053's structure is more consistent than a bank-specific CSV, but "structured" doesn't mean "uniformly implemented" — every format on this list has produced real parsing bugs in practice, just different ones. The format alone doesn't guarantee correctness; the parser's handling of that format's specific edge cases does.
Why hasn't the industry standardized on one format?
Partly historical inertia (CFONB predates SEPA by decades and is still in active use), partly because different formats serve different use cases (BAI2 for US cash management, CAMT.053 for SEPA-wide standardization) that never had a strong enough reason to converge.
Does automated format detection eliminate these pitfalls?
Detecting WHICH format a file is written in is the easy part — a file's structure usually makes that obvious. The pitfalls described here happen AFTER correct format detection, inside the parsing logic for that specific format's edge cases, so format detection alone doesn't solve them.