Europe keeps influencing data privacy around the world. First, there was GDPR, and now we have PSD2, which is the new phase of Europe's Payment Services Directive. And as with any new compliance, there's a lot of confusion about what it does, what you have to do and what it all means. You can basically sum it up like this:

Data is even trickier as there are basically three kinds of data PSD2 is forcing banks to expose.

Making Public Information Available Over an API

Surprisingly, banks are now forced to expose information like bank locations and services over an API - this data may have been available on websites, but now it's required to be available over an API allowing for easy integration into third-party apps.

This means a third party will be able to create apps for finding specific kinds of branches (an obvious example is branches with good services for people with disabilities or who have different native language speakers). But interestingly, once a standard is established, it will be suddenly very easy to compare banks services, find contact information, and use that information to help consumers navigate the big banks.

Making Customer Transactions Available Over an API

Banks know a LOT about you — your spending tells them where you are, what projects you're doing (spends a lot of time traveling but buys a lot of home improvement hardware). That data has always been considered an asset of the bank so they can develop new products and services and sell them to a ready customer base

But under PSD2 that information can be released to third parties. Say you grant a tax management application access to not just your main checking account but to your credit cards from other banks, and to your savings accounts. Finding your deductions suddenly got a lot easier.

Allowing Third Parties to Trigger Payments

And here's the big one — now, third parties can send requests to your bank directly to move money from point A to point B. Moving money around has been tricky for years; credit card machines in retail shops connect to a card processor, not the bank. That card processor then contacts the bank and money starts to move around.

PSD2 makes it so anyone can write software to contact the bank and, with the right credentials, move money from one account to another.

Sounds Great! How Do I start?

PSD2 is a body of European law that European banks have to comply with. We're not sure how it's going to affect US banking, or what the APIs are going to look like, or what brilliant applications are going to come out of it.

The problem with compliance law is that the people who write it aren't the people who have to implement it or make it work. When a body of law is brand new there haven't been any wins or losses, so no one has a model for what to do and what not to do.

The UK's OpenBanking (see https://www.openbanking.org.uk/) is probably the most sophisticated at this point, but third parties still have some pretty big gaps they're going to have to deal with including

• User Identity: Each bank has their own Identity management system; if you're going to build a third party app against, say the nine major banks in the UK, you're going to have to coordinate all nine identities and have a secure way to maintain those identities in such a way that doesn't make them have to log in nine times every time they want to look at a report.
• Services Identity: Your app and your microservices are now playing with people's banking and livelihood. Every little app, be it your frontend web app or individual microservices on the backend, need specific permissions so something doesn't go rogue and start eating everyone's money. (And even if it isn't going to eat money, you need your customers to be comfortable it won't. See our blog on Infrastructure, Legal and Embarrassment).
• Thing Identity: Obviously a big part of the opportunity with PSD2 is changing the tools we use to transact business. Kiosks, mobile devices or embedded systems are going to become more and more important. Trusting that device means tagging and identifying the device as much as a human being.

And, at the end of the day, this is all part of the GDPR world. You need end-to-end tracking so if something does go wrong, you know exactly who touched what, why, and how to fix it.