Open Banking and PSD2 in Practice: APIs and MPLbank
Next-generation digital concierge services with Open Banking
Our experience of digital banking services will change beyond recognition over the next five years. Imagine opening a single app on your smartphone and being presented with your cumulative wealth, regardless of the financial institution or credit card provider. Or perhaps youâ€™re looking to buy the perfect gift and can tap into an AI-powered concierge service that makes intelligent recommendations; that identifies the lowest cost retailer; earns loyalty points; and then selects the most appropriate bank account from which to push the payment.
This is the era of Open Banking. And itâ€™s here already.
The premise of Open Banking is to provide consumers the choice of how we access our banking services and data. Financial institutions are increasingly offering secure (and permissioned!) access to our data, to allow us to work with trusted parties to experience the kinds of value-added experiences described above. This article introduces the concepts of Open Banking, using European regulation, PSD2, as an example. It is the first of three articles on the subject and positions a working IBM Banking solution that has been established to identify and address the technical pain points associated with Open Banking and PSD2.
Bringing Open Banking to life with Payment Services Directive 2 (PSD2)
In Europe, the second iteration of the Payments Services Directive (PSD2) came into effect in early 2018, and requires all payment providers â€“ banks, building societies and credit card providers â€“ to offer Open Banking services. PSD2 stipulates that payment providers, such as Banks and Credit Card providers, must offer three new kinds of service:
- Account Information Service (AIS), will provide information about the account-holderâ€™s balance information and recent transaction history;
- Payment Initiation Service (PIS), will allow payments to be made between two accounts, for instance in a business transaction between a buyer and a retailer; and,
- Access to Accounts (XS2A), a digital channel to securely surface these Account Information and Payment Initiation services.
These services are made accessible to Third Party Providers (TPPs) who have been granted permission to access the account holderâ€™s details. The TPP may be other financial service providers, such as Banks, PayPal; or even fintech start-ups, some of whom are listed in this UK-based FCA repository of TPPs. Figure 1, below, illustrates these inter-relationships both now, and under PSD2.
Over the last 24 months, a consensus has formed amongst European Banks, in consultation with the European Banking Authority, that APIs are the preferred approach to implementing the channels for PSD2. This API-based approach has many advantages, relating to open standards, ease of use, implementation and, most critically, a robust security framework to protect consumers, corporations and the financial services providers themselves.
Most fascinating of all, is that this European regulation has rapidly fired the imagination of the global banking sector. Already, payment providers as far afield as North America, India, China and Australia, are honing in on the essence of PSD2, and identifying the lucrative business potential associated with broader Open Banking initiatives.
Embracing the Challenge of Open Banking and PSD2
There are two key challenges facing Banks embarking on an Open Banking journey: (1) the business implications of an intermediary taking ownership of the relationship with the end customer; and (2) the technical challenge of offering a â€˜delightfulâ€™ API experience to external parties that nevertheless provides secure and robust access to core payments and accounting systems.
For adopters of PSD2, there is a third challenge: succeed at speed, and iterate fast.
Based on a wealth of deep expertise in the financial services sector, IBM is uniquely positioned to help organisations address the multi-faceted implications of Open Banking and PSD2. This and the subsequent articles address the technical challenges facing the banking sector, and sets out a proven end-to-end solution, built on the MPLbank showcase.
Open Banking and PSD2 Solved: Introducing MPLbank
MPLbank is a real-world showcase of the technical challenges facing the banking sector today. More than a simple demo, it was conceived as a replica of one of Europeâ€™s largest banks, with a core accounting and payment system based on CICS and DB2 z/OS technologies on the IBM Z platform. Servicing 12 million accounts, the MPLbank has evolved over time to introduce multi-tier application platforms, ESB technologies and Big Data platforms. More recently, MPLbank has adopted a digital channels strategy supporting internet and mobile banking channels. It is a true representation of the challenges and pain points facing Banks today.
With the recent regulatory changes, the MPLbank team set themselves the challenge of adopting an Open Banking solution and meeting the deadlines of PSD2. Pioneering an approach, now widely being adopted in the industry today, Open Banking became a natural extension of the existing digital channels strategy. Figure 2 shows a simple illustration of MPLbankâ€™s architecture, and the new channels in place for PSD2.
How did the MPLbank team achieve this? And do so in a matter of weeks, not months?
Open Banking at speed with API Connect and z/OS Connect Enterprise Edition
There were two key technology enablers that allowed the MPLbank team to provide secure and timely Open Banking Services: IBM API Connect and z/OS Connect Enterprise Edition (EE).
Having previously established an API interface to support their mobile channel, MPLbank extended their API Connect implementation to form an enterprise-wide Banking API Platform, suitable for both internal and external API consumers. In the process of extending this API platform, new services were introduced to satisfy those requirements for the XS2A, AIS and PIS elements of PSD2. The inherent capabilities of API Connect enabled new APIs to be rapidly defined, governed, secured and published for TPPs to discover and consume.
At this stage, a number of options were available to the MPLbank team to integrate API Connect with the Accounting and Payments Systems. One option was to re-use the existing integration fabric; however, MPLbank elected to use z/OS Connect EE to provide APIs directly into the CICS core banking application. This provided two key benefits:
- Speed. Since there is less design, development and runtime effort in transcribing the external API request to the core banking system, new core banking functions can be surfaced far more quickly. The Chief Payment Architect of one major European bank has estimated that, by taking this approach, they save 60% of the time, effort and cost in surfacing core banking APIs to the end consumer.
- Security. IBM z/OS Connect EE provides a security framework that allows customer and TPP identities to flow through the API Connect gateway, and on into the core banking system. This offers huge advantages when reconciling disputed payments, as it provides a single place to identify all parties in the transaction, at the point at which the transaction was run.
The result? Exploiting the API platform alongside z/OS Connect EE, MPLbank developed the following scenario, which sees an MPLbank customer exploiting multi-factor authentication, with the in-built biometrics of an iPad to permission a TPP to access their account, query their account history and initiate payments. You can see this scenario in full in the demo, below.
This article sets the scene for Open Banking, PSD2 and two key technology enablers that have allowed a real-world banking platform to respond at speed. It paves the way for a further two articles, which go deeper into the API developer experience, and the security designs associated with this implementation.
- Open Banking and PSD2 in Practice: Developer-Ready APIs (coming soon)
- Open Banking and PSD2 in Practice: Designing for Robust Security (coming soon)
The era of Open Banking has arrived, but these are early days and it remains an untapped resource. Your organisation is likely responding already; the question is: are you moving fast enough to be the disruptor? Or are you about to be disrupted?