As of January of 2018, the Competition and Markets Authority (CMA) has mandated the nine largest UK Banks—Allied Irish Bank, Bank of Ireland, Barclays, Danske Bank, HSBC, Lloyds Banking Group, Nationwide, RBS Group, and Santander—to open up their data to third parties using a standard format. The mandate, known as Open Banking, requires that API endpoints be accessible to authorized payment and solution providers. The Open Banking standards are compatible with the PSD2 (second Payment Service Directive) created by the European Union that requires financial services companies to let customers securely share their financial data, even on transactions where only one of the payment providers is based in the European Economic Area (EEA).
The European rules cover a broad variety of payment accounts, including credit cards, as long as they’re accessible online. The Open Banking standard will first cover personal and business “current” accounts—those that facilitate both receipt as well as payments.
the Open Banking standard, as well as technical specifications.
If you’re a financial services provider currently offering or preparing to offer API access as part of Open Banking or PSD2, much of your development process has likely been focused on launching your API endpoints. But Open Banking is the frontrunner to a more open finance ecosystem that we will eventually see all over the world, and there’s much to be said for planning ahead.
Firstly, while your customers may not directly interface with these API endpoints, the availability and responsiveness of these APIs still impact your user experience and brand reputation.
Secondly, this extended ecosystem also presents an opportunity to build an open, personalized and ultimately more customer-centric service of your own. As with any digital experience matter, visibility is key to achieving success.
Here are some pointers on how to get the visibility you need.
Monitor From Every User’s Point of View
As with any Internet and cloud-based service, Open Banking API endpoints should be monitored from the vantage point of your customers. This means collecting data about the performance of these endpoints from where the API calls are being made. In many cases, API calls will be made from end-user devices all over the world, so it makes sense to monitor from global cities. In other cases, API calls to your endpoints will occur from third-party app provider data centers or instances within IaaS clouds such as AWS or Azure. You should have visibility from all those vantage points.
Monitor Both Application Delivery and Network Performance
If you want to see, understand and assure the “experience” that your API endpoints are providing to connected apps and their users, you need to look at multiple layers at once. Of course you should measure end-to-end performance of sample API calls. But you should also look at underlying dependencies such as DNS, Internet paths and BGP routing. Without these layers, you may receive an indicator that something has gone wrong, but no clue as to why and how to deal with it. For example, let’s say that you have a third-party app that is having issues accessing your endpoint—the possibilities for where the problem lies are extensive:
- User endpoint device, OS, browser or plugin
- User Internet access
- User Internet transit path
- Third-party app data center compute, software or networking
- Third-party app IaaS instance
- Third-party app Internet access or transit path
- Security/authentication provider
- DNS providers
- CDNs
Unless you can look at data across multiple dependency layers, it will be very difficult to even isolate the root cause of the issue to a particular provider. With both app and network-layer monitoring data, you can move through your root cause analysis process with confidence.
Use Shared Data for Effective Escalations
Once you have the evidence you need to isolate a root cause to a service—be it internal or external, the ability and willingness to share rich monitoring data is key to efficient escalation processes. Shared diagnostic data is the lingua franca for solving problems across organizational boundaries and especially when the Internet is the boundary between organizations. Without that data, you’ll be subjected to a slow crawl starting with the lowest vendor support call center contractor. With a strong troubleshooting dataset, you can jump several levels to those who can actually fix something. For example, if you can show that API timeout issues are clearly due to packet loss in one of your app provider’s transit ISPs, then you can get to the app provider’s engineers and collaborate successfully to restore service levels to an optimal state.
Network Intelligence for API Monitoring
ThousandEyes delivers Network Intelligence—visibility from every user or service to every app or API, across any network. More specifically, ThousandEyes provides a convenient way to create repeatable, active API monitoring by configuring HTTP server tests to perform a POST with a custom POST body string and custom user agent definition (such as an iPhone), as seen in Figure 2.
ThousandEyes lets you run API monitoring tests from a broad set of pre-deployed IPv4 and IPv6 Cloud Agents in over 150 cities globally, simulating the vantage points of end-users that are calling API endpoints from their browsers. In addition, you or your third-party developers can deploy Enterprise Agents in IaaS cloud instances or third-party developer data centers to run the same tests from the vantage point of back-end microservices.
ThousandEyes monitoring can be configured to include deep Layer 3 network tests that generate detailed path visualization with hop-by-hop metrics so you can easily identify causality of network issues, as seen in Figure 3 and Figure 4. In Figure 3, we see an Internet path visualization from a variety of geographical market locations to an API endpoint that highlights routing nodes with performance anomalies. In Figure 4, we can see that one of the nodes (highlighted in red) is experiencing significant packet loss.
a simple mouse-over of any hop in the path visualization.
Path visualizations and metrics are time-correlated to app/API-layer metrics such as availability, response time, and throughput. By using correlated app and network-layer visibility, you can trace root causes and resolve user experience-impacting issues faster.
APIs are the New Battlefront for Finserv Digital Experience
Most financial services organizations are keenly aware of the millennial disruption index study by Scratch, a subsidiary of Viacom. The net-net of the study from a Finserv point of view is that millennials don’t think very highly of banks and see themselves interacting with cloud giants or fintech companies to manage their money. It’s not surprising then that according to the PwC Global Fintech Report 2017, 89% of incumbent financial services organizations believe part of their business is at risk from new industry innovators.
This makes mastering digital experience an existential matter for financial services companies. Open APIs are a new front in this battle for the hearts and minds of today’s and tomorrow’s consumers and employees. This presents a risk of marginalization to incumbent providers but also an opportunity to add value to their existing applications through faster access to 3rd party services and ultimately the ability to differentiate through their ecosystem.
If your organization is confronting this reality, then you should be investing in visibility to ensure API availability, performance and digital experience.
To learn more about ThousandEyes and Network Intelligence, download the Guide to Network Intelligence. If you want to get a more in-depth walkthrough, request a demo. Or if you know you’re ready to get your hands on deeper visibility today, sign up for a free trial.