How will Banks organise themselves to manage APIs built for PSD2 / XS2A?

The PSD2 is here.  For those who don't know what that is, it's the European update to the Payment Services Directive (PSD) of December 2007.  The original PSD aimed to harmonise the European payments markets and make the Eurozone behave as a Single Market.  It achieved some of those objectives, but the update goes much further and was adopted in October for implementation in 2017. 

The big deal in PSD2 is Trusted Third Party Account Access, which are represented by two acronymns: Third Party Payment (TPP) under the Access to Accounts (XS2A) rule.  I wrote about those things back in September, and the key part of PSD2 and XS2A is the introduction of open APIs.  What does this mean?  I could write an article about that, but I found one that explains it well by Paul Rohan, an independent advisor on payments regulation.  Here's Paul's view:

How will Banks organise themselves to manage APIs built for PSD2 / XS2A?

Though quite technical in nature, APIs developed by banks for PSD2 will not be a routine IT Management issue within Banks. An API is not a piece of software, so the IT team that manages a bank's software is not a logical choice to manage the PSD2 API suite.  Software isn't an API, though it can be presented as an API to enable third-parties to use the software's capabilities.  The IT team that currently supports internal Users within a bank is not a logical choice, because an API is not a user interface.   The IT team that manages a bank's servers is not a logical choice, because a server is not an API (although a server can host APIs that expose the functions provided by the server).

As PSD2 is a pending legal obligation common to all EU banks, it is likely to arrive as an issue into a bank's prioritisation and resource allocation processes via a bank's Compliance department.  However, the key decisions arising from PSD2 need to be handled by the team that manages a bank's pursuit of comparative advantage.  This is because the Open Banking Technical Standards likely to be agreed by the EU regulators and the banking industry will have several layers.  The first layer of standards will deal with Basic PSD2 Compliance.  On top of that layer, there will be an Industry Rulebook layer that caters for disputes, liabilities, rejects, returns, refusals, refunds etc.  The third layer of Open Banking standards will consist of Additional Optional Services.  This is the competitive space where banks can provide superior APIs in pursuit of comparative advantage.  As banks will incur costs from Basic PSD2 Compliance, this is the layer that can deliver a commercial return  from PSD2.

Before a bank embarks on the post-PSD2 regime on a daily basis, it must first make strategic choices on how many commercial roles it wishes to play within the new PSD2 regulated ecosystem.  Obviously, a traditional bank is being positioned by regulators to act as an Account Servicing Payment Services Provider (AS PSP).  Fintechs are the obvious and planned Payment Initiation Service Providers (PISPs) and Account Information Service Providers (AISPs).  However, a traditional bank also has a commercial opportunity within the PSD2 regime to pursue comparative advantage by also acting as a PISP and/or AISP, instructing payments and/or sourcing account data from accounts held by their customers at other AS PSPs.  Indeed, an AS PSP may find useful aggregations of data available from AISPs that it could pull into its recurring business processes via APIs.

Once the key strategic decisions are made, the Open Banking API Suite becomes a daily commercial process for a bank in this new world.   The most logical team to carry this responsibility seems to be a bank's traditional Product Management function.  An API has many of the same commercial characteristics as a traditional bank-branded product delivered through a bank's own branded channels.  A bank will have to design APIs to be attractive to the intended developer/user, whether the API is designed to achieve Basic PSD2 Compliance or achieve comparative advantage as an Additional Optional Service.

When an API is developed an Additional Optional Service, three questions probably need to be asked:

• which Third Party PISPs and/or AISPs are the intended developer/users?
• how is the bank going to manage the engagement with the PISPs/AISPs around the API?
• what is the contractual basis for the engagement with the PISPs/AISPs?

While specific to the API Suite built for PSD2, this is the sequence of segment?/channels?/pricing? questions that traditional bank Product Managers ask about a bank's own-brand products on a recurring basis.    This probably answers the organisational question for banks.  Whether today's Bank Product Managers have the training and technical skillset to make commercial decisions about APIs alongside the traditional own-brand products is a separate question.

If you have further questions about the PSD2, the European Commission has a useful FAQs section here.