Teller – API for your bank account
blog.teller.io
blog.teller.io
If some fraud was to come about as a result of someone using Teller then they would be out of pocket or has Teller got agreements with the compatible banks to overcome this situation (either by Teller reimbursing the customer or the bank)?
I can't even count how many promising-looking Fintech products I had to pass over because the only auth mechanism they offered was through sharing online banking credentials.
Until bank policies regarding credentials-sharing actually change, I think it's really irresponsible for products to even ask for credentials at all, let alone offer it as the default/only auth option. Users could be unwittingly putting their entire life savings at risk.
Is this a realistic concern? I thought the point of a bank was that situations like that can be reversed 100% of the time.
Depending on the scope of your accounts with the financial company that you're banking with it's possible that beyond your day-to-day operating funds and your mid-term savings accounts that you may also have access to your investments and other long-term stores of value. They aren't as liquid, and it would be harder for a thief to shift them into something that can be transferred out of your account, but it certainly is possible for it to happen if sales of stocks/bonds/etc. are conducted without your knowledge and then the funds are wired out.
I'm personally waiting for the PSD II law to be deployed (see https://blog.teller.io/2016/04/26/tauth.html) in order to have clear-cut protections & boundaries, before leveraging Bankin or similar (Teller) as a SaaS product builder.
Firstly, we don't always need a credential. Some banks provide other auth mechanisms, e.g. EMV CAP. We use this for Barclays and Nationwide. Using Teller might not violate your bank's terms of service, which is why we advise you to read them in conjunction with ours. Furthermore, it is the view of some senior bank people that I speak to that PSD2 will make such clauses in banking terms illegal. It is also worth mentioning there has never been a single case of fraud or loss attributed to "screen-scraping"
Secondly, we have ongoing dialogue open with every major UK bank at very senior levels, from C-level down. We want to help banks deliver these APIs. Formal agreements with banks are a key strategic objective for Teller, but they only started returning my calls once I'd broken their apps and took their APIs. The market can't wait for the banks, developers and users want new choices, apps and service now.
Whether or not there's 'been a single case of fraud or loss attributed to "screen-scraping"', I believe most banks are more than happy to blame you by default and make it difficult/expensive to resolve.
I'd like something like this, but I wouldn't want to give the bank details away.
Sure would take time and some effort, but would certainly return well for such an effort and as said, people would appreciate that greatly, so can only help you and your business.
That said, I don't think the business model on display here is tenable at all and I don't think it will be successful. I certainly wouldn't sign on for this, way too risky.
I can totally understand the motivation (particularly with PSD2 around the corner, which will mandate banks to provide legit APIs - I'm guessing the plan is to grab market share before that happens). However, I am very skeptical of this approach when applied to finance. Any technical product whose risk profile is "break into us and steal money directly" is a really dangerous place to leave your users on the hook for liability.
It's also highly probable that it has happened, it just wasn't attributed properly.
I think it's likely one of these screen-scraping sites that store bank passwords has been breached, and any losses as a result have simply not been attributed to it.
I say this having experience in infosec and seeing how comically little companies who should care about security actually do. Often there's not even a single person with infosec experience. And they make every mistake you'd passively learn not to by casually reading HN comments.
That's not to say some companies don't get it right. Some (including my current employer) do an extraordinary job. But even teams with solid infosec staff get broken in to. The odds that a site storing large numbers of bank passwords with only a handful of engineers not getting popped sooner rather than later is slim.
Well... no thanks. I (and likely many others) would only consider using such a service if I had a guarantee, both from you and my bank, up front.
from your ToS:
>"We are not liable for any loss or damage that may result from your use of our services. This includes any direct, indirect, or consequential losses; any loss or damage caused by tort, including negligence, breach of contract or otherwise."
Oh geez.
There's a reason every investment-related advert has to state that "The value of your investment may go down as well as up", etc.
I'm not sure that's the case; I thought the FCA were pretty clear one intent of PSD2 is to stop the need for screen scraping.[1]
Have you had any dialogue with OpenBanking UK etc. about their strategy on API driven interactions?
1. https://www.out-law.com/en/articles/2017/february/screen-scr...
This response makes me angry. Every service worth attacking will have security problems at some point. You're running a store of bank credentials, which you have to have access to (as opposed to password managers for example which can store user encrypted data). Given enough time, one of these services will get hacked and "this has never happened before" is not going to be a good answer. Someone will be the first one.
I'm happy your service will push more banks to provide APIs. But I'm already doing bank screen scraping for myself because I don't trust services which require my credentials. I hope people consider that risk seriously.
In short, that service is run out of private datacenters, not publicly available. You'd have to compromise not just Mint/TurboTax/QuickBooks but then the FICDS service, which only has methods that take a token representing the credentials and passes back transactions, not the actual credentials.
It's the competitors to Mint who can't afford their own datacenters and don't have the many millions of dollars to put into securing their service the way Intuit does that should be much more worrisome.
Disclaimer: I used to work at Intuit, though not on any of the products I mentioned. But I have had many conversations with the people that run Mint and FICDS and I know the overall architecture used. I give my bank credentials to Mint without any worry. It would probably require a state-level entity to get in, and they'd likely need to get someone hired into that group to facilitate it. The service is very secure.
With that said, security is taken very seriously and most of the stuff I experienced was UI related. So hard to say...
FICDS, on the other hand, was spun up more recently and is in much better shape. I wouldn't look at an application like QBO and see much that would inform a behind the scenes service like FICDS.
The more interesting product, to me, is TurboTax. The seasonality of it allows Intuit to basically rebuild it from the ground up every year. It's really a different mindset on the San Diego campus (where TT is developed) and in Mountain View (where QBO is developed). San Diego is much more willing to take (non-security) risks with the product because small changes can add up to big wins. I remember a talk by one of the guys in charge of A/B testing on TT who said that a tenth of a percentage point increase in conversion rate was good for tens of millions in added profit.
Contrast that with QuickBooks, where the difficulty to use is actually a feature. Accountants spend years learning the app and learning the work arounds for those bugs you mentioned. That knowledge and experience becomes a barrier to entry into the field and a job skill that they're compensated for. The result is that QB/QBO is aimed at accountants with years of experience in the product. Their livelihood depends on it and they don't like change. So the teams there do as little as possible that can cause problems and know that they'll still get good reviews if the get almost nothing done so long as they don't cause problems.
It's deeply disfunctional and yet explains why you can put a lot of trust in FICDS. They too have had bugs for years. For example, they don't save cookies between scraping sessions and so are always an untrusted browser to the banks. I have at least two accounts that constantly send me 2FA tokens whenever Mint tries (and fails) to sync. But no one gets fired for not fixing bugs. You get fired for compromising the security or stability of the service, and the easiest way to not do that is to push as little possibly vulnerable code to prod. It's the anti-Zuckerberg environment...move slow and don't break things.
Ha, actually, one more - the only way to change the date format in invoices (from mm/dd/yy to YYYY-mm-dd for instance) is to change the overall Windows OS setting. That's crazy enough, but what's worse is, when you do that, it screws up the dates of many pre-existing, closed transactions in your company files. Fortunately in my case (iirc) it reset those dates way in the future, so I was able to find and fix them manually. But I mean, seriously...
My favorite WTF for QBD: The data upload was literally just using the replication feature of the embedded Sybase database. One of the Distinguished Engineers that I worked with, "I worked on that feature and I probably know more about how it works than anyone and I can't get it to work reliably.
So, does this mean QBD is basically the living dead, and inevitably I'll have to find an alternative? It looks like everyone's doing online these days.. :/
Edit: Yeah, looks like it doesn't have inventory tracking. Conflicting reports on multi-currency support too.
Looks like Xero might be a viable option though.
That was the impression I got when I was there. They're putting a ton of effort into getting people to migrate. But there's still a ton of die-hards that won't and they were continually having to push back their sunsetting plans. I've been gone more than a year now, so I can't say what the current situation is.
It sounds like you're a lot more familiar with the long-tail features of QuickBooks, so I may be recommending something that's missing a lot of what you need, but my favorite competitor product was Wave. They seemed to be the only one that was actually trying to make an intuitive product that wasn't unpleasant to use. It's online though and I don't really know much about the desktop alternatives, so if you're set on running on-prem software, it won't work for you. The accounting stuff is free, though, if you want to play with it.
But Xero is also online only, right? I was pretty negative on them, considering they basically started from scratch in an era where the result should have been much better than Quickbooks considering it didn't have all the baggage that Quickbooks has to deal with. And yet they came up with something that's arguably just as frustrating to use.
Financial Institution something something Service. It's the internal initialism name for the service that communicates with financial institutions on behalf of the applications that need to pull transactions and other information.
> What does it mean "quickbooks online is decades old"?
The project was started in the late 90s. It's as messy a codebase as you'd expect to find when you've got close to 20 years of commits.
My latest version (Quicken 2016) literally takes seconds to tab between fields and often does not keep a correct tally balance until I close the check register view. I only have a year of data in it (I thought the slowness might have been due to importing my old data so I restarted fresh).
Since I've been getting bombarded with upgrade ads that I can't seem to disable each time I start Quicken I'm thinking of moving to another app like Moneydance. It feel like an end of an era.
Second, even before it was sold, it was like Intuit's vestigial tail. It was an important part of the evolution of the company, but it didn't fit into what Intuit was trying to do and was largely ignored inside the company. Even before they announced plans to sell it, it felt like the kitchen table they keep at headquarters...something that's there to remind people of Intuit's past but feels really out of place with its present.
That being said, if you run all your spending through your credit cards except obvious notables you update manually you are golden. (i.e. Rent/Mortgage)
From http://blog.precipice.org/why-wesabe-lost-to-mint/
Wesabe built our own data acquisition system, first
using downloadable client programs (partially because
that was easier and partially to preserve users’
privacy)Any tools you recommend, or is it all hand-rolled?
Using minimal standard screen scraping will be hard because most bank apps are a complicated mess of client and server side processing using ancient tech. After many tries, I just used python+chromedriver and that's doable in ~100 loc per bank.
CSV statements because OFX and others are a complete mess in most cases. I haven't seen a single compliant and correct file so far. (This may be AU specific)
Own database / spreadsheet so you have a local copy you can easily filter on. Obtaining specific date range from a bank may be an interesting challenge. I default to importing last 30 days every day with duplicates detected using a hash(date-description-amount-idx) where idx increases for every date-desc-amount duplicate.
So far I'm happy. Actually I'm in the process of writing a post about it - will submit sometime next week most likely.
I wrote it as I just spend too much time digging out passwords all the time and the usual crowd like LastPass are a) stored online and b) fail to login automatically to complex input sequences like banks.
Saying "it's never happened before" doesn't in anyway mitigate the attack vector. For what it's worth, there have been cases of fraud attributed to screen scraping, but they don't tend to get publicized.
It is pretty telling (no pun intended) that nowhere in your blog post does the word "security" appear, and no details about how you're storing credentials when you do need them. Why should I trust you with a credential from another party if you refuse to tell me how you're actually storing it.
> "We are not liable for any loss or damage that may result from your use of our services. This includes any direct, indirect, or consequential losses; any loss or damage caused by tort, including negligence, breach of contract or otherwise. This applies if the loss or damage was foreseeable, arose in the normal course of things or you advised us that it might happen."
I don't know which solicitor gave you those terms, but they will be laughed out of a court in England as unconscionable. You're not liable for any negligence, even if it's foreseeable or someone told you you were being negligent??
If that is close to explicitly as you have stated then either 1) The senior bank people you talked to are lying to you 2) the senior bank people you talked to really don't know anything about PSD2 3) They mistated to you how PSD2 changes will affect this 4) You misunderstood what they mentioned about PSD2 changes.
If a bank mentions in its clauses as per PSD2, that only authorized persons/firms are use an API and their acccess, they are authorized to negate any liability if it was given/accessed by an unauthorized party. Banks are required to make API's available (not same as accessible) to any SaaS or other developer as long as it is authorized by the bank.
Rather than relying on hearsay or in conversation on crucial regulatory changes , might I suggest this: https://www.createspace.com/5772402
Authorized in this context means that the third party obtained an authorization from their local financial authorities, and that the authorization is for the type of service they are requesting (Payment Initiation or Account Information).
While it may be true that there hasn't been historical fraud attributed to "screen-scraping", what has been seen historically is insider fraud - you pretty much have to expect a certain rate of incidents where your own employees, included tenured ones in high trust positions, will intentionally risk jail time and attempt to steal money; in the finance industry (despite all reasonable precautions) it's not a question of if it will happen, it's a question of how often it'll happen (i.e. if it's 1 incident per annum per 100 employees or if it's 1 incident per annum per 1000 employees), how large will be the impact (most precautions don't prevent the risk as such, but limit the amounts involved), and what are you going to do about it.
E.g. the idea that your main technical administrator might sell a database of stored credentials to organized crime; (or get his/her family kidnapped in order to get access to them, that has happened as well) isn't ridiculous fiction, it's a rare but feasible scenario that's more likely to happen than e.g. a datacenter burning down, so what you're going to do in similar cases is quite relevant, not only to your own internal risk analysis but also to your customers. A bank might say "oh, we've got it covered, but if a major hack-event happens, our capital reserves and deposit insurance will still guarantee that you don't lose your savings" - an API company can't fall back on that.
...how do you know?
I think it is likely there has been fraud like that though. It just doesn't get reported or even found out.
It was my understanding that the YC-backed company Standard Treasury (acquired by Silicon Valley Bank in 2015) was trying to do this. I don't know where they went with this or what happened (although I believe there was techcrunch write-up about them and the purchase by SVB). Hopefully you can make this work securely because having to navigate a shitty branded (which apparently means constantly changing) web interface to monitor and move money is increasingly frustrating.
We are building a better front-end for any bank on top of Teller (or any other banking API) - http://bixtr.com.
I have some friends who use SVB but they all agree on needing a a much better front-end experience - so would like to help them.
So be careful and if you want to have more insight into your finance maybe it's better to digest those apis yourself, libraries should pop out soon if they are not yet available for your bank (in europe anyway).
If not, then I think there's still some utility in a service that can normalize that stuff and provide you with a single, consistent interface.
There are however some inititives for open API standards that might be accepted by a majority of the banks.
That's obviously and opportunity for Teller, Figo.io and other players, they can perform legit aggregation just swapping out their scraping for bona fide API access.
But the situation is more complex... even banks can become aggregators for other banks if their customers want... These are interesting times.
100% coverage might be quite time consuming, but getting most the market is not going to be excessively hard.
There definitely seems to be a trend for more and more proprietary protocols instead of standards.
And we all know that any kind of regulatory action is anti-freedom and job-killing so I wouldn't expect any regulation to happen.
However, the whole concept of something like Mint is really read-only access, and I wish that site-specific passphrase had that as well.
I'm guessing the benefit to banks is lower fees or perhaps even monetization through transaction data sharing with Visa?
This of course breaks Interac features like Interac online.
Last time I opened a bank account and got a co-badged Interac card I immediately asked them if I could get an "Interac Only" card. At first they had no idea what I was talking about, but a few phone calls to head office later, and they were able to re-issue new debit cards without the Visa co-badge. Interac online works, and I feel better not sharing purchase data with Visa.
The non-machine-readable german-language-only API specification consist of >800 pages spread across various PDFs[1] full of gibberish. There are no official client libraries, no minimal examples, different banks only support certain versions etc. etc. etc.
[1]
https://www.hbci-zka.de/dokumente/spezifikation_deutsch/fint...
https://www.hbci-zka.de/dokumente/spezifikation_deutsch/fint...
https://www.hbci-zka.de/dokumente/spezifikation_deutsch/FinT...
https://www.hbci-zka.de/dokumente/spezifikation_deutsch/fint...
Besides, that does not explain, why none of the other banks can get their act together. If FinTS is too difficult to implement, how come they are not offering something simpler?
Your conflation of "bad" with "enterprisey" is unfortunate. Also, is it really adoption if different banks only support specific features/versions?
> If FinTS is too difficult to implement, how come they are not offering something simpler?
Well banks aren't really in the business of APIs, are they? Nobody is graduating #2 in their class at Stanford with a CS degree and going to work for a bank as a web developer.
The issue of incentive boils down to the fact that business clients, being the main source of revenue for retail banks, simply aren't making enough noise about their desire for APIs.
Sounds just like any other API, from most REST APIs to messengers.
HBCI is a lot better designed, and a lot easier to work with than the many different messengers that exist on phones nowadays. Everything is documented, everything is specified, and you have a stable API. Try getting something like this for Facebook Messenger, Allo, Duo, WhatsApp, Signal, Riot, all at once.
HBCI is bad, but it's a rare gem. Usually, when many major corporations have similar products, they try to prevent any such APIs from being created at all.
> non-machine-readable
I'm not sure I've seen any major API that's machine readable. Most major APIs don't have any machine-readable specifications publicly available. They probably have them internally, but almost never publicly.
> german-language-only
That's not really an issue, if you're in Germany. I don't go into the US and expect their banks to provide their specifications in English either. I realize that English has become the lingua franca in IT, but that's not a good thing.
Ah the horror. Last week it was bleating that German laws are written in German, this week it's bleating that German bank documentation is written in German.
The software I use at work is developed by a German-speaking team based on German documentation. I think the code is mostly English although they often use German identifiers when there is no straightforward translation[0]. It's highly specific to the German legal environment and of absolutely no use abroad anyway. Translating everything twice just introduces more errors.
And even in huge codebases such as SAP, most comments are still German.
Yes, modern codebases are often written in english, but that’s not everywhere.
Swiss Federal Government provides english translation of documents. https://www.admin.ch/opc/en/classified-compilation/19920153/...
It's not legally binding, but for education and information purposes works great.
Privacy policy and terms are linked to from https://teller.io/developer/beta
Privacy policy: https://teller.io/developer/privacy
Terms: https://teller.io/developer/terms
Payments APIs will be signed by the developer's private key (See more about that our auth scheme here https://blog.teller.io/2016/04/26/tauth.html) and transactional APIs will use idempotency tokens to prevent double processing.
This is not a scheme to sell anything to advertisers, it's a scheme to improve the quality of financial services for the highest number of people by providing developers with API access to bank accounts that banks should have provided themselves long ago!
"We are not liable for any loss or damage that may result from your use of our services. This includes any direct, indirect, or consequential losses; any loss or damage caused by tort, including negligence, breach of contract or otherwise."
You don't get taken seriously in the financial space with terms like that. You need to accept responsibility for errors and carry errors and omissions insurance.
Compare Bank of America Bill Pay service terms:
When you make a bill payment using Online or Mobile Banking you can be confident that it will be processed correctly. In the unlikely event that we fail to process your payment in accordance to the payee, amount and date you specified, Bank of America will reimburse you for any late-payment-related charges incurred.
We are committed to keeping your financial information safe and making sure you can bank with us securely, which is why you are not liable for fraudulent transfers or bill pay transactions made via online or mobile when they are reported promptly.[1]
[1] https://www.bankofamerica.com/onlinebanking/online-banking-s...
-- http://www.newyorker.com/magazine/2015/05/18/tomorrows-advan...
Our terms are comparable to the incumbent "screen-scrapers" in the market, e.g. Yodlee and Plaid. FWIW it is not currently possible for users to move money with Teller. I'm open to revisiting the terms when it is, and I'm always open and listening to feedback such as this.
Thanks for taking the time.
Right now I pay for several online services, a gym membership, insurance, a student loan, a mortgage, and an auto loan. Every one of these companies has authorization to pull money from my account each month. They all pay their payment processor a significant sum of money in exchange for the processor running the payments and shouldering the risk of the bank not honoring them.
With an API, I could stop relying on this "pull" model and start using a "push" model instead. Companies get my money only when I explicitly send it to them. I could schedule a payment to go out every month for services I want instead of allowing arbitrary vendors to charge my card (banks do have a partial stab at this in the form of bill-pay, but it tends to be pretty bad).
Presumably since the risk of fraud is lower since I authorized the payment with my RSA key, merchants could pay lower fees to their payment processors.
Now, I'm a little atypical, because I know how to program so I could use the API without help. But I know many people who would certainly take advantages of services built on top of an API like this.
Think of all the people in your life who have accidentally continued paying for something they no longer wanted due to the vendor "mistakenly" continuing to charge their card. Or scummy negative-option marketing companies which loudly tout a free product or service and then continue to charge your card thanks to some tiny section in their terms of service.
The possibilities get better too. You could have budgeting apps that don't let you spend more than $X per month for video games, but still allow you to buy groceries. You could give your children an authorized card with a per-month maximum but still allow them to pay for an Uber home if it's after 9 pm.
I really think this sort of thing would be a massive boon to people and society, and it's unfortunate that banks (in America) are fighting so hard to prevent it.
Respectfully, your users don't care about technical security if you get compromised - they care about their financial security. Please do reconsider your stance on liability, I found myself wincing while reading that disclaimer.
It pains me to say it as a techie but insurance is more important than security in this case. It'd be great if you were iron clad against all hacks ever but it'd sit more easily if there was insurance backing it up. What if you get a rogue employee dumping out all the credentials for example, not all attacks come from outside.
If you don't trust your security enough to assume liability, why should your users?
> FWIW it is not currently possible for users to move money with Teller
I don't believe it's so much a compromised service or API that's concerning, it's your credential storage. The data you hold does allow users to move money if compromised.
Having picked fault with your service enough, it does look like a great service and I'd love to use it one day. Best of luck!
I'm really surprised.
> the lawyers told us to stay clear (huge greyzone)
I remember going in to speak with your lawyers, convincing them, you emailing me the same day telling me as much and still wanting to do a deal.
> Stevie was elusive on pricing. I finally asked, "Look, if we paid you $1M, how many banks could we get?" He said one.
If you then thought I was going to give you, a competitor, my core IP for 1 million dollars a year, while you used it with your series A money to capture the market, well then you must be out of your damn mind.
> the banks themselves didn't want to engage with us using teller even if it sped up development time
Banks don't want to engage with you period. Nobody has heard of Token, you have zero technology and zero bank integrations.
Best of luck with it all, Steve.
I remember going in to speak with your lawyers, convincing them, you emailing me the same day telling me as much and still wanting to do a deal. At least one of you should have these emails.
If you then thought I was going to give you, a competitor, my core IP for 1 million dollars a year, while you used it with your series A money to capture the market, well then you must be out of your damn mind. You would have been paid $1m/year to provide a service. You wouldn't have given up ownership of your company, or taken a risk on stock valuations. $1m cash. Each year. Actual cash. For a startup of 1. If you don't think that's good money right out of the gate, you have serious judgment issues (and this is also reflected in your top-floating comment re security).
Nobody has heard of Token, you have zero technology and zero bank integrations. This was the first time I've heard of Teller...If Token claims they have bank customers that they're providing integration for, it's an easy matter for them to prove it; they only need to publicize one bank client to refute your claims. On the other hand, you come across as very petulant when you say nobody has heard of Token and that they have zero technology or bank integrations since that's an easily disprovable claim.
FinTech and financial services place a lot of value in judgment, since their industry is defined by risk. Right now, you're not showing much good judgment, and if you keep up like this, you have no chance in this space because you're demonstrating in many ways that you're a bad risk for them to take.
> Nets is split up in two divisions: Nets, which manages the Danish market, and Teller, which handles all international markets. This means that Nets processes all Dankort transactions, while Teller processes all transactions by international cards.
http://www.epay.eu/acquirer-internet/nets-teller.asp
https://www.nets.eu/en/payments/
http://netseu.23video.com/secret/12342399/64f0568391b3ebaa58...
There were a bunch of questions about Plaid and the difference. The obvious one is that Teller is UK only and supports the top couple banks, Plaid is US only and supports thousands of financial institutions. If you need both UK and US coverage - since we both have pretty developer friendly APIs - it seems like a nice combo! Steve/Teller have also taken a bit of an antagonistic approach and has not worked with the banks - time will see if this proves successful, but we've taken the approach to work directly with the banks (as investors, clients, data-partners etc.).
Hope that helps and if you have any other questions/comments feel free to shoot me an email at william [at] plaid.com
> Plaid... supports thousands of financial institutions.
While this is technically correct, I feel this is a little disingenuous. In the UK we have a far concentrated banking industry, at least in retail banking, in that the vast majority (I'd guess >99%) of current accounts or similar are held with maybe 6-7 well known high-street banks. We also do not yet have a shared banking API format.
In the US, there are a very large number of smaller credit unions, and many banks/credit unions support the same API format (that I believe Mint.com etc use), and have done for a long time.
So I feel this is disingenuous because a) there are fewer banks to integrate with in the UK, and b) the game of integrations here is much tougher.
Citation needed. Clearly you have a competing product. I'm surprised to see you using HN to throw shade at a competitor without context.
I like the idea, but i would never use this as a service on the internet.
I really wish someone would come out with an API service targeted towards someone who would like to manage and query their portfolio of accounts with code. I have tried time and time again to use things like Mint or Quicken to have a consolidated view of my accounts, but invariably I find things that really suck about the service. I'd rather hack together a set of scripts and do it that way, but where to go for the actual access (aside from manually downloading .obx files).
Plaid was fine with creating a developer account for just a few bank accounts, they didn't have any minimum or anything.
One thing I ran into quickly when parsing my own bank's OFX was the truncation of the payee field, which made it extremely difficult to identify certain transactions. For example, I might get coffee at a Starbucks, but it would show up in the bank export as "STORE93423 CA LA STAR". I never determined if this was a limitation of the bank's software or simply that OFX didn't allow for enough characters. It'll be interesting to see if Plaid solves this.
Now that's an intro!
We have ideal for payments (https://www.ideal.nl/en/payment-service-providers/) and every bank has its mobile app that is integrating via ideal. So all payments on my phone the app just pops up, I do a finger scan and done. All apps are very decent for all normal banking business. I can't think of any use case I would need to trust a third party with my credentials.
Simple example: I want to build a arbitrage trading bot that can automatically request my bank to wire money to some address so I can have my funds on an exchange topped up. That's not gonna be possible without an API.
If there was an API I could use to get these details, it would be so much more convenient. Could even build a product around it.
At this point I'd take the enterprisey German API over nothing.
I'd love our government or the EU stepping in.
Either they or I don't understand what long tail means.
E.g. 80% of revenue coming from 1,000 customers. 20% of revenue coming from 100,000 customers
or
20% of revenue coming from 1,000 customers. 80% revenue coming from 100,000 customers.
The latter is more fat-tailed.
Things are starting to not-entirely-suck in retail banking land. (in Europe, at least - not sure about elsewhere)
Teller is not a bank itself though. I believe it started as a wrapper around banks' private APIs, not sure whether that's still the case.
That might change later this year when they roll out current accounts but for now it's just simple prepaid/travel debit card with mobile app.
Also not sure they have switched from WireCard yet? Last time I heard they have not switched all of their existing users to their own platform but perhaps they managed the transition already?
Banks benefit from certain bugs/holes in their software (e.g. shitty UI for viewing transaction history/balance -> more overdrafts -> more fees).
With copyright, why create something new when you can just sue somebody?
First is that copyright applies to written content (even short content such as tweets) and does not apply to factual data.
Second is that whatever rights may apply to the data, in the fintech scenario the users are scraping their own data.
So all kinds of copyright-specific laws, of which there are many, don't really apply in this case - and those are the laws that can easily get used against the service provider, unlike the possible ToS violation where the bank would have to against their own customers to enforce it.
That's the trick, they just put all the liability on the user for security issues. Most banks say you must never give your credentials to a third party
So these startups and fin-tech companies just slap a few clauses in their T&Cs to say it's the users problem, not theirs.
The US is a long ways away from having this.
This is the case for Barclays, for example, where in fact once the mobile app is registered, that can be used as a Pinsentry (2FA) device replacement.
Reverse engineering mobile APIs is a superior strategy to screen-scraping because:
- they already return structured data
- the security model for that channel is different, e.g. no need for 2FA all the time so truly unattended use cases are possible
- it's much more difficult for banks to make breaking changes. When banks do make a breaking change the old version is supported for a decent amount of time to allow their own banking app users to upgrade, we can take advantage of this window to provide a consistent level of service.
Finally, we often don't need user credentials. If there is an option to authenticate with another mechanism during registration, e.g. EMV CAP (A.K.A Barclays PINSentry etc) we use that.
Unless they have relationships with the banks now, and would be given a heads-up. Perhaps that's the case. It sounds like it may be.
Yes you can, and banks already do this. Even the E-Trade app refuses to work unless it's on the most current version. When you control the apps and the API, you can pretty much do as you please.
In other words, many of the big banks have such a dysfunctional relationship to internet banking that customers of many of them have learned to deal with not being able to use the apps for long periods of time - it's hard to imagine that a third party will be perceptibly worse.
Not to mention, once they discover what changed, now this service has to go make the changes on their system... meanwhile that bank doesn't work with this service anymore.
So the App is broken for some undefined period of time.
"All" of their client code is a bunch of apps, that mostly auto-update. My bank (small town credit union) has a banking app that refuses to work at all unless it's the most recent version of the App. I see no reason why this would be a challenge for the bank - it's only a challenge for this service.
Also, will your reverse-engineered use of the mobile API's have any detrimental effect on the user? I imagine the user will be the one authenticated with the API, what if the bank starts to see an influx of odd API traffic and decides to investigate it or there is some type of rate limit?
Your decision to reverse-engineer mobile API's opens the door for many important questions in my opinion.
In terms of stability. It actually takes 6-12 months for a bank to get something into production. We are not talking about fast moving organisations here. We have not had a breakage with a supported integration in two years of beta testing.
We take many steps to ensure our traffic does not stand out to banks eager to actively interfere with Teller. Our clients perfectly emulate (100% API compatibility with their own) and make the same API calls in the same order etc. We also only make API calls as a result of user action, i.e. Teller does not poll or cause atypical traffic patterns. Finally have 100s of IP addresses and assign an IP address to a user for a period of time. All of this compounds to make Teller traffic look indistinguishable from their own mobile app traffic. The objective is to make it more likely they will block their own app traffic than block Teller as a string incentive to not interfere their customers' choice to use Teller enabled services.
I hope banks will realise that open APIs are a good thing, and if they don't start getting their shit together, they'll be left behind. Our whole financial infrastructure is so needlessly complicated. Why can't it all be JSON APIs?
Even back then you had caught the attention of banks. I'm sure they've threatened you many times. But now that banks are taking you more seriously and returning your calls, how are you going to convince them to work with you instead of against you?
And what happens when, if they haven't begun already, try and legally DoS you?
This is so insanely risky...
It seems to be that any service that consumes private APIs is going to be inherently unstable, although I agree on the slow pace of work in the finance world.
Also, once they figure out your consuming their APIs there will be an arms race and possibly legal action.
For comparison: I've been unable to use Barclays own mobile app for about half of the last 4 years in chunks because their app seems to whitelist phones as they decide it's worth it. On a relatively random subset of my phones over the last 4 years, it just shuts down. No error, no nothing. Their support insists nothing is wrong. Nobody at Barclays appears to give a shit that they lock customers out. The Play store is full of thousands of one star reviews from people affected. My current phone took 6 months before it suddenly started working.
In other words: If you bank with Barclays, either you accept that you'll need to have a pinsentry device on standby when you get a new phone, or you'll stand a good chance of being unable to use their service for months on end.
When I signed up for Xero for my business account, I had to provide them with a document that they had to fax to Barclays to get them to pass on transaction info. It took about 10 days to get it enabled. If only I could get my personal statements electronically as easily (maybe Teller can finally solve that).
The banks have made sure peoples expectations of them is so low that any third party service that's remotely transparent is likely to find customers are very tolerant of bank problems.
I mean, the only reason I'm still with Barclays given the above is that most of the alternatives are shitty too, and I have locked in a mortgage rate with them that I "can't afford" to give up as long as the Bank of England rate is as low as it is (tracker rate that means I pay well below inflation).
What happens if the banks realize you're doing this and just block your IPs? What happens if they decide to go after you legally because you reverse engineered their applications and are benefiting from it commercially - you'd have a decent argument, but are you prepared to go to court with it?
Then again I guess the screen scrapers have gotten away with it for a fairly long amount of time, so maybe it's not a concern...
It was my understanding back then that even when Teller does more advanced authentication with the bank, eg EMV CAP, that that does still grant them the rights to move money, even though Teller doesn't yet support it.
To me that paints a big target on Teller's back - all those juicy downstream credentials.
sjtgraham's point was that setting up new payees typically (always?) requires additional authentication. But I can think of a number of scenarios where a hacker might send all my money to all my existing payees just to mess with me/Teller/my bank... causing fees and stress.
Obviously it's going down the route that Teller won't need your full credentials, you will grant them access via something like EMV CAP, which I applaud.
But I would call on Teller to publicly commit to not integrate more 'advanced' auth methods if they don't include the ability to grant read-only access, if the user wishes!
PSD2 explained: https://transferwise.com/gb/blog/what-is-psd2
Everything else would be very naiv.
Asking for credentials is no go whatever the bank is. There are ways to get some feeds even now but that requires signing some papers. Besides, I don't want to shoot down the service because this is genuinely a useful service (if it wasn't for the scrapping) but the best way to solve this problem is for banks to implement their own APIs with proper access controls that make sense in the context of the bank and the account.
I notice that National Australia Bank is experimenting with APIs, they have a developer portal [1], with FX rates and branch location APIs currently available. Authentication, customer details and accounts APIs are 'coming soon'.
https://community.commbank.com.au/t5/NetBank/API-access/td-p...
However, the response is not really understood by those answering the question.
There was talk of them being required by ligislation to have an api by July 2018, but not sure what the progress of that is.
https://www.itnews.com.au/news/australian-banks-told-to-buil...
What will the fees be on sending/receiving money?
Scraping data from your own bank account seems rather uninteresting to me. I assume sending/transferring is limited to domestic banks. Is this the case?
You should make it open source (to grow your bank catalog by the community) with some premium Plan (to earn money of it)
That's the only way to get it worldwide, otherwise, you will have to do MITM attack every single Bank App in order to get their APIs, with is painful and most of the times impossible without valid credentials.
Opensource + Premium is the way to go!
https://github.com/bankscrap/bankscrap
We already support major banks in Spain and we're looking forward for people who can contribute with adapters to support even more banks worldwide.
More info here: https://atrium.mx.com/home
NOTE: I saw a few people mentioning Plaid and Quovo so I thought it would be appropriate to mention our product.
Is your product still going to be on the open market in 6 months time?
We do add as many data sources as possible. We can use Morningstar for example to find cusip of holdings data. We're always trying to improve too :).
Cool… keep on trucking! :)
BTW, I don't suppose you have Australian/NZ support?
We are not liable for any loss or damage that may result from your use of our services. This includes any direct, indirect, or consequential losses; any loss or damage caused by tort, including negligence, breach of contract or otherwise.
This applies if the loss or damage was foreseeable, arose in the normal course of things or you advised us that it might happen.
This includes but is not limited to loss of your income or revenue; salary, benefits, or other payments; business; profits or contracts; opportunity; anticipated savings; data; goodwill or reputation; intangible and tangible property; wasted management or office time.
No, none.
Will have to pass on it for now. Good to see a lot of growth in the FinTech industry though, with banks like Monzo popping up and all these smart investment sites like Nutmeg.
It is UK only.
"Teller is available today for Santander UK, Barclays, Natwest, Nationwide, RBS, Isle of Man Bank, and Ulster Bank."
You need legally available reverse engineering without dmca-hammer to be applied plus PSD2 directive coming soon forcing banks to open.
Those are EU things.
So how about No?