Bank Statement Formats: OFX, MT940, CAMT.053, BAI2, and More

Banks export transaction data in a dozen different formats depending on country, software, and banking tier. This guide covers each format — what it looks like, who uses it, what the fields mean, and how to convert between them without losing data.

Structure

Early OFX used a header-plus-SGML structure (tagged but not valid XML). OFX 2.x uses clean XML. Both are still common in bank exports:

<OFX>
<BANKMSGSRSV1>
<STMTTRNRS>
<STMTRS>
<CURDEF>USD</CURDEF>
<BANKACCTFROM>
<BANKID>123456789</BANKID>
<ACCTID>9876543210</ACCTID>
<ACCTTYPE>CHECKING</ACCTTYPE>
</BANKACCTFROM>
<BANKTRANLIST>
<STMTTRN>
<TRNTYPE>DEBIT</TRNTYPE>
<DTPOSTED>20260115</DTPOSTED>
<TRNAMT>-42.50</TRNAMT>
<FITID>2026011501</FITID>
<NAME>GROCERY STORE</NAME>
</STMTTRN>
</BANKTRANLIST>
<LEDGERBAL>
<BALAMT>2814.35</BALAMT>
<DTASOF>20260131</DTASOF>
</LEDGERBAL>
</STMTRS>
</STMTTRNRS>
</BANKMSGSRSV1>
</OFX>

Key fields

• TRNTYPE — DEBIT, CREDIT, INT (interest), DIV (dividend), FEE, ATM, POS, XFER, CHECK, PAYMENT, CASH, DIRECTDEP, DIRECTDEBIT, REPEATPMT, HOLD, OTHER
• DTPOSTED — Transaction date in YYYYMMDD format (or YYYYMMDDHHMMSS)
• TRNAMT — Signed amount; negative = debit/outflow
• FITID — Unique transaction ID assigned by the financial institution; used to prevent duplicate imports
• NAME — Payee name or description
• MEMO — Additional transaction details (optional)

When to use

• Importing into GnuCash, Moneydance, Money, or any personal finance app
• Small business bookkeeping where your bank offers OFX download
• Creating files programmatically for import into accounting software

Structure and field tags

:20:STMT202602          ← Transaction reference
:25:DEUTDEFF/DE89370400440532013000  ← Account (BIC/IBAN)
:28C:00001/001          ← Statement number / sequence
:60F:C260131EUR12500,00 ← Opening balance (Credit, date, currency, amount)
:61:2602010201D42,50N029NONREF       ← Statement line (transaction)
:86:Invoice 2026-001 - Supplier ABC  ← Information (free text)
:61:2602050205C1500,00N062NONREF
:86:Customer payment - Order #12345
:62F:C260205EUR13957,50 ← Closing balance

Field reference

Parsing the :61: statement line

The :61: field packs several values with no separators:

:61:2602010201D42,50N029NONREF
↑       ↑ ↑    ↑   ↑
|       | |    |   └─ Reference for account owner
|       | |    └───── Bank transaction code
|       | └────────── Amount (EUR comma-decimal format)
|       └──────────── D=Debit / C=Credit
└──────────────────── Value date YYMMDD, optionally followed by
entry date MMDD (here: 260201 + 0201)

Bank transaction codes (N029, N062, etc.) are not standardized across banks — each bank defines its own codes. This makes generic MT940 parsers imperfect; you often need bank-specific mapping tables.

MT940 character set limitation

MT940 officially uses a subset of ASCII with no accented characters. In practice, banks use ISO-8859-1 or their local Windows code page, which means non-ASCII characters in beneficiary names or references may be corrupted in transit or parsing. CAMT.053 solves this by using UTF-8.

QFX

QFX (Quicken Financial Exchange) is Intuit's proprietary variant of OFX. The file format is nearly identical to OFX — same tags, same structure — with one addition: an INTU.BID header identifying the financial institution for Quicken's online update feature. Most US and Canadian banks offer QFX downloads.

OFXHEADER:100
DATA:OFXSGML
...CHARSET:1252
<INTU.BID>12345</INTU.BID>     ← Intuit bank ID (QFX-specific)
<OFX>
... (standard OFX content)
</OFX>

If you have a QFX file that another tool can't read, try renaming it to .ofx — most OFX-compatible software accepts QFX files without the Intuit extension.

QIF

QIF (Quicken Interchange Format) is the original Quicken format from the 1980s. Despite being officially deprecated by Intuit in 2005, many banks and tools still support it because of its simplicity:

!Type:Bank
D01/15/2026       ← Date (US format MM/DD/YYYY)
T-42.50           ← Transaction amount (negative = debit)
PGrocery Store    ← Payee
LFood:Groceries   ← Category (Quicken category:subcategory)
MWeekly shopping  ← Memo
^                 ← Record separator (caret)
D02/01/2026
T1500.00
PClient Payment
LIncome:Services
^

QIF limitations: no unique transaction IDs (can't prevent duplicates on re-import), US-only date format by default, no multi-currency support per transaction, no account balance information.

What is CAMT.053?

CAMT.053 is the ISO 20022 message type for Bank-to-Customer Account Statement — the standardized replacement for MT940 in Europe's SEPA payment area. It uses structured XML that's far more detailed than MT940's free-text fields.

<Document xmlns="urn:iso:std:iso:20022:tech:xsd:camt.053.001.08">
<BkToCstmrStmt>
<Stmt>
<Id>STMT-2026-02-001</Id>
<Acct>
<Id><IBAN>DE89370400440532013000</IBAN></Id>
<Ccy>EUR</Ccy>
</Acct>
<Bal>
<Tp><CdOrPrtry><Cd>OPBD</Cd></CdOrPrtry></Tp>
<Amt Ccy="EUR">12500.00</Amt>
<CdtDbtInd>CRDT</CdtDbtInd>
</Bal>
<Ntry>
<Amt Ccy="EUR">42.50</Amt>
<CdtDbtInd>DBIT</CdtDbtInd>
<BookgDt><Dt>2026-02-01</Dt></BookgDt>
<NtryDtls><TxDtls>
<RltdPties>
<Cdtr><Nm>Supplier ABC GmbH</Nm></Cdtr>
</RltdPties>
<RmtInf><Ustrd>Invoice 2026-001</Ustrd></RmtInf>
</TxDtls></NtryDtls>
</Ntry>
</Stmt>
</BkToCstmrStmt>
</Document>

CAMT.053 vs MT940

ISO 20022: the umbrella standard

ISO 20022 is the overarching standard containing CAMT.053 and dozens of other financial message types. SWIFT completed its MT-to-MX (ISO 20022) migration in November 2025 for cross-border payments. Key message types:

• CAMT.052 — Intraday bank-to-customer account report (not a full statement)
• CAMT.053 — End-of-day account statement (replaces MT940)
• CAMT.054 — Credit/debit notification (individual transaction notification)
• PAIN.001 — Customer credit transfer initiation (you → bank, payment instruction)
• PAIN.008 — Direct debit initiation
• PACS.008 — Financial institution credit transfer (bank-to-bank)

NACHA uses a fixed-width format where every record is exactly 94 characters. Record type is identified by the first digit:

1 = File Header
5 = Batch Header
6 = Entry Detail (one per transaction)
7 = Addenda Record (additional transaction info)
8 = Batch Control
9 = File Control

101 091000019 1234567890260201...       File Header
5200ABC Company        1234567890PPD... Batch Header (PPD = Prearranged Payment)
62209100001912345678   0000004250...    Entry Detail (routing, account, amount)
8200000001000910000010000000000004250   Batch Control
9000001000001000000010009100001004250   File Control

Entry Detail fields (record type 6)

NACHA files are for payment initiation, not statement download — you create them to send to your bank for processing, or receive them from your bank to reconcile incoming ACH transactions.

BAI2 uses comma-delimited records with numeric type codes:

01,BANKNAME,COMPANYID,260201,1200,001,80,1,2/       ← File Header
02,123456789,BANKNAME,1,260201,1200,USD/             ← Group Header
03,9876543210,USD,010,125000,,015,134575,/           ← Account Header (type codes below)
16,195,4250,0,260201,,REF001,Supplier Payment/       ← Transaction (type 195 = wire debit)
49,134575,2/                                         ← Account Trailer
98,134575,1,2/                                       ← Group Trailer
99,134575,1,2/                                       ← File Trailer

BAI2 type codes

BAI2 uses numeric codes for account and transaction types. Common ones:

CSV is also the only format that any bank, accountant, or tool can open without specialized software. When in doubt about what format to share, convert to CSV first. The Spreadsheet Tools hub has converters for CSV to Excel, CSV to JSON, and most other format pairs.

Column mapping varies by source

Different source formats produce different CSV column sets. An MT940-to-CSV conversion will have columns like value_date, entry_date, debit_credit, amount, transaction_code, description. An OFX-to-CSV will have date, amount, type, fitid, name, memo. Plan your column mapping before importing.

What converts cleanly

These conversions preserve all useful data:

• Any format → CSV — always works, minor metadata loss
• OFX ↔ QFX — nearly identical formats
• MT940 → CSV — all transaction data preserved; field codes become columns
• CAMT.053 → CSV — XML structure flattens to columns; rich data preserved
• NACHA → CSV — all 94-character records decoded to readable fields
• BAI2 → CSV — type codes resolved to descriptions

Conversions with caveats

• MT940 → OFX — MT940 bank transaction codes (N029, N062) have no OFX equivalent. They get dropped or stuffed into MEMO.
• CAMT.053 → MT940 — Structured IBAN/BIC fields flatten to free text. Remittance info truncated to 390 chars. Character set downgrades from Unicode to SWIFT subset.
• CSV → any format — Works if your CSV has the required fields (date, amount, account number), but you have to generate IDs (FITID for OFX, reference for MT940) that may not match the bank's records.

Available converters

CSV import tips for accounting software

Most accounting tools that accept CSV want at minimum: date, amount (signed or two separate debit/credit columns), and description. Common issues:

• Date format — Know what the target expects (MM/DD/YYYY vs YYYY-MM-DD). Wrong format silently misparses years and months.
• Amount sign — Some tools want a single signed amount (negative = debit); others want separate debit and credit columns. Never both.
• Encoding — Save as UTF-8 with BOM for Excel-based import tools; UTF-8 without BOM for everything else.
• Duplicate prevention — OFX FITID and MT940 references help; CSV has no built-in dedup mechanism, so software relies on date+amount+description matching.

• MT940 — Officially restricted to SWIFT character set (ASCII subset, no accented characters). Banks in practice use ISO-8859-1 or their local Windows code page. German umlauts in company names get mangled when the file is read as UTF-8.
• OFX — Declares encoding in the CHARSET header field (e.g., CHARSET:1252). Some banks declare Windows-1252 but write Latin-1. Check by looking at characters in the 0x80–0x9F range.
• CAMT.053 — XML standard mandates UTF-8. Encoding issues rare; BOM is possible from Windows-generated files but not required.
• BAI2 / NACHA — Fixed-width ASCII; high-byte characters are simply absent or replaced with spaces.
• CSV exports — Entirely dependent on the source system. European banks commonly use ISO-8859-1 or Windows-1252. Always check before importing.

For deeper encoding diagnosis and conversion, see the Text Encoding Guide or use the Text Encoding Converter.

• Use client-side tools. All ToolsDock converters process files locally in your browser using JavaScript. Nothing is uploaded to a server. Verify this for any tool you use by checking network traffic in browser dev tools — there should be no upload requests during conversion.
• Delete converted files after import. Don't leave CSV copies of bank statements in a Downloads folder or send them via unencrypted email.
• Verify output before importing. Compare transaction count and totals between source and converted file. A parser bug that shifts columns can turn a debit into a credit without any error message.
• Account numbers in files. OFX and MT940 include full account numbers. If sharing a converted file with a third party (accountant, auditor), consider redacting the account number column from the CSV unless they need it.