PSD2: In fintech and banking more generally, it’s become the magic word for disruption, opportunity and threat all rolled into one.

The Payment Services Directive 2 is a revised directive from the European Union on how the payment services industry must operate, cooperate and provide choice for consumers. Even in the light of Brexit, PSD2 will have a seismic effect on the payments landscape in Europe.

At the heart of the directive is the opening up consumer bank accounts to trusted third parties who can act on behalf of a bank customer to make payments or gain access to account information. Customers can delegate authority to these third parties to perform activities such as making an automated payment on their behalf: This will be done without ever seeing the customer’s card details or accessing account information that is not relevant to the payment they are authorised to make.

Wallflowers

Whilst the directive does not mandate it, there is a general consensus that the natural vehicle for exposing the accounts to trusted parties is via a suite of APIs and the hubris on open banking continues to grow in volume in light of this point of view. The prospect has resulted in a collective eye-widening and mouth watering across the fintech scene, with many protagonists reacting with an almost Pavlovian excitement whenever it’s mentioned: PSD2 represents a huge opportunity for them to offer differentiation in products and services.

However, the traditional banking industry (especially in the UK) has reacted with an almost equivalent amount of inertia, with the general consensus that the banking regulators across Europe need to introduce fit-for-purpose frameworks under which PSD2 can be implemented. Certainly there are early movers, like BBVA, but generally the industry resembles a school disco, with all the kids standing against the wall waiting to see who dances first.

Trip the light fantastic

Your average techie working at a financial institution will look at PSD2 and think: “Why should I care? I’ll deal with it when it drops into my backlog”. However, when the dancing does start and the banks and financial institutions across Europe are compelled to implement the framework set by the regulator, many organisations will need a mechanism for delivering APIs or face serious penalties. The technology teams in such organisations can help deliver this by taking a number of practical steps now that will deliver real benefit in the near future and they can help shape their architecture to make it PSD2 ready.

Treat your architecture like a platform

API experts often talk about platforms, with the idea being that whatever happens in your stack will be unbeknown to your customers: All your consumers know about is your API. However, you need to consider the implications of grooming the API mullet as your organisation is going to have to ensure that the right data is in the right place at the right time to really make this stick and that could be a question of having a fit-for-purpose architecture to support it. This needs to be considered in the context of your organisation and how you would go about ensuring an API offering customer data gives the consumer everything they need via this single channel.

Revisit and redesign your services

The majority of IT people will be sick to death of hearing about services. 10 years ago it was all about service-orientated architecture (SOA) and the vendor-supplied frameworks that went with it; today it’s microservices and how they can transform your organisation.

Whatever your view services, the simple fact is that an API exposes a service and, whatever that service is, it needs to convey the right information to the right person when requested. Actually getting this right when your API is facing outside your organisation is of paramount importance so time and effort should be devoted to ensuring this can be done, with the right design methodology and technical infrastructure to make it happen.

Breakout user identity

Clearly the requirements of PSD2 break new ground for many financial institutions on the topic of user identity. Traditionally banks only provide access to customer records for internal services, all held within the banking ‘fortress’: This rulebook is being ripped up and replaced with the need to trust an unknown number of external services that see part or all of the information held on a customer.

In order support this the identity of your customer needs to be abstracted away from their core data and made reusable in isolation: In terms of a technical construct, in the same way that OpenID Connect uses scope and claims to describe permissions and authorisations about a given identity. Without decoupling identity you won’t be able to support the objective of turning your architecture into a platform, as security and data will remain intrinsically linked.

Final Thoughts

PSD2 has the potential to open up a new ecosystem of opportunities and, at Ebury, we’re readying ourselves for the opportunity: Whilst we may not fall under the scope of the directive, we’re building our API in line with the practices above with the aim of putting ourselves in the best possible position when the technical frameworks for PSD2 are drawn-up.

By taking this approach we believe we have the best chance of success in this exciting new payments landscape.

If you’re interested in talking about our API please drop me a line.