Anectodally speaking, here’re some banks that I know of that support it as of today:
- alliant - ally - becu - capitalonebank - chase - citi (direct download supported) - etrade (direct download supported) - fidelity (direct download supported) - morganstanley (direct download supported) - target - techcubank - vanguard And again, anecdotally, here are the banks that removed support for it in the last couple years: - amex - discover - schwab Ofx was introduced in 1997. In the tech world, that is old. It will eventually go away. But nobody knows when the remaining institutions will remove support for it. So how should one approach ofx when writing importers? Here’s my two cents: 1) For me, the interesting question is not “should I invest time into setting up an ofx import” as much as it is “how can I setup my import system for adaptability so swapping out a file format for another is easy?” - Consider also that the download method and the file format are only, say, 20% of your import system with respect to setup effort and complexity 2) Consider your alternatives. Here’s an example of development times (this is unscientific, and the relative times are more important than the absolute numbers): - ofx: 5mins - csv: 1-2 hours - some_other_format (json, xml): 2-4+ hours In addition, Non-ofx formats unfortunately have a lot of downsides <https://reds-rants.netlify.app/personal-finance/a-word-about-input-formats-use-ofx-when-you-can/> . 3) Don’t confuse direct downloads with ofx. Some banks have pulled support for direct downloads, but continue to support ofx if you download them manually from their website. An example is Chase. Summary: setup ofx today when you can. There’s no downside to doing so IMHO as it’s low effort. Focus on building a robust ingest system where changing file formats is an easy, small part. And finally, what does the future hold? - Europe is ahead of the US/North America: finance.ec.europa.eu <https://finance.ec.europa.eu/digital-finance/framework-financial-data-access_en> - The US is doing something about it as well. See federalregister.gov <https://www.federalregister.gov/documents/2023/10/31/2023-23576/required-rulemaking-on-personal-financial-data-rights>, though so far, despite mentioning “consumer access” here and there. it seems to be somewhat focused on “third party access.” On Saturday, September 28, 2024 at 2:40:41 PM UTC-7 chri...@gmail.com wrote: > I've been using beancount for about 2 years now, and in the last month > I've started looking more closely at the External Contributions > <https://docs.google.com/document/d/1Z37bQ45wDtjTPaMQ_x-f33p1trH9fNosEAUgbQXwp30/edit#heading=h.rs27hvxo0wyl>. > > I decided to try reds-importers, and pretty quickly discovered a few things: > > 1. ofxhome.com is gone. > 2. ofx.chase.com doesn't work anymore ("Name or service not known") > 3. FDX is a new thing, and does not appear to be friendly to > open-source accounting tools like beancount. > > For those that have used OFX for a long time - is it slowly going away? > Are there alternatives that facilitate automatic downloads? > > -- You received this message because you are subscribed to the Google Groups "Beancount" group. To unsubscribe from this group and stop receiving emails from it, send an email to beancount+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/366e7fc7-269b-4327-8abb-f8facd1b167fn%40googlegroups.com.
