Here at Plaid (https://plaid.com/docs), we're trying to build this for all the major banks.

I've started building an app with Plaid and so far, it's amazing. Covers the major banks (similar to the original ApplePay banks), and has a beautiful API.

It's just sad that the banking infrastructure underneath is still the old legacy BS. Having to answer security questions or relay two-factor auth is insane. I yearn for the days when we can OAuth with our banks!

Completely agree. We're working on some of this, but ultimately moving to true OAuth is going to require the banks to get more deeply involved.

Hi - we have a consumer financial app on both the appstore and chrome store - how do we get in touch about potentially using your api?

Feel free to reach out -- I'm zach@plaid.com

I think Simple might have one, though I only came across this repo referencing Simple: https://github.com/wearefractal/bank

I used to be the VP of Engineering at Simple. We always wanted to release an API but weren't able to. They're working on a bunch of great stuff over there, but I hope they do release one someday.

As someone who uses Simple every day, I'd kill for an API. Would be cool to do some analytics on my spending on top of what they already provide.

Why weren't they able to? Lack of time, demand, security, did it wrong and had to start over?

I can no longer speak for them, but while I was there we were entirely focused on getting our core consumer online banking product right. We did not want to launch an API without properly supporting the community, and we didn't want to distract ourselves from executing on the core product. There were other complexities but it's not appropriate for me to say any more.

there are api endpoints, just not documented, right?

check devtools when logged into simple.

These libraries are screen scrapers with no security control. You can't make a read only version that prevents an attacker from using your API key to steal your money, for example.

I want to completely disclose Neocities financing, and lack of API for safely doing this has been a frustrating problem.

You would have to proxy the requests on your server, enforce read-only on your public facing API, and keep the token sever-side for talking to the bank?

Put varnish in front of your API to act as a caching layer and prevent anyone from causing your server to overload the bank API.

There is the age-old OFX which many banks and credit card companies do support. May not be quite as complete, but many functions are possible. Typically you need to enable OFX (sometimes wrongly labeled with Quicken nomenclature) and isn't always free. There are a bunch of libraries out there that work with the standard.

I'm not aware of any, but I've been wanting for exactly the same thing. It seems like it would be an interesting (albeit expensive) experiment to build an API-first bank. It would open up all sorts of interesting possibilities like an ecosystem of third-party clients to access your banking information.

We've built exactly this at here https://Holvi.com for business customers. We offer a full bank account replacement with integrated merchant account for online payments. A full API is in private beta at the moment. We are regulated as an authorised payment institution, and can currently service customers in all EU/EEA countries. Email toivotuo@holvi.com for access to the beta.

+1 for Holvi. They're great.