
Teller – API for your bank account - ldn_tech_exec1
https://blog.teller.io/2017/06/12/the-api-for-your-bank-account-is-here.html
======
alexbilbie
UK banks don't accept any liability if you give your online banking
credentials to a third party.

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)?

~~~
sjtgraham
Hi,

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.

~~~
viraptor
> It is also worth mentioning there has never been a single case of fraud or
> loss attributed to "screen-scraping"

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.

~~~
djsumdog
This is what always worried me about services like Mint.

~~~
curun1r
Mint is probably the one you don't have to worry about. The service that
stores credentials and scrapes bank sites is the same one that powers TurboTax
and QuickBooks. Intuit spends a lot of money keeping that service secure and
they're well aware of how catastrophic a breech would be.

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.

~~~
tempestn
I don't know, if the general level of bug-ridden-ness of their products is any
indication, I wouldn't put much stock in their security. There are glaring
bugs in Quickbooks for example that persist year after year, having been
reported repeatedly, even as they continue to release a new version every
single year with various visual tweaks and seemingly not much else.

~~~
curun1r
QuickBooks, even the online version, are decades old and have major issues
that prevent the teams from getting much done. They took a year to do clean-up
and basically didn't introduce any new features. Not much got done just due to
the complexity of changing anything without causing problems.

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.

~~~
tempestn
I suppose you could have a point about the fact that (good) accountants know
the work-arounds. And many of the bugs are annoyances and UI things rather
than critical stuff. There are some that will really bite you (meaning, result
in incorrect accounting) if you're not familiar with them. For example, the
home currency adjustment in the multi-currency mode skips accounts with a
current balance of 0 in foreign currency, even if the balance in home currency
is non-zero, and so an adjustment is needed. If you know that, you can go in
and do those ones manually (although it's a PITA), but if you don't, your
taxes will be off. That seems like something that should not be allowed to
persist in accounting software. It's the most glaring example I can think of,
but there are others.

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...

~~~
curun1r
Heh...you're talking QBD. That's the true dysfunction of Intuit. It's the
product Intuit doesn't want you to use. They want customers to transition to
QBO and only "maintain" Desktop because many customers refuse to "upgrade" to
Online. I never met a single employee who was currently working on QBD. A
product that accounts for more that 1/4 of their revenue and they had
literally no engineers participating in company events, or at least disclosing
what product they worked on. Hell, I met the entire Quicken for Mac team at
one point.

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.

~~~
tempestn
Yeah, I don't love the idea of trying to run accounting software in a browser;
doesn't seem like it could possibly have the performance of a desktop app.
Also, last I checked, QBD includes features I use that QBO doesn't. I can't
recall what they were though, so that may no longer be the case.

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.

~~~
curun1r
> So, does this mean QBD is basically the living dead

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.

~~~
tempestn
Yeah, Xero is online too. It was just the only one that appeared to check all
the boxes I need. (Most were missing one of payroll, inventory management, or
multi-currency support.)

------
mirekrusin
Somebody told me that 2018 is the deadline for EU banks to provide API access.
If that's the case then going through any server side layer managed by
somebody is unnecessary and people in general should think twice about every
single bank transaction being stored somewhere "there". It gives out a lot of
information from your internet provider to your child's creche, holidays
habits, income (duh), loan repayments and whether you like on mondays this new
sandwich at pret a manger with a coffee for take-away or eat-in - can be
inferred as well.

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).

~~~
kevincennis
Are they required to adhere to a standardized API?

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.

~~~
DerJacques
My understanding is that the EU PSD2 regulation indeed is supposed to make
banks adhere to a standardised API. That being said, I wouldn't expect a super
easy to use REST api with documentation powered by readme.io.

~~~
hobofan
If you read the legislation (?) you will see that they are actually very vague
in how the banks will provide access. I think it is already a great success
that they (fingers crossed) will manage to force the banks to provide access
to the data in any form and gave them little wiggle room for justifications to
get out of it.

There are however some inititives for open API standards that might be
accepted by a majority of the banks.

------
foxylion
As a German it is hard to believe that such things do not exist yet in other
countries. We have a standardized protocol called FinTS which is implemented
by most banks. This results in a huge amount of desktop and mobile
applications for banking.

~~~
sparkling
FinTS (formerly known as HBCI) is horrible and serves as a great example of
how not to design a API.

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/fintsv4/FinTS_4.1_Formals_2014-01-20_FV.pdf)

[https://www.hbci-
zka.de/dokumente/spezifikation_deutsch/fint...](https://www.hbci-
zka.de/dokumente/spezifikation_deutsch/fintsv4/FinTS_4.1_XML-
Syntax_2014-01-20_FV.pdf)

[https://www.hbci-
zka.de/dokumente/spezifikation_deutsch/FinT...](https://www.hbci-
zka.de/dokumente/spezifikation_deutsch/FinTS_Rueckmeldungscodes_2017-05-11_final_version.pdf)

[https://www.hbci-
zka.de/dokumente/spezifikation_deutsch/fint...](https://www.hbci-
zka.de/dokumente/spezifikation_deutsch/fintsv4/FinTS_4.1_Data-
Dictionary_2014-01-20-FV.pdf)

~~~
rodgerd
> german-language-only

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.

~~~
toomanybeersies
English is the working language of software development, so it does make a
degree of sense to bemoan the fact that the API documentation is only
available in German.

~~~
germanier
A significant amount of software development in Germany is done in German
only, especially if you solve Germany-specific problems with your software
(such as accessing banks). English far from being a general working language
for software development here.

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.

------
Animats
Not seeing terms of service or a privacy policy. Who's responsible when
there's an error, or a transaction is processed twice or zero times? Is this
really a scheme to obtain user data and sell it to advertisers?

~~~
sjtgraham
Founder here. First of all, I'm honored the legendary John Nagle now knows
about my startup! :)

Privacy policy and terms are linked to from
[https://teller.io/developer/beta](https://teller.io/developer/beta)

Privacy policy:
[https://teller.io/developer/privacy](https://teller.io/developer/privacy)

Terms: [https://teller.io/developer/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](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!

~~~
Animats
Your terms:

 _" 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...](https://www.bankofamerica.com/onlinebanking/online-banking-
security-guarantee.go)

~~~
sjtgraham
Thanks for your feedback. We developed TAuth to provide attribution and non-
repudiation for exactly this kind of situation. I personally take security
very seriously such that launching our product has taken longer because
designing and implementing a system worthy of performing financial
transactions on behalf of others is a serious undertaking.

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.

~~~
dbbk
Is there much desire for moving money via API though? Seems like it would
expose you to massive risk for little reward.

~~~
anthuswilliams
Oh my, I have thought about this a lot, and I firmly believe that there is.
Sorry for the ensuing wall of text!

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.

------
skirsch
Early on at Token, we looked Teller as a possible solution to getting to
market quickly. We found two things: 1) the lawyers told us to stay clear
(huge greyzone) and 2) the banks themselves didn't want to engage with us
using teller even if it sped up development time. We even brought stevie in
talk to our lawyers to make his case. He failed to convince them. Finally, we
inquired about the price. Stevie was elusive on pricing. I finally asked,
"Look, if we paid you $1M, how many banks could we get?" He said one. So at
that point, we were so far apart on all issues, so we pulled out. Token will
be doing something similar to teller in terms of "one API for all banks"
(aggregating banks' PSD2 interface with Token acting as a PISP/AISP). But we
are also providing the PSD2 interface for other banks. We have raised plenty
of money to do it right ($18.5M Series A to start with), but our pricing to
developers will be ridiculously inexpensive. Also, we need to hire developers
very quickly, so if you are interested in helping us do it right (no shared
secrets, all end-to-end secure protocols, secure central PII storage (where
the decryption keys are only available at endpoints), please let us know. We
don't have a lot of time left to do this right. We are located in London and
San Francisco.

~~~
sjtgraham
Steve,

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.

~~~
gamblor956
It seems you boys can settle your dispute the old fashioned way: by providing
support for your claims.

 _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.

------
eriknstr
There already exists a company called Teller in Europe which is dealing with
payment solutions.

> 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](http://www.epay.eu/acquirer-internet/nets-teller.asp)

[https://www.nets.eu/en/payments/](https://www.nets.eu/en/payments/)

[http://netseu.23video.com/secret/12342399/64f0568391b3ebaa58...](http://netseu.23video.com/secret/12342399/64f0568391b3ebaa58b291826ee05aa4)

[https://my.teller.com/login](https://my.teller.com/login)

------
whockey
Hey all - co-founder of Plaid[0]. Congrats to Steve - great to see some
innovation across the pond!

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

[0] [https://plaid.com](https://plaid.com)

~~~
danpalmer
> Teller... supports the top couple banks.

> 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.

------
cikey
Am i the only one that would never trust a completely unknown third party with
my bank account?

I like the idea, but i would never use this as a service on the internet.

~~~
cbcoutinho
There will be early adopters who take on this new tech and show the rest of us
the possibilities. Just because someone reads HN doesn't mean they need to
jump on the band wagon

------
foodstances
How is this different than something like
[https://plaid.com/](https://plaid.com/) ?

~~~
JohnnyMneunomic
Or any different from Quovo ([https://www.quovo.com/](https://www.quovo.com/))
if you were pulling both bank data and brokerage data?

~~~
rufugee
First I've heard about Plaid and Quovo. These services seem to be targeted at
a developer interested in developing products for others.

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).

~~~
foodstances
I use Plaid for my own bank account access, which I used to replace my own OFX
code because my banks kept randomly breaking their OFX interfaces.

Plaid was fine with creating a developer account for just a few bank accounts,
they didn't have any minimum or anything.

~~~
rufugee
Thanks. I'll give it a shot. Any useful scripts you'd care to share?

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.

------
smaili
_How many times have you thought to yourself “Damn, I really wish my bank
account had an API”?_

Now that's an intro!

~~~
bastijn
You think? For me as a Dutch guy my only though was "literally never".

We have ideal for payments ([https://www.ideal.nl/en/payment-service-
providers/](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.

~~~
tokenizerrr
Another dutch person here. I can think of plenty of use cases. I'd like to
keep track of where my money goes, and have played with programs like GnuCash
and Ledger before. The big problem is getting data into them. I have a decent
system where I download the CSVs, feed them to a script, and everything gets
imported. However this requires me to think about downloading that CSV every
month. And my administration lags behind by a month. It's also inconvenient if
my system can't automatically identify the receiver, since then I'll have to
help it out. Hard to do that when I have to recall where I spent $15 a month
ago.

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.

------
heneryville
"We realise that our revenue will most likely be a very long tail with a small
number of customers bringing in most of the cash."

Either they or I don't understand what long tail means.

~~~
whitepoplar
Long tail doesn't necessarily mean that the tail makes up most of the
distribution. A long tail can make up a majority, or minority, of the total
distribution.

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.

------
skrebbel
Dutch mobile-only bank Bunq also published their API pretty recently:
[https://www.bunq.com/en/api](https://www.bunq.com/en/api)

Things are starting to not-entirely-suck in retail banking land. (in Europe,
at least - not sure about elsewhere)

~~~
reledi
Monzo, the UK mobile-only bank, also has an API:
[https://developers.monzo.com/](https://developers.monzo.com/)

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.

~~~
martinald
To be fair, Monzo isn't either. They don't have any of their own
infrastructure yet, it's just a third party rebranded prepaid card.

~~~
lylo
That's not true. They recently received a banking license
([https://monzo.com/blog/2017/04/05/banking-
licence/](https://monzo.com/blog/2017/04/05/banking-licence/)) and they have
built their own platform ([https://monzo.com/blog/2016/09/19/building-a-
modern-bank-bac...](https://monzo.com/blog/2016/09/19/building-a-modern-bank-
backend/)).

~~~
richardknop
But monzo card is still just prepaid debit card. You don't get a current
account.

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?

------
Scottymeuk
I built a little script to export my accounts to CSV/QIF. Super easy to use
API! [https://github.com/scottrobertson/teller-
export](https://github.com/scottrobertson/teller-export)

------
insomniacity
I emailed a bit with sjtgraham on this a while back.

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!

~~~
insomniacity
Incidentally, if Teller start to get an appreciable proportion of the UK
population (remember, users will be using Teller without realising, through
other apps and platforms), they should expect a call from the regulators, who
will want to be sure that they can't cause any systemic instability (eg by
getting hacked.)

------
lookingfj
How does it work if not by screen scraping?

~~~
sjtgraham
It works by using the same private APIs that the bank's own mobile app. We
reverse engineer their app, work out the API contract, implement our client,
and normalize the data.

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.

~~~
jswny
Not only does this sound potentially illegal but how can you be confident that
you will recognize the breaking changes in time to fix them? What if you begin
supporting a large number of banks and you can't keep up?

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.

~~~
sjtgraham
The EU Computer Programs Directive 2009 provides an exemption for reverse-
engineering for the purposes of creating inter-operable systems. This
directive has been harmonized into UK law (where Teller is domiciled and
operates) and Teller satisfies the requirements to be protected by the
exemption. We have also developed many novel techniques that do not meet the
UK legal definition of reverse-engineering so we have that angle too. This
issue has also been looked at by expensive lawyers.

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.

~~~
fredsted
Seems pretty sensible.

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?

------
IshKebab
Yeah no thanks. I want a banking API but I want a _first party_ API. No way
I'm trusting some random guy on the internet with my banking password.

------
jsk2600
This is interesting and has great potential to grow when PSD2 goes live in EU
(early 2018). I wonder what authors plans are regarding this.

~~~
sjtgraham
My hypothesis is that PSD2 will not be the golden opportunity everyone hopes.
Banks are an oligopoly and unfettered open access to their customers via open
APIs is potentially a disaster for them. They have little to gain and
everything to lose. When you consider this and then expect incumbent banks to
act in their self-interest it follows that they will act to subvert the impact
of PSD2, e.g. by fragmentation, lobbying for onerous requirements in order to
consume them, etc. All of this is already happening, which is why I think
there is an opportunity for Teller by truly aligning with developers and
users.

~~~
llsf
Removing roaming fees for all European telecom operators was also a something
that they had little to gain and everything to lose. But, here we are. From my
understanding SEPA is getting implemented. I could see PSD2 following the same
path. Some banks will drag their feet, but it is a pandora box situation, as
the banks that will implement PSD2 first might get all the apps attention and
love, potentially driving new customers. Let's see next year how PSD2 adoption
pans out...

PSD2 explained: [https://transferwise.com/gb/blog/what-is-
psd2](https://transferwise.com/gb/blog/what-is-psd2)

~~~
jasiek
Current roaming regulations in the EU are designed with the biggest,
transnational players in mind. By subsidizing operations in a less lucrative
market using proceeds from other countries, they can bleed smaller national
telecoms. They will then proceed to buy them for pennies on the dollar. This
will result in less competition down the road, and higher prices for the end
user.

~~~
icebraining
Can you break that down? How do the roaming regulations enable those bigger
players to do that?

~~~
jasiek
[http://ec.europa.eu/transparency/regdoc/rep/10102/2016/EN/SW...](http://ec.europa.eu/transparency/regdoc/rep/10102/2016/EN/SWD-2016-202-F1-EN-
MAIN-PART-1.PDF) \- see page 32 (ARRPU). Operators in different countries have
different profits per user (obvious). If you have someone like T-Mobile or
Orange, they'll use the proceeds from say... France, to finance their
operations in say... Poland. This will put pressure on other national
operators to further lower prices. Lower prices mean lower profit margins,
mean lower dividends, lower company valuation, being less attractive to
investors, etc. After a while their value will decline by so much, they'll be
willing to sell themselves at the current going price of their infrastructure.
Orange buys them, and kills off competition.

~~~
aembleton
That would be referred to the competition commission and could be blocked.

~~~
jasiek
This has already happened and no one batted an eyelash. Why?Because, Orange is
French and T-Mobile is German.

------
jimmcslim
I wonder how many of the use cases for a retail banking API would be simply
satisfied by just allowing customers to request a weekly email with a CSV
transaction file attached in a sensible format?

~~~
StarlaAtNight
Banks should most definitely do this. Or maybe provide a link to a CSV file
behind a login-wall (so the details passed over email can't be poached as
easily)

------
pjwal
Can someone explain to me this dichotomy I see with the almost thermo-nuclear
war when it comes to copyright protection of total drivel, but when it comes
to fin-tech there is literally a flourishing industry of screen scraping
typing companies and well-publicized plays like Mint and it's just like a big
shrug? How are these companies able to mitigate through the banking companies
TOU and such?

~~~
PeterisP
There are two main differences between screen-scraping content and screen-
scraping transactions.

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.

------
johnlbevan2
Is there a test / mock instance, allowing you to call services connecting to
dummy bank accounts? i.e. Some people may be concerned about trying out the
API on their own accounts during the early stages, or if any update services
are added in future. Also it enables those not banking with a supported bank
to develop against the service.

~~~
sjtgraham
A sandbox is planned.

------
sigi45
People: Only do it with an extra bankaccount. Without any credit functionality
and without your primary money.

Everything else would be very naiv.

------
_pdp_
Once you have access to someones banking account you can typically make small
transfers (up to ~£200) without second-factor authentication. So if your
service get's breached attackers will have potentially the means to extract
real cash through mules or wreck havoc.

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.

------
sleepyhead
Teller is already an established brand name in the payment industry in Norway
(Scandinavia?).
[https://www.nets.eu/en/payments/](https://www.nets.eu/en/payments/)

------
teekert
Bunq already has a native api [0], only if you pay sadly, many other functions
are free. I like Bunq but their app devellopment is slow, I still can't share
iDeal (is iDeal only Dutch? I wonder...) requests through anything other than
email and sms. Everybody is waiting for general sharing on Android/iOS.

[0] [https://doc.bunq.com/](https://doc.bunq.com/)

------
jimmcslim
Does anyone have any insight into a PSD2-style effort in Australia?

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'.

[1]
[https://developer.nab.com.au/ourapis](https://developer.nab.com.au/ourapis)

~~~
lysp
There's also a long running discussion on the commbank forums (since 2013).

[https://community.commbank.com.au/t5/NetBank/API-
access/td-p...](https://community.commbank.com.au/t5/NetBank/API-
access/td-p/5071)

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...](https://www.itnews.com.au/news/australian-banks-told-to-build-apis-
to-share-data-by-2018-442562)

------
guelo
This is annoying, I got all excited and then realising this is for a handful
of UK banks. Would be great if it were tagged as a UK thing more prominently.

~~~
niklasrde
I was really not excited, expecting it to be US-exclusive, until I clicked the
link and saw it was UK banks. Whoop ;)

~~~
esamek
I had he exact opposite reaction: expecting it to be US-exclusive and got to
the last paragraph where it said they don't support any US banks. Big ole' :-(
face.

------
runeks
> Transfer money between accounts, make external payments using Faster
> Payments, and manage your payees, standing orders, and Direct Debits all
> through the Teller API.

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?

~~~
ldn_tech_exec1
Teller allows developers to build applications on top of their users' bank
accounts, not just your own. Read more about TAuth and how it works here:
[https://blog.teller.io/2016/04/26/tauth.html](https://blog.teller.io/2016/04/26/tauth.html)

------
bruno2223
Cool project,

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!

~~~
javiercr
Teller is amazing (kudos to Stevie), but if you're looking for an open source
solution you can take a look to:

[https://github.com/bankscrap/bankscrap](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.

------
film42
Engineer at MX here! We have a similar product for US and Canadian banks
called Atrium.

More info here: [https://atrium.mx.com/home](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.

~~~
kondro
Didn't Morningstar just sell you to a bank though?

Is your product still going to be on the open market in 6 months time?

~~~
film42
MX is not owned by any bank. It's still privately owned startup. We are long
term in that we have many 5-7 year contracts with big name banks and add more
each quarter. We offer mobile banking solutions, data categorization and
budgeting tools to banks, so we Atrium is a product to sell access to the
services we built to power our other products. So yes, our product will
definitely be on the market for years to come.

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 :).

~~~
kondro
Sorry, don't know why I always get MoneyDesktop and HelloWallet confused. :(

Cool… keep on trucking! :)

BTW, I don't suppose you have Australian/NZ support?

------
orliesaurus
Knowing the founder personally and his level of competency writing code gets
me very warm down below. If I still lived in the UK, I would build something
around Teller trying to give users a feeling close to what Monzo-bank is/does.
Some kind of a hybrid zombie child, but beautiful!

------
megamindbrian
How is this differently than Yodlee?

------
SamyGe
Maybe every Bank should provide its own, well documented API. Third Party is
not an option imho. Also this reminds me of that root Bank i saw here in HN
some time ago... [https://root.co.za/](https://root.co.za/)

------
BigChiefSmokem
A bank account is usually only part of the financial equation. What would
really be useful is an API for a service like Mint. I'd even be willing to pay
a low fee for someone to make available all the aggregate data from all the
financial institutions via API for me.

~~~
artosispylon
IIRC, Mint works by screen-scraping, which is what Teller.io is trying to
avoid

------
7ewis
This looks really cool, but I'm nervous about trying it. Can they provide any
guarantees?

~~~
corobo
_While we make every effort to ensure our services are available, secure,
accurate, complete, and free from defects we provide no guarantees,
conditions, or warranties of this, express or implied.

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.

~~~
7ewis
That's a shame.

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.

------
wbronchart
I have a UK bank account but no UK phone number, can't sign up.

------
_cairn
Sorry for the newb question but a quick google didn't yield the results I was
looking for. What is the attack vector here that "screen scraping" would
exploit?

------
retrac98
Just wanted to say well done. Lots of people here throwing up problems,
complaints, reasons why this won't work etc. I think this is great.

------
benoror
Paybook ([https://www.paybook.com/](https://www.paybook.com/)) is doing the
same in Mexico

------
apeace
Which countries are supported? Not seeing that info anywhere. I only saw in a
comment here that Teller has relationships with "every major UK bank".

~~~
apeace
Found it: [https://teller.io/developer/beta](https://teller.io/developer/beta)

It is UK only.

------
sgt
Seems similar to [https://root.co.za/](https://root.co.za/) \- which is
focused on South Africa.

------
hendry
I think I noticed a similar venture in Indonesia:
[https://brank.as/](https://brank.as/)

------
billconan
Is this only for UK? which banks are supported?

~~~
giobox
It's stated in the post:

"Teller is available today for Santander UK, Barclays, Natwest, Nationwide,
RBS, Isle of Man Bank, and Ulster Bank."

------
Doctor_Fegg
Superb. Any chance of supporting Lloyds?

~~~
sjtgraham
Yes, Lloyds HBOS brands are a high priority.

------
empath75
I'd much prefer that this were just open source so I don't have to share my
bank credentials.

------
kennedy
When will this be available in the US?

~~~
rdslw
Never?

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.

~~~
kanwisher
yodlee, mint, quicken, come on. I've had bank transaction information for last
20 years

~~~
rdslw
Mint is readonly. PSD2 and reverse engineered api is not. Also Mint exposes
you to the very threat mentioned in top comment, while PSD2 protects you here.

So how about No?

------
elliott2020
OMG finally! So does this mean we can skip all the credit card and ACH fees?

------
lamby
Would love HSBC support :)

------
donatj
Any plans on support for more American Banks, such as Wells Fargo?

------
petraeus
There are many many problems besides the technological hurtles.

------
mossid
Is there any plan to support south korea?

------
adambowles
Why is it gated behind SMS?

------
jamesrom
Is the fact you don't talk at all about security in this blog post or on your
home page deliberate?

------
AJRF
I cant wait for PSD2.

------
beaconstudios
cool - what makes your service different from Yodlee?

------
lngnmn
Yet another man-in-the-middle collecting a fee from each transaction?

------
kkotak
I'm sorry but your solution is not my problem.

