OK, so everyone keeps telling me about why I need to drop everything and go read about PSD2 this very second because it’ll take a nutcracker to security for financial institutions. Having become at least cursorily educated about it, I have to say that now I’m overall pretty “meh” about the whole thing. At least from a security point of view.
Here’s what I mean by that. Firstly, it’s probably ultimately good for consumers. I’m not doubting that… well, OK, maybe I am doubting that a little bit… but since I only write about security, I’m willing to hold my peace on that front to see how the market reacts and what new services arise because of this. The part that I would tend to comment on – i.e., the security impact of it – I really don’t think is going to be the huge “hammer of doom” that everyone says it will.
If you don’t know about PSD2, I’m referring to EU Directive 2016/2366. In a nutshell, it requires banks and other financial institutions (e.g. retail lenders, etc.) to provide API’s such that other parties can provide services around finances in addition to the institutions themselves. Meaning, it’s about fostering competition in “financial-adjacent” services (by “financial adjacent”, I mean like opening up information so that technology providers can provide more services to you that would otherwise not be practicable because there’s no way for them to get to the data.) So less like Google is going to become your bank and more like a “Google Financial” service where you can go to see a consolidated financial profile of what you have, what you owe, stock positions, etc. Would I use that? Again: “Meh?”…
Now on to the security part. Don’t get me wrong here, I’m sure there will be security implications of this. Having worked at a large financial institution, I trust the ability of the average developer there about as far as I can throw them (I say this with love having been at the time a) also a developer and b) working in financial services). As an example of the shenanigans that go on and why I say that, I recall being in a meeting once to discuss a new order entry application… the developer of that spent (not kidding) about 15 minutes explaining in intricate detail the new “connect via URL” methodology they were using to “relay data” about the user to the app. After politely listening to the explanation, the colleague I was in the room with said “so… it’s a link… and you click it?” The developer grumbled, “yeah, you could also say it that way.” Point being, I’m sure that the API’s bit will introduce some security challenges, there will be some “kinks” to iron out along the way, and the first few stabs might not be the final end product.
But other than this (which is to be expected), there are really two levels to the security impact: the program level and the API level. At a program level I’m referring to new protections that are required to secure what they’re trying to do. And here, those security requirements are pretty high level. They also don’t really require much from the FI to adhere to as it’s arguably all stuff that they should be doing anyway.
Consider the final report from the EU Banking Authority for example — i.e. “Guidelines on the security measures for operational and security risks of payment services under Directive (EU) 2015/2366 (PSD2). (side note to remind you that I AM NOT A LAWYER.) It requires (paraphrasing from the “Guidelines” section): risk management (including risk assessment), “Protection mechanisms” that include things like “defense in depth”, continuous monitoring, BCP, physical security, situational awareness, etc. Sound familiar? It should… because it pretty much says the same thing that every other security guidance document does since time immemorial. The tl;dr? It’s super high level and any financial institution keen on not getting sued is already doing these things already. The most interesting part is Guideline 9 which relates to user awareness about risks — that’s a bit on the “novel” and “action required” side, although it’s not going to break the bank to put in place (get it? get it? break the bank? because it’s a ba… Nevermind).
When it comes to the specific API’s is when it gets maybe a little more complicated. But I think upon reflection it will ultimately bolster security. I say this because services like Yodlee and Mint have channels already — as do more specific services like Fiserv (formerly Checkfree) — to gain access to this data. The difference is that each one is a one-time kludge “proprietary transactional mechanism” supporting an individual service. So conceptually, what’s new is the scope – i.e. the parties on the other end. But underneath, it’s an opportunity for standardization. I think that’s a good thing for the security of the system overall.
Will there be problems along the way? Of course there will… in large part because appsec isn’t really anybody’s strong suit, but also because it’s increasing surface area about who has access to financial data. But ultimately, is it going to transform how FI’s implement security? I’m skeptical. Or, said another way, “meh”.