If you want to create an app or startup that does anything involving banking, look elsewhere. The chances you will get approval from banks and regulators are zero. To have a halfway decent shot, you would need years, significant industry connections, expensive lawyers on retainer in New York and Washington, and the ability to prove you have cash on hand in the high 7 figures.
Here's a good example of what I'm talking about: https://medium.com/@oscargodson/thatll-do-pig-that-ll-do-899...
Full disclosure, I work for Capital One now. So... C1 has stated publicly it's interested in this space and some of its prominent employees are in prominent public technical groups trying to make it happen. The liability and fraud stories are really unimaginably complicated.
For people looking to make a product today, I've decided to add a quick primer:
Finicity, FinancialServices, and Plaid are all financial aggregators that you can use in combination with novel (read: quasi-legal) mechanisms you can use to provide financial services within the confines of the beleaguered law.
In general a financial product's engineering cycle looks like this:
1. Find a data aggregator you can partner with and give most of your profits to.
2. Work very hard on experience driven products.
3. Find a good lawyer who can help you produce a novel interpretation of the law that works with a specific financial product.
4. Still have limited success because fintech products have linear adoption curves (even Mint).
Examples in this space of novel mechanisms that use existing payment services, data aggregation products and very clever lawyers: Acorns, Digit, Tally.
I was one of the founders and the founding engineer of Level, and worked on Simple. My general observation is that most of the challenge is around data quality and aggregation on the technical side of things.
A lot of the challenge of making these apps work is balancing your fraud risk with your customer experience. Customers are apathetic and inclined to ignore the space, fraudsters are diabolically clever and very engaged.
Even though Plaid comes up a lot in these conversation, I haven't found their pricing any better or startup friendly than any other provider (fincity, yodlee etc).
Better marketing yes. Better api? Meh.
Anyway, I see the current set of financial data aggregators being fine for market validation for some type of applications, but they are too expensive to allow for wide-spread innovation.
The current aggregators are optimized for big businesses and venture backed startups. I used them to sell a startup to capital one, and I named other people doing the same.
You just need to think very long and very hard about your business model.
The way Plaid structures (structured?) their pricing is much friendlier than Yodlee in that there are no monthly minimums, setup costs, or term commitments. Simple volume based pricing is generally much more startup friendly, at least in the initial stages.
So people get around it by logging into the user's bank and scraping. Which is much less secure than just providing a secure api to begin with...
All good intentions have consequences.
For banking credentials, we generally must use reversible encryption for which we have special procedures and secure hardware kept in our secure and guarded datacenter. The decryption keys never leave the hardware device (which is built to destroy the key material if the tamper protection is attacked). This device will only decrypt after it is activated by a quorum of other keys, each of which is stored on a smartcard and also encrypted by a password known to only one person. Furthermore the device requires a time-limited cryptographically-signed permission token for each decryption. The system (which I designed and patented) also has facilities for secure remote auditing of each decryption.
I'm curious how they handle two factor authentication?
In the US I recommend you check out Plaid (https://plaid.com), although I believe they offer read only APIs.
There is also the Open Bank Project (https://openbankproject.com) which is also intended as a universal API but I don't believe has any production integrations, although they do have sandbox APIs.
Email address in profile if anyone wants to chat more about this topic.
It's called POSADA (personal open source automated digital assistant). It's a open source digital assistant. The primary use cases are financial (paying bills, transferring money, etc). It will open source and user hosted. People host their assistant on pre-loaded, plug and play raspberry pi 3s. Hopefully there will be a community of developers that will share integrations (ie, scraping scripts). So if I want my assistant to work with my local bank, I build an intergration and now anyone else that has the same bank can connect to it.
POSADA's logic will be programmable as well. So you can customize when it alerts you, requests confirmation, or automatically transfers money from one account to another to
pay a bill.
One of the use cases I'm most excited about is the ability of POSADA to make donations to organization and charities you care about. So rather than setting up an auto-pay thing with a 3rd party, you tell POSADA how much you want to give, how frequently, and can even adjust the amount based on an assessment of your current financial position. The user would be in total control and I hope that will encourage more people to financial support media outlets, open source projects, and other worthy causes on a regular, sustaining basis.
I've got a mobile app prototype that handles two factor authentication and will eventually grow to become the front end of the assistant. I'm currently leveraging the built in speech-to-text capabilities of android phone to allow the user to communicate with their assistant via voice.
Have you opened this up anywhere yet? I'm interested in using some of your ideas and/or contributing to them. :)
We are basically on the same page. POSADA's logic interface has a concept of a plan which is composed of plan actions.
Users will be able to build plans that get executed everyday. for example, you could tell POSADA check you bank account daily and make sure any outstanding checks or withdrawals are adequately funded. If not, you're plan could tell POSADA to try transferring from you savings or alerting you on mobile if it is unable to fund the withdrawal.
I'm currently using protractor (webdriver) for my crawler but I would open to switching to nightmare to be compatible with you as long as I am able to get that stack running on a pi.
EDIT: Yes, there are aggregators who have agreements with banks, but I believe the OP asked for directly accessing a bank's API, which I believe is not possible with the exception of some beta programs here and there that gives access to some non trivial bank data.
Either way, the internal incubators at leading banks - at least in NYC - are actually very promising. As parent said, almost every bank has agreements/internal APIs, but they are VERY VERY careful with who gets access. Primary issue, aside from privacy/compliance/PII is that transactional data can be mined so heavily for purchasing patterns and thus predicting revenue for publicly traded companies. In fact, there are a couple of startups trying to do exactly this that popped up recently.
US Bank's Elavon: https://developer.elavon.com/#/home/landing
Capital One: https://developer.capitalone.com
I envision a repository of integrations (ie, scripts for certain sites) so as people create integrations, you share them with the community. There's also a mobile app that allows users to get updates from the assistant, makes requests to it, or give confirmation before the assistant takes action.
However, you asked for american banks and i haven't seen options to get a sandboxed variant albeit i am sure these exist. Another option would be to open accounts at some Banks....
Other commenters point out that some US banks have shared some early APIs, but most are not for public consumption and are limited to "partners". I suspect we'll see some restrictions on API access for a while still while regulators and banks get comfortable with an API approach.
Citi has had a Mobile Challenge for a few years with some API test access (http://www.citimobilechallenge.com/), and the Open Bank Project has a sandbox (https://openbankproject.com/) for their version of banking APIs.
But for now, unless you want to leverage aggregators, I think you'll need to just keep reaching out to the banks to be included as a "partner" and try to get early access, or wait til they open broadly, and I wouldn't expect to see that til the next few years for most large banks.
I know in the UK the only production banking API is Teller .
Here's a list: https://wiki.gnucash.org/wiki/OFX_Direct_Connect_Bank_Settin...
Note that some banks (I think Bank of America is one) turn off this access by default on your account to prevent people being tricked into providing access but a quick call to them will get it enabled on your account.
I've recommended that every Bank I've done work for (which is quite a few) consider an external facing API to enable Lead User Behavior (see Von Hippel et al from MIT and MIT Press) and the concept has never gotten good air, for a variety of reasons which, no doubt, make sense to the their reference business models. Much of that can be explained be the theories of Disruptive Innovation (see Clay Christensen, et al, Harvard Business Press).
While I can't speak on this front, I think it's also acknowledged by anyone with a fully functioning brain stem that the various screen scraping solutions are sketchy for all concerned. There are some stable providers (Plaid seems pretty shiney and exciting. Fiserv and Yodalee have been around, and I'd only say that one of them seems yo have more clout than the other.
I think you'll see some exciting possibilities in the not too distant future, but I'd have trouble seeing a major Bank opening their doors to the public for all the reasons mentioned here. If the theories of disruptive innovation hold water, I'd say that once robust services come available that allow smart developers to apply modern thought to services, the disintermediation will be annoying to the big Banks if it strips away their best customers, which it's not likely to.
The problem (from the theory side) is a) there's not much money in providing a service, there's money in selling accounts, and that's where it's really hard for a small player to gain entry and b) in a battle where the incumbent is motivated to fight, that incumbent will likely win, and I personally don't want to fight with an incumbent who makes 5BB a quarter.
In the meantime...
Work at Dwolla. What us and others, like Plaid, have done is taken these partnerships, resources, compliance requirements, etc. and smashed them into endpoints, creating [hopefully] something you're looking for. Our White Label and co-branded APIs (https://developers.dwolla.com/). A quick list.
Create Bank Transfers - Yes
Know Your Customer Verification - Yes
Sandbox - Yes
Bank account verification - Yes
Webhooks - Yes
Oauth - Yes (Co-branded only)
Create Customer Records - Yes (White Label only)
Reach out to Spencer@Dwolla.com, if you think we can help to. (While we don't work directly with Plaid, we can be complimentary).
(By way of full disclosure, I work in Capital One's Open Source Office.)