Glossary
What Is an OFX File?
OFX, short for Open Financial Exchange, is the published specification that describes how banks, brokers and accounting programs pass statements and transactions between each other. A file ending in .ofx is one such message saved to disk: a sign-on block, the identity of the financial institution, and a list of transactions. It is also the parent of the formats around it - the .qfx and .qbo downloads are the same specification with vendor-specific additions on top.
TL;DROFX is the specification the whole family of bank download formats is built on, split into an SGML branch and an XML branch and delivered either as a file you download or as a direct link between program and bank.
2.3
the current version of the OFX specification, while the .qfx and .qbo downloads in circulation are still built on the older 1.x branch
Who Wrote OFX, and Who Keeps It Now
OFX was announced in January 1997 by three companies at once - Microsoft, Intuit and CheckFree - and version 1.0 of the specification followed a month later, in February of the same year. That joint origin is the reason the format spread the way it did: it arrived already agreed between a bank-side processor and the two dominant personal finance programs, rather than as one vendor's private export. Stewardship has since moved on. Since 2019 the specification has been maintained by FDX, an industry body for financial data sharing, and the original three are no longer the ones who publish it.
A reader does not guess the version - the file declares it. Every OFX message opens with a header that names the branch it belongs to and the character set it is written in, and that header is the first thing a program looks at. It is also why the 1.x branch has no UTF-8 to offer: the encoding options in that header predate it.
OFX 1.x Is SGML, OFX 2.x Is XML
The single most useful thing to know about an OFX file is which branch it belongs to. Versions 1.0 through 1.6 are SGML: the tags look like markup, but closing tags are optional and mostly absent, so a value simply runs until the next tag begins. Version 2.0 onward is proper XML, with a declaration at the top and every element closed. The two branches carry the same ideas - the same blocks, the same field names - written under two different sets of syntax rules.
The practical consequence is that a strict XML parser will reject a perfectly valid OFX 1.x file, and reject it with a syntax error that says nothing about banking. Anything that reads this family for real has to handle both dialects with one reader.
The file extension does not tell you the branch. An .ofx file may be either dialect, and so may a .qfx or a .qbo. What the extension really tells you is which program the sender expected you to open it in, which is a different question from what is inside.
Web Connect and Direct Connect: Two Ways the Same Data Travels
OFX describes the messages, not the delivery. There are two delivery mechanics, and confusing them is behind a lot of support threads. Web Connect is the manual route: you sign in on the bank website yourself, click a download link, get a file on your own disk, and import it into your finance program by hand. Direct Connect is the automatic route: the program itself talks to the bank server, sends the same OFX messages over the network and pulls the transactions in without a file ever appearing in your downloads folder.
The same specification covers both, which is why a Web Connect file and a Direct Connect session look so similar once you read them. What differs is who initiates the exchange, and what the bank has to switch on: Direct Connect usually has to be enabled on the account, and not every institution offers it at all.
Dates inside an OFX file are unambiguous by design - they are written as YYYYMMDD, year first. Whatever a bank prints on the paper statement, the file itself leaves no room for the day-month mix-up that plagues older text exports.
What Is Actually Inside an OFX File
Open one and the structure is easy to follow even without the specification in front of you. There is a sign-on response with a server timestamp and language, a block identifying the financial institution, then one statement block per account - checking, credit card or investment - each with its currency, its account number and a run of transaction records. Each transaction carries a type, a posted date, an amount, a unique transaction id assigned by the bank, and the payee and memo text.
That is enough for a program to load the statement and reconcile it. It is not enough to hand to a person: the file is text, but reading a year of transactions out of nested tags is not how anyone wants to check a balance, and none of the finance programs will show you the file unless you first import it into a live account.
Related Guides
Related Terms