What is OFX Format?

Open Financial Exchange was born from the merger of two competing standards. In the mid-1990s, Microsoft developed Open Financial Connectivity (OFC) for Microsoft Money, while Intuit and CheckFree backed their own specification. In 1997, all three companies agreed to unify their efforts, producing OFX 1.0 — a specification that would become the backbone of online banking data exchange for the next three decades.

OFX 1.0 through 1.6 used SGML (Standard Generalized Markup Language) as their underlying syntax. SGML allowed the format to omit closing tags, which made files smaller but harder to parse with standard XML tools. In 2004, the OFX consortium released OFX 2.0, which migrated to well-formed XML. This transition made OFX files compatible with the vast ecosystem of XML parsers available in every programming language.

The specification is maintained by the OFX consortium, a group of financial institutions and technology companies. As of 2026, the latest version is OFX 2.2, which added support for tax reporting, loan accounts, and enhanced security mechanisms. Despite the availability of newer versions, the majority of banks still serve OFX 1.x files due to the massive installed base of legacy software.

Intuit created two proprietary derivatives of OFX: QFX (for Quicken) and QBO (for QuickBooks). Both add Intuit-specific headers — primarily the INTU.BID identifier — to an otherwise standard OFX file. This means that while OFX is an open standard, the two most popular accounting platforms in the United States require proprietary modifications to accept it.

An OFX file consists of two parts: a plain-text header section and a structured SGML or XML body. The header declares the OFX version, character encoding, and security level. The body contains one or more message sets — sign-on responses, bank statement responses, credit card statement responses, or investment position reports.

The most common use case is a bank statement download, which uses the BANKMSGSRSV1 message set. Within it, the STMTRS (Statement Response) element contains account identification, the transaction list, and the ledger balance.

Notice the SGML syntax: opening tags like <TRNAMT> have no corresponding closing tag. The value follows immediately on the same line. This is valid SGML but will cause errors in standard XML parsers — a frequent source of confusion for developers encountering OFX for the first time.

Each transaction block is wrapped in <STMTTRN>...</STMTTRN> tags. The FITID (Financial Institution Transaction ID) is a unique identifier assigned by the bank to each transaction — it is what prevents duplicate imports when the same file is loaded multiple times.

The most significant technical distinction in the OFX ecosystem is between versions 1.x and 2.x. OFX 1.0 through 1.6 use SGML, which allows tags to omit their closing counterparts. In practice, this means a value like <TRNAMT>-1250.00 is complete — no </TRNAMT> is needed. Container elements like STMTTRN do have explicit closing tags.

OFX 2.0 and later require well-formed XML with proper closing tags on every element. The header also changes from the plain-text key-value format to an XML processing instruction. While OFX 2.x is easier to parse with standard tools, the vast majority of banks still export OFX 1.x because of backward compatibility with older accounting software.

If you are building software that reads OFX files, plan to handle both variants. The simplest approach is to detect the header format — if the file starts with OFXHEADER:100, it is SGML; if it starts with <?xml or <?OFX, it is XML. Many parsers pre-process SGML files by inserting closing tags before feeding the result to a standard XML parser.

OFX files are plain text (SGML or XML), so you can open them in any text editor to inspect the raw transaction data. Look for <STMTTRN> blocks to find individual transactions.

For spreadsheet analysis, convert OFX to a tabular format. FinanceConvert's OFX to CSV converter extracts all STMTTRN fields into clean columns: Date, Description, Memo, Debit, Credit, Balance, Currency, and FITID. For Excel with native formatting, use the OFX to Excel converter.

For QuickBooks import, OFX files must be converted to QBO format with the required Intuit headers. The OFX to QBO converter adds the OFXHEADER preamble and INTU.BID that QuickBooks expects. For Quicken users, the OFX to QFX converter performs the same function.

To create archival transaction records, the OFX to PDF converter generates a formatted, printable statement document from your OFX data.

SGML parsing failures. The most common technical problem is trying to parse OFX 1.x files with a standard XML parser. Since SGML omits closing tags, XML parsers will throw syntax errors. You need either a dedicated OFX parser or a pre-processor that adds the missing closing tags before XML parsing.

Missing or invalid FITID. Some banks generate duplicate FITIDs or leave them empty. Since the FITID is the primary mechanism for deduplication, missing FITIDs can cause duplicate transactions on import. If you notice duplicates after importing OFX files, check the FITID values in a text editor.

Encoding mismatches. The OFX header declares the character encoding (typically USASCII or UTF-8), but some banks include characters outside the declared encoding — accented characters in payee names, for example. This can cause garbled text or import failures in strict parsers.

Date format inconsistencies. While the OFX specification mandates YYYYMMDD, some bank implementations append timezone offsets (e.g., 20260315120000[-5:EST]) that not all parsers handle correctly. Others omit the time portion entirely when the spec expects it.

Intuit software rejection. As noted above, Quicken and QuickBooks reject standard OFX files. The error messages are often cryptic — Quicken may display "This file is not a valid Quicken file" without explaining that the INTU.BID header is missing. Converting to QFX or QBO resolves the issue.