How banks are getting around open banking and PSD2
thefinanser.com
thefinanser.com
Each bank has an open source adapter (this is different to Teller) and we encourage the community to help us building more adapters. So far we got adapters for 4 major banks in Spain, and 3 more are a work in progress.
Whether PSD2 is going to happen or not, we believe public APIs for banks will happen (even if banks don't like it).
IMHO banks arte not scared because of security concerns: they all have APIs in production already, they are just not documented. Their main concerns is basically how APIs used by third party services could affect their businesses.
> The person having a right to use a copy of a computer program shall be entitled, without the authorisation of the rightholder, to observe, study or test the functioning of the program in order to determine the ideas and principles which underline any element of the program if he does so while performing any of the acts of loading, displaying, running, transmitting or storing the program which he is entitled to do.
There is in fact a EU proceeding against MathWorks for preventing a competitor to reverse-engineering their product to achieve interoperability [2]
In any case, we currently offer no guarantee to our users and we encourage them to use our open source libraries at their own risk.
[1] http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2...
I suppose you've somewhat addressed it with your final comment: "...at their own risk." I'm not risking access to all my money on using your library to access my bank account. If you say the risk is mine, and, since I'm using your library rather than an approved binary, the bank can show that the risk is mine, when someone finds and exploits a weakness in your library to take my money, I'm screwed.
I'm not sure what kind of exploit or weakness you are thinking about. But the risk of using Bankscrap's gem from your computer is similar to using your bank's mobile app. Bankscrap itself doesn't store any data nor send your credentials to any place other than your bank's API (the same that your mobile app does).
In other words, if you use Bankscrap's gem to build a web app to fetch and store your bank transactions (or someone else's), and your webapp or server gets hacked, obviously the responsibility is yours.
And we're not talking about HTTP calls with SQL injection or things like that. We're talking about identical HTTP calls to the ones that the banks' mobile apps do. Same headers, same body.
Besides universities there are not many non-profits that will have the legal and financial means to publish an open source lib. The legal landscape for managing a complete library with numerous banks is complex. As we see in this discussion thread, there are some fragmented solutions with limited coverage.
https://github.com/Internet-of-Money (empty placeholder)
No business would take that risk and use your library at scale. Yes, open source is great, etc. But it doesn't solve the problem.
Sorry, but I still don't understand what you mean here. There could be a bug in the library in the same manner that there could be bugs in any other open source library. Could those bugs become a security issue for your app? Yes, they could. Despite of this we all use open source software, right?
Let's say you were using Active Merchant[1], would you sue Shopify if someone hacked your app to process irregular payments through your Bank's payment gateway (accessed by Active Merchant [2])?
[1] https://github.com/activemerchant/active_merchant
[2] https://github.com/activemerchant/active_merchant/tree/maste...
And yet every business has a checking account, and many aren't that diligent about checking it every 24 hours.
However it looks like is just a collection of web scrappers. This is the implementation for Barclays bank:
https://git.weboob.org/weboob/devel/blob/master/modules/barc...
Bankscrap, despite of its name, tries to avoid web scraping in favor of XML/JSON apis provided by the banks. Right now all our working adapters are API-based, not web scrapers.
You can add that some modules have the same kind of name (BNporc which would translate to BNswine for BNP Paribas[0]). Or some applications: QHandjoob[1], QFlatBoob[2] or QHavedate[3] where the icon is a stickman with an erect penis getting ready to have sex doggy style[4].
They used to have a nazi svatiska on the Caisse d'Épargne module logo[5]. At least they changed that one.
Really, how anyone could use that professionally is beyond me.
[0] http://weboob.org/modules#mod_bnporc [1] http://weboob.org/applications/qhandjoob [2] http://weboob.org/applications/qflatboob [3] http://weboob.org/applications/qhavedate [4] http://weboob.org/media/images/applications/qhavedate.png [5] https://symlink.me/projects/weboob/repository/changes/module...
https://github.com/bankscrap/bankscrap-bbva/blob/master/lib/...
Does it break functionality if you don't pretend to be an Android phone?
Adding the library version in their would be helpful for debugging too. Ideally it'd be possible to override at the app level so that it correctly shows up in their logs.
We try to mimic as much as possible the requests that banks' mobile apps would do to avoid them becoming "hostile".
If a law could codify an acceptable answer to that problem, I think a lot of the security/regulatory problems could go away. Banks might still try to stop the process for competitive reasons, but they might not be able to lean on the crutch of "security" to do so.
In the UK this problem isn't new, there were aggregator services 15 years ago that screen-scraped banking data to provide customers with a consolidated view of their finances and they required customer's to provide their credentials for them to do that. Banks understandably weren't too pleased about the idea of 3rd parties having those credentials.
Most of the banks here just provide downloadable csv/excel files after logging in with BankID (national electronic ID thing, https://www.bankid.no/en/company/).
If you upload that file to a 3rd party, the 3rd party still needs a license etc to keep/process it and is liable.
In any event, liability really depends on who is taking the decisions over the use of the data. If the third party just takes a feed of the data from the bank then takes various decisions over its use, they could well be a data controller. If on the other hand a bank contracts with a third party to provide an account aggregation service to its customers and they are passing data for this very specific purpose then the service provider could well just be a processor.
The above is also going to change with the new General Data Protection Regulation coming into force next year...
That sounds ridiculous. Are YCombinator executives at risk of being fined/jailed in Norway since they presumably did not get a license for the Hacker News users table?
Would a Norwegian teenager land in legal trouble for running an unlicensed phpBB forum? Do SaaS programmers need code review from the government on their pull requests? When Amazon or Netflix trains a new recommendations model?
The more complicated bank licence is needed to lend money from people.
I'm not sure about U.S though.
But I think most banks have realized that they need to do something, lest they will end up the non-significant bill for the infrastructure but a dwindling list of services that they can make money on.
Regarding third party screen-scrapers, from what I can see there are challenges both in the legal framework and technical issues like security and performance.
The main reason is legacy: Banks and other financial institutions are among the oldest users of computer systems (I would not hesitate to say that certain banks even utilized Hollerith tabulating systems; they certainly likely used tabulating and other accounting machines made by the early IBM).
Code in these institutions likely consists (in a large part) of many lines of COBOL (and possibly other archaic languages - I wouldn't doubt there is some old RPG lurking around).
You might ask "well, they could just translate the code or rewrite it" - but it probably isn't that simple. Over time, what we now call "technical debt" built up in a massive way. They fixed and patched and fixed some more, and probably comments don't match the code, and there likely isn't a singular design document or API description anywhere that shows what the system is actually doing (and any that does exist probably doesn't match what is actually happening). Coders came and went, most are probably dead now. But that code is the baseline for how the system works, warts and all. Heck - there's probably code in there that works around bugs in older COBOL compilers or who knows what else.
They keep this around - probably emulation on top of emulation - because to refactor all of this would take a super-human level of dedication and effort, and likely introduce new bugs along the way. In fact, there are likely still a ton of "edge case" bugs lurking deep inside that have yet to be found. It may be that fixing these bugs (if found during a refactor, say) might break other working code that depends upon them existing! Even if the refactor were successful, they would still only get to the point of having a system that does everything it currently does (but still may have unknown bugs).
You're right that there isn't a financial incentive to fix it. In fact, the opposite is likely, because if fixing it breaks something, in even a subtle way (and that would be worse than anything, because something like a small rounding error might go easily unnoticed until far too late) - it could end up costing the business so much money as to ruin them. I can't really blame them for being so hesitant about such a change.
This kind of legacy affects all kinds of businesses and institutions, especially the ones that are quasi-considered "foundational" to society, and hence are likely to be among the oldest users of computer, transaction processing, and accounting systems. A few others I can think of would be accounting firms, logistics (especially railroads - as they were among the first to use Hollerith's systems after the 1890 census), air traffic control (we've already seen this system try to be updated - and fail), airline ticketing (arguably maybe second oldest - how old is SABRE?), insurance...
None though - with the exception of the ATC systems - have the same level of repercussions to happen should a new system not perform and act the same as the old system(s) currently in place.
I personally am not particularly keen on yet another API being made available to a bunch of rapacious VC-funded startups that facilitates my intimately personal financial info being spread around. Personally I bank with metro bank in the UK, they're new, competitive, and frankly pretty darn good, all for free. Do I need even more "financial services" thrown at me when there are apparently zillions of bricks and mortar operators already offering me everything from credit cards, subprime, insurance, car finance, re-mortgaging, yada yada yada yada ad infinitum?
I would argue that in this case, the banks' and my interests are somewhat aligned. They're protecting my privacy! How many profit seeking entities on the internet can say that?
I get it that fintech would dearly love to get its hands on people's money, but is there actual demand from said people for even more financial services? Or does this post simply amount to self-interested regulatory lobbying for a zero sum transfer of economic rents to the fintech space. Because you just know that if these APIs come about, fintech will find all sorts of dubiously "persuasive" ways to get people to allow access, possibly against their own interests.
Incumbent banks have been incredibly bad at creating modern digital user experiences. To analyse my spending, I have to login to my online bank with a fob and various passwords, download statements in .csv format (month by month, no batch download) and plot them in excel. It's not great.
I am really looking forward to more open banking API's. Monzo have one, a couple of others, but very few.
I have been working on a side project for the kind of banking experience I would want [1] - but it won't be possible without banks opening up API's.
[1] http://bixtr.com
That is certainly true, but it's not as if the shiny new fintech startups are necessarily any better. You'd think it would be business finance 101 to be able to reconcile money that a payment service collects from your customers and then deposits in your bank account with the money you expected them to be collecting, but unless there's been yet another API change lately, none of the services we use support a simple, reliable way to do this.
I have a credit card with a different provider
If I want a quick assessment of my accounts, either I need to log in to multiple accounts and add them together, or I can use an account aggregation service like yolt
Unfortunately nobody supports secure delegated auth, so you risk compromise.
First of all, they should provide an API for me, the customer, so that I can use the data and automate my banking.
Eula's would be the greatest difference.
It is sad though, that no start-up would consider building a self-hosted version that'd keep all data local, instead wanting to offer it in SaaS form.
i don't think that'd be automatically true. if there were enough security conscious users to create a market for a product like this, someone would provide.
This has the added benefit of possible adds and even gathering data of users.
The issue is exacerbated by the almost sure to be available open-source gratis software. Presuming the software is under-maintained.
Or more generally contracts and regulations, yes. If you need to be registered with some regulatory authority with security audit requirements, say, in order to be able to gain access to the API, then you cannot use the API, whether you would technically be able or not.
Teller does work but only a very small amount of users have production access at the moment. We've been very cautious about broadening access in case banks responded aggressively and generally speaking they haven't. A lot of work has been put into making the service reliable when it essentially sits on private APIs the banks prefer no one but them uses.
Teller will eventually support every bank but the banks we support currently are:
- Barclays
- Natwest
- Nationwide
- Santander
- RBS
- Ulster Bank
- Isle of Man Bank
personally, i'd love to write my own open source clients you can verify and compile yourself that provide better information and heuristics - but that'd hurt the banks.
there are several kinds of of users: those who make the bank money (the uninformed that do not care much) and those who are actually interested in their statements. the latter are loss leaders. for consumer banks, the latter seem to be in the majority.
an app that informs you with the best intention (warning: if you continue your spending for the rest of the month like you did this week, you'll pay a lot extra!) would shift the balance even more.
That sounds like a made up argument. How is structured data less consistent than the scraping that is currently happening? A more realistic argument is that banking systems are old and outdated, the cost of upgrade is enormous and no banks wants to be first.
Worse, some banks actually have standard APIs (e.g. OFX) than are used by commercial accounting softwares (e.g. mint, quicken) but the banks (e.g. Chase) charges a monthly fee to enable it.
I can tell banks plan or want to offer PSD2 services.
Either by a third party or offering them on there own.
What you might get though is a terible ugly interface to the inner part of the bank.
I also just read the newest version of the PSD2 proposal. There is (sadly or luckily) still no plan for further specification what a bank needs to offer or how.
But all in all PSD2 won't change the world of payment.it will be still easier to just use PayPal:)
You can bet the banks didn't think of this themselves, but it was probably forced on them by a consumer protection law. It is, coincidentally, something most Dutch people don't know exists.
Can you explain your reasoning?
Often with things like auto-bill-pay, you have to wait a billing cycle for the new changes to take effect. And you generally have to keep the two accounts open until everything is switched over, or face the wrath of failed direct debits.
I'm a lot less concerned about a 3rd party leaking info about my assets than I am about them being able to do things with them.
So far, every program or website that wants access to info also gets full rights to sell, buy, transfer, etc.
When notifo stopped (free API to send push messages without having to write your own native app); I didn't re-implement it, but from time to time, I wished I did; maybe something I should look into again.
I think big banks will learn pretty quickly that they are commodities, and they will need to compete on more than inertia alone.
It looks like something that makes sense for big companies. The pricing [2] is a bit weird:
> Developers will find the Envestnet | Yodlee Aggregation API – our new and improved RESTful API architecture – easy to use, which will speed up integration and simplify data access. It will also enable developers to sign up on the developer portal for a $250 monthly fee and get immediate access to a testing and production environment.
So $250/mo just to sign up... no idea about what's the pricing per API call.
[1] http://money.cnn.com/2010/12/02/pf/mint_leaves_yodlee/
[2] https://www.yodlee.com/blog/envestnet-yodlee-offers-new-quic...
It's a crappy service, but the only one that support a wide range of banks in different countries: - costs a lot: we pay around $20,000 / year - we have a lot of support tickets from users who can't connect to their bank. We usually forward the issue to Yodlee and they fix it within a few days.
They scrap bank websites, but their algorithms do not seem very robusts. If the bank change a little detail in their UI, it breaks Yodlee's connector. Sometimes, the bank interface depends on user preferences (e.g. language, business/personal account), so the user has to configure his preferences before succeeding to sync Yodlee.
As an example; they have a PayPal interface too. Initially we thought of using them to connect to PayPal, but we noticed they scrapped the Paypal website too, instead of using their API. So, we had issues with some users who did not have a Paypal business account
Unfortunatelly, it's the only solution that supports a wide range of banks (~24,000 banks), so we are still using it. (for U.S. users, we use Plaid that is more reliable but support less banks)