API performance monitoring is part of managing, and here at APImetrics our mantra is: You have to manage your APIs. And if you are relying purely on passive monitoring of API gateways, you are not monitoring your APIs because you don’t actually know how your APIs are really behaving from the end-user perspective.
Open Banking is a cluster of innovations driven by the new technologies and pent-up customer demand for truly 21st century banking. PSD2 is a EU directive mandating that banks and financial institutions across the European Single Market allow access to their systems for the purposes of enabling payment services.
Banks are conservative organizations reluctant to embrace Open Banking for both technology and business reasons. But for banks in the Single Market, they don’t have a choice about implementing PSD2 – no matter how much they might drag their feet and ask for extensions.
PSD2 is already here.
A common complaint about PSD2 is that there are no standards to implement. The EU’s approach towards open banking is to be technology and business neutral and to let a thousand philosophies bloom. There are published standards such as Open Banking API standards for UK banking, the Berlin Group NextGenPSD2 Framework and the Open Bank Project standards and banks can always develop their own.
Regulatory Technical Standards for Strong Customer Authentication and Common and Secure Open Standards of Communication (PDF) is only 31 pages long, of which only 20 pages are the actual standard. But this isn’t to say that the EU doesn’t have plenty to say about monitoring APIs.
CHAPTER V COMMON AND SECURE OPEN STANDARDS OF COMMUNICATION is the relevant one, specifically Article 32 Obligations for a dedicated interface.
1. Subject to compliance with Article 30 and 31, account servicing payment service providers that have put in place a dedicated interface shall ensure that the dedicated interface offers at all times the same level of availability and performance, including support, as the interfaces made available to the payment service user for directly accessing its payment account online.
Banks are required by PSD2 to measure the quality of their APIs.
And the only way it’s possible to do that is the active monitoring. You can’t do it through passive monitoring because you don’t know if a request has made it to the API gateway and also because you need to know the performance of all APIs not just those that are most commonly exercised.
2. Account servicing payment service providers that have put in place a dedicated
interface shall define transparent key performance indicators and service level
targets, at least as stringent as those set for the interface used by their payment
service users both in terms of availability and of data provided in accordance with
Article 36. Those interfaces, indicators and targets shall be monitored by the
competent authorities and stress-tested.
So “competent authorities” (national regulators) must monitor and stress-test the APIs. And banks need to demonstrate that their APIs meet KPIs and SLOs (Service Level Objectives). Active monitoring is vital to determining what reasonable KPIs and SLOs might be and then to determining whether they are met. Using a third party product or service is going to be both more reliable for doing this and also provide objective data on API quality. Some cURL scripts are probably not going to cut it.
4. For the purpose of paragraphs 1 and 2, account servicing payment service providers
shall monitor the availability and performance of the dedicated interface. Account
servicing payment service providers shall publish on their website quarterly statistics
on the availability and performance of the dedicated interface and of the interface
used by its payment service users.
Banks have to publish quarterly statistics on their websites.
Some of those statistics might well come from passive monitoring, but “the availability and performance of the dedicated interface” by definition requires active monitoring. You can only know the availability of the interface by accessing it from outside as the payment service users will be doing!
It is the performance of the API for those users in the wild that has to be monitored. To do that requires, the API to be exercised regularly by synthetic transactions from locations in the cloud, not necessarily just from cloud service providers, but also from mobile devices.
Article 33 Contingency measures for a dedicated interface continues.
1. Account servicing payment service providers shall include, in the design of the
dedicated interface, a strategy and plans for contingency measures for the event that
the interface does not perform in compliance with Article 32, that there is unplanned
unavailability of the interface and that there is a systems breakdown. Unplanned
unavailability or a systems breakdown may be presumed to have arisen when five
consecutive requests for access to information for the provision of payment initiation
services or account information services are not replied to within 30 seconds.
Again, to detect “[u]nplanned availability or a systems breakdown”, you have to monitor actively. What matters is whether the end user, who is external to your corporate network, is experiencing an outage. If nothing is getting to the gateway, passive monitoring at the gateway can’t detect a problem.
It’s only with active that you understand how an API is really behaving from the end user’s perspective. As we have said, it’s good practice to actively monitor the APIs you are exposing. If you aren’t actively monitoring your APIs, you aren’t managing them. But when it comes to PSD2, it’s not a question of best practice. It’s a question of what is mandated by the EU, the European Banking Authority and the national regulators. It’s something you have to do.
We are currently writing a whitepaper on Building an API Monitoring Strategy for PSD2 and Open Banking. If you would like to receive a copy as soon as it is published, please reach out to us.