PSD2 is coming and it’s going to change everyone’s view of banking data. Under PSD2 regulations, banks must provide access to customer accounts through open APIs (application program interfaces), allowing third parties to build their financial services platform on top of banks’ data and infrastructure.
In a nutshell, PSD2 ushers in a world where you might log into Barclays and see your Lloyds account balance, transfer money between accounts using Google, or pay your bills through any one of thousands of as-yet-unknown fintech startups. And the countdown is entering its final phase. The UK government is required to bring the EU’s revised Payment Services Directive into law by 13 January 2018.
PSD2 represents a tremendous opportunity to be bold, but a big problem for many financial services businesses is that their legacy systems simply aren’t geared up to deliver what the regulator wants.
A new economy with a bigger pie
The PSD2 changes might seem revolutionary, but in truth they’re just bringing banking into the technology mainstream of the API economy. In many industries, it’s already a given that interoperability and integration driven by open standards can make the pie bigger for everyone.
According to the Harvard Business Review, by 2015 Salesforce.com was already generating 50% of its revenue through its APIs, eBay 60%, and Expedia.com a staggering 90%. For these companies, their APIs aren’t just add-ons – they’re often the primary interface.
Collectively, financial services companies will need to agree on open standards to maximise interoperability on lower development costs across their common ground. Individually, they’ll need to look for opportunities to enhance their core offerings, using services provided by other organisations.
Microservices for financial services
To become a first-class player is this world of APIs, simple integration and open data, financial services firms will need a software architecture that’s fit for purpose: agile, adaptable, highly scalable, reliable and robust. The architecture best equipped to operate in this new environment is one that’s already well proven at companies such as Amazon, eBay, Twitter and Netflix: microservices.
A microservices architecture in banking splits monolithic applications into a set of services that talk to each other via open APIs. Each service performs one thing extremely well; the service and its API are a product that’s discoverable, well-defined and carefully maintained. Self-contained services are then assembled as required. Services cooperate to deliver complex functionality, even if they are deployed independently of each other.
Services can scale independently too, making the software adaptable at runtime. And if one service fails, it typically won’t bring down the entire system because of the resilience built into microservice-based digital banking solutions. Separation means that each service can be developed independently using whichever methodology, programming language, application framework or data storage options are appropriate to the specific task it fulfils. This also means that the banking microservices assembled into a solution can be developed by entirely separate organisations.
Interact
In July 2016, ieDigital embarked on an ambitious programme to develop the second generation of our flagship Interact product. Starting with a blank sheet of paper, we looked afresh at the opportunities and challenges we thought financial services firms would face in the next five years. We determined that an engagement platform built on a microservices architecture was the answer to the questions raised by these opportunities.
In developing the second generation of our Interact product, we imagined that, in the world of PSD2, financial services firms would need a product platform with well-defined, open APIs. One that’s highly adaptable, highly scalable, and doesn’t require an army of consultants to change.
We imagined that it would need to work with state-of-the-art software, and integrate with legacy banking systems. We imagined that as its highest priority, the software would make possible the easy orchestration of multiple independent services into single, secure and seamless user journeys that deliver the best possible experience to our customers. And we imagined that the product platform needed to be ready now, in 2017, before the new regulations become law.
As PSD2 approaches, the time has come for the next generation.
