If a Fintech uses PSD2 APIs, can a Bank ever switch them off?

Businesses that use APIs need to think about them like any other input in their supply chain.  Risk managers in both Banks and Fintechs probably need to start thinking about the risks associated with consumption of a PSD2 API.

Losing ongoing access to an API is like a business losing a key raw material.  In general, businesses that require third-party APIs in their workflows need to identify alternatives, regularly review their access rights and be prepared for mission critical changes. A Fintech losing access to a PSD2 API could be like Coca Cola losing access to aluminium for their cans or sugar for their drinks.

Banks face significant Conduct Risks from PSD2.  Under PSD2 rules, Banks acting as AS PSP’s must treat PISPs and AISP in a fair way. Banks cannot make PISPs and AISPs who use payment accounts sign any sort of contractual agreement.   Banks cannot force PISPs and AISPs to carry out their business in a particular way.  Banks cannot treat PISPs or AISPs as a low priority, by putting payments from user accounts initiated by PISPs at the end of the queue.  If there is evidence of fraud or unauthorised access to an account, Banks can refuse to take instructions from a PISP or AISP.  However, the PSD2 law says that Banks must give reasons if they refuse.  

We can assume that Fintechs are generally more advanced than Banks in thinking about API risk management.   Many Fintech business processes are assembled by APIs. Organisational processes and data are opened up to partners and customers via APIs.  Without the legacy technology issues that Banks grapple with, Fintech architecture and infrastructure is highly scalable.  They build their business using bottom-up capability.  Fintechs in the EU are now scrutinising PSD2.  Will they choose to be a PISP, an AISP or both?  Do they have the ambition and capital to scale up as an AS PSP?

Banks are probably significantly less advanced in the commercial use of APIs.   They will have to adapt their risk management framework and culture to deal effectively with PSD2 APIs.  Banks have traditionally had a “hub and spoke” organisational model.   The hub contains huge vaults of customer data.   The hub also contains transaction processing engines for products such as payments, accounts, loans and deposits.  The spokes of the wheel are a Bank’s distribution channels. These channels carry the Bank’s brand.  The distribution channels are usually branches, call centres, ATMs, websites, kiosks, mobile phones, tablets and customer relationship managers.

Published API Suites from the PSD2 legislation creates a new risk and dynamic for Banks.   The APIs will be “indirect channels” to market for a Bank.  The Developers that use these APIs will be commercially independent.  However, the design of the services by the Developers is physically dependent on the APIs.   These new services will carry a Bank’s data and a Bank’s reputation for risk management.  For Banks looking to maintain and build trust with their API developer community, how changes are communicated and how access to an API is maintained will be a vital component in market communications.

In broad terms, we can say that there is a lot more at stake when APIs access (or unexpectedly fail to access) peoples’ money.  Money is a very emotive topic for everyone.  The PSD2 APIs that will report on peoples’ money or move peoples’ money are more emotive than any use of the Google Maps API.  A visitor in a strange city can still find their way if an App loses access to the Google Maps API.  If Google Maps API stops responding to their App, a taxi-driver can phone you to get directions to your house.  An App that has an unexpected problem with Google Maps API can probably get up and running with Microsoft Bing Maps without major disruption to customer loyalty and revenues.  Unlike Google Maps API, we can safely say that PSD2 APIs will carry out functions that are crucial to the financial value chain.  Risk managers need to consider the implications of economically vital financial processes being dependent on the new PSD2 API suites.

Under PSD2, a “Payments Initiation Service Provider (“PISP)” is a payment service provider offering a payment initiation service.  This is a service to initiate a payment from a payment account at the request of the user.  The payment account is held at another payment service provider.   As the PSD2 law makers have asked the European Banking Authority to design Regulated Technical Standards that do not dictate either technologies or business models, we can assume that PISPs could emerge to offer payroll services.  The most crucial process in the financial value chain for the general population is almost certainly a wage or salary payment.

In crude terms, a tourist getting lost for 15 minutes when Google Maps API is unavailable is closer to comedy than tragedy.    A family being unable to buy food for the weekend due to an unexpected delay in a wage payment is definitely not a comedy.  The stakes are high.  If payroll payments that rely on PSD2 APIs are disrupted, there can be a long ripple effect.  When wages don’t arrive, loan repayments don’t get made, utility bills are missed and routine spending that turns the economic wheel gets delayed.

Although PSD2 is the law and moving money is a high stakes business, there could be situations where a Bank feels it can abruptly switch off a Fintech’s access to an API.

The risk of a bank’s abruptly switching off a PSD2 API due to legal issues is low. The Regulators’ aim is that the legal environment around PSD2 APIs should not give rise to abrupt cessations of APIs.  Commercially published APIs have legal dimensions that won’t apply to the legally mandatory PSD2 APIs.   There will be no risk that the AS PSP doesn’t have the legal right to distribute the content to appropriate other entities.  This is established within the PSD2 framework.  Customer permission will be operationally recorded within the PSD2 Regulated Technical Standards.   The rights of the Fintech business that is using the API are also set out under the PSD2 framework.  They will be registered and regulated as AS PSPs, PISPs or AISPs (or all of the above).

There is a risk that a PSD2 API consuming Fintech could use data from PSD2 APIs for more purposes than the service agreed with the end user.  This would be a breach of PSD2.  The PSD2 rules explicitly refer to fraud or unauthorised access to an account.  In these situations, we could conceive of a risk that Banks could refuse to take instructions from a PISP or AISP.  A Bank could take a firm line and claim that a Fintech is guilty of unauthorised access to an account if it uses use data for more purposes than the service agreed with the end user.   There are structures under PSD2 for making complaints.  There could be a risk that a Bank could shut down a Fintech’s API access before a complaint to Regulators is upheld.

Fintechs will need to carefully identify if they become heavily dependent on APIs from Banks that are not covered by PSD2. 

Banks will have a lot more ability to shut down APIs when they offer additional services to the PSD2 APIs.  If Banks as AS PSPs seek to differentiate themselves as API Providers, they may offer Additional Optional Services (AOS) within the same technical and operational environment.  AOSs are not a legal obligation for the AS PSP.

For AOSs, the rights and legal considerations for distributing content must be considered by Banks before developing AOS APIs.  For example, if a AS PSP is distributing data from a customer’s foreign currency payment account under PSD2 rules and also distributing a dynamic stream of foreign exchange rates as an AOS, the market data could actually be owned by Reuters or Bloomberg.  Distributing this data outside the enterprise as an AOS without permission could have significant implications.   Banks will probably need a Rights Management policy, to ensure that it does not repurpose content that it does not own.  A change in a Bank’s interpretation of its rights could give rise to a situation where AOS APIs are abruptly unavailable to a Fintech.  

In the AOS arena, Banks will probably have to make decisions on any trademark or branding constraints.   For example, the Twitter API restricts the API consumer from using “Twitter”.  The name is reserved for Twitter’s branded strategies.  Banks could take the same view.

With AOSs, a Bank’s existing Privacy policies also come into play.  AOS APIs will have to take into account a Bank’s overarching privacy policies. A change in a Bank’s Privacy Policies could give rise to a situation where AOS APIs are abruptly unavailable to a Fintech.

Banks could be very sensitive to perceived misuse of PSD2 APIs when they go live for the first time.  Consumers of APIs usually don’t intend to misuse content or services. In some cases, Banks could fairly or unfairly perceive bad intent from a Fintech.  If a Bank perceives misuse and does not respond to it, they could be in a weakened legal position if they choose to take action later. Bank inaction in the face of known Fintech misuse could be considered “implied consent.”  In that environment, there is a possibility that APIs could become abruptly unavailable to a Fintech.

Lack of access to a PSD2 API to initiate a payment would mean the Fintech would have to do one of two things.    Firstly, it could try to find a substitute API with similar capabilities.  However, it will take time for a customer to switch their payment account to another AS PSP.  This assumes that the customer is happy to make that change in order to continuing to use the Fintech.  That does not seem to be a viable contingency option.  The reality is that the Fintech would need to close off features (and therefore lose revenue) from the disrupted API-enabled service.  The real contingency for the Fintech is to stop charging the end user and to understand why they lost access to the PSD2 API.  For a Bank to manage its Conduct Risk, it will need very active Developer Community Management in these situations.

Public APIs cause a broad risk profile for Banks because they are usable by third parties that do not necessarily have a wider business relationship with the Bank.  The PSD2 APIs are very high profile due to the Regulatory intervention.   They can be a potent source of “delegated R&D” to a community of developers.  The enforced stimulus from PSD2 could give rise to new revenue streams, sometimes from unanticipated segments or partners.  However, the increased reach and increased volume from Public APIs increase a Bank’s overall risk profile.

In conclusion, Partner APIs could be a “soft launch” for banks’ risk management of Public APIs.  Partner APIs are used to facilitate integration of software between the company and chosen business partners.  They are supported by specific contractual agreements.  They can also be framed with specific risk management and dispute management procedures.  Partner APIs could be a staging post for Banks on the journey to Public APIs enforced by PSD2.