Enterprise ready open banking: API Infrastructure for the future of finance

Larger clients have very specific needs. It’s not just about higher volumes of API traffic or lower tolerance of failures and errors. Larger clients also often have aggressive expansion plans or performance requirements. So what components are necessary for an Enterprise ready open banking partner?

What is an enterprise-ready platform?

Enterprise clients operate in a financial landscape that’s ‘always on’ 24/7, is highly sensitive to downtime, and, of course, highly regulated. Consequently, their financial infrastructure needs to be equipped to handle this.

The Yapily platform meets these exacting standards and complex demands. That’s what we mean when we say it is Enterprise ready.

We understand that larger clients need more than just API functionality. Being Enterprise ready demands an underlying platform and infrastructure that enables your business to reach its growth goals and protects your customer experience.

It is these non-functional requirements (NFRs) that are equally or more important to support the scalability, reliability, throughput, security, and performance of your business.

In this article we will describe how we address these concerns and the Enterprise grade technical solutions within Yapily’s platform that have been built specifically to meet Enterprise requirements.

Key considerations for a scalable open banking platform

Mentioned in this section:

  • Cloud native infrastructure
  • Microservice architecture
  • Vertical and horizontal scaling dynamically
  • Operational efficiency to control costs

Yapily’s technical infrastructure is barely older than Open Banking itself. It has been designed for scalability from the ground up, including being cloud native from the beginning.

There are no ‘bare metal’ machines, on-premises servers or data warehouses to physically maintain. That means we can deploy and extend resources to the cloud as and when required.

Vertical scaling is easy as we can increase our computing power or memory to our machines dynamically. We can also horizontally scale by adding more machines, nodes or clusters too. This is easily orchestrated and managed using Infrastructure As Code (IaC) tooling.

Both of these scaling strategies, combined with a microservice architecture, are very powerful as this compartmentalisation of different functions and responsibilities means we can scale individual parts of our platform independently and distribute load efficiently. This can even be automated to adjust dynamically based on current API traffic and resource usage through platform telemetry and monitoring. This offers nearly infinite growth potential.

By running these as a managed service with Yapily as an infrastructure provider, Enterprise clients are not liable for our operational costs. Yapily manage all the complexities of platform performance optimisation and efficiencies on your behalf.

By choosing Yapily as your Open Banking Infrastructure Provider (OBIP), you can expect fully managed services, continuous and seamlessly scalability. That way, our clients can concentrate on integrating their product to the API. No additional technical complexities, development work or unexpected costs.

Availability and Reliability - the key to enterprise open banking

Mentioned in this section:

  • SLAs
  • Uptime vs service availability
  • Monitoring, alerting and tracing (observability)
  • Change control
  • Incident management
  • Disaster recovery / BCP

Service Level Agreements (SLAs) are an important aspect of setting contractual expectations with your API service provider. Reliability is a critical element and it is important to know what is a meaningful metric. Many API service providers will refer to reliability in terms of uptime. While technically valid, it is probably not the critical service assurance you may assume. In fact, it’s surprisingly easy to keep an API gateway available almost 100% of the time.

The real assurance you need is that the underlying services are working. So even if you can technically call their API, you may not be able to perform essential services such as making a payment or receive unexpected errors. In addition to quoting uptime as part of our SLAs, we also monitor our service availability.

We believe this holistic approach gives you a more meaningful measure of the service we provide. This includes every component of the end to end (E2E) pathways, from client API requests, through all our internal service calls, out to an ASPSP (e.g. bank) and all the way back again.

From a monitoring perspective this involves building telemetry to collect metrics about the health of every microservice in our platform, primarily using Micrometer and feeding these into Prometheus. We then visualise this status through Grafana dashboards. Typically, we focus on three key metrics related to error rates, throughput and latency. By looking at microservices separately and also combined with their respective functional flows means we can quickly detect and resolve problems. We are also able to trace single requests through this microservice architecture using distributed tracing with Zipkin.

This also supports our change control process and how we deploy new changes to production. The microservice architecture allows us to distribute risk and make small changes frequently without downtime, helped by a modem CI/CD stack including BitBucket pipelines and ArgoCD including using modern techniques such as incremental rollout e.g. feature toggles.

Even with the best intentions, we all know that things can still go wrong.

Our disaster recovery or business continuity planning (BCP) is where we actively think of worst cases scenarios that could impact our platform and how we would maintain service.

This can go to the extremes of recreating the entire platform on the fly in another cloud location using Infrastructure as Code (IaC) solutions such as Terraform and Helm. This also extends to other platform concerns such as data storage by using replication and high availability solutions built into our solutions such as PostGreSQL and Redis.

Despite our very best efforts, we all know things can still go wrong. That’s where our incident management is important. Our dedicated incident manager, response teams and on-call system will act quickly. First priority is to restore your service first and then initiate our post-incident process to identify how we could have done better and prevent the same issue from recurring.

Enterprise-grade security to ensure trust in open banking

Mentioned in this section:

  • Audit / Certification
  • Vulnerability scanning
  • Recognising attacks
  • SIEM / SOC
  • Penetration tests

Security is vital and also complex. That’s why we have a team dedicated to this critical area.

Our strategy is focused in three areas:

  • Identify and Protect
  • Monitor and Detect
  • Respond and Recover

Identify and Protect refers to mapping assets and evaluating their risks and threats. We then look at ways to mitigate those risks with defence tools such as Web Application Firewall (WAF), Distributed Denial Of Service (DDOS) protection, Network Address Translation (NAT), Virtual Private Clouds (VPC), NGAV (Next-Generation Antivirus) endpoint protection etc. These implementations are also thoroughly tested using regular audits and certifications such as ISO 27001 and external and internal penetration tests. We also mitigate risk from a people perspective by training our employees in social engineering attacks, conducting regular phishing exercises and implementing a Secure Software Development Lifecycle (SSDLC) e.g. preventing common OWASP vulnerabilities. We also actively manage our employee’s laptops and devices.

Monitor and Detect Attackers and malicious actors are becoming increasingly more sophisticated and resourceful so the second stage is to detect security incidents on our platform. Yapily uses a Security Information and Event Management (SIEM) system to aggregate and enrich security event data ingested from diverse log sources including applications, network traffic, cloud environments and endpoints to monitor threats and detect behavioural anomalies. With a dedicated 24/7 Security Operations Center (SOC), our environments are monitored around the clock, ensuring that we can effectively respond to and mitigate any security incidents that may arise. This proactive approach is crucial to prevent and limit financial, operational and reputational risks.

Respond and Recover Once a threat is detected, the third and final stage is to respond, remove it and recover the system quickly and efficiently. In addition to the processes and automation outlined, there is also a human element. Yapily has a response team on-call with prepared and drilled Incident Response Plans (IRP) and Disaster Recovery Plans (DRP) that have been devised from activating tabletop drills and ‘war game’ scenarios to test our response.

Summary

There is a lot to think about when choosing an Open Banking Infrastructure Provider (OBIP).

The Yapily Enterprise-ready platform caters to the exacting standards of larger Enterprises by providing an ‘always on’ 24/7 financial infrastructure that prioritises uptime and compliance.

While API functionality is often an important focus, Enterprises will also need some very specific additional underlying capabilities. It is important for companies of all sizes to understand the most important service measures and the questions to ask of a possible provider on performance metrics and security measures.

Yapily’s cloud-native infrastructure, coupled with a microservice architecture, allows for dynamic vertical and horizontal scaling. Infrastructure as Code (IaC) tools enable efficient resource management, ensuring nearly limitless growth potential.

Robust monitoring, alerting, and tracing ensure quick issue detection and resolution. This is used to maintain our service availability, as well as being able to make API requests. Change control and deployment processes are streamlined, thanks to a microservice architecture and modern CI/CD stack. We also have robust disaster recovery and incident management.

Security must be multi-faceted and we categorise our approach into Identify and Protect, Monitor and Detect, and Respond and Recover actions. Rest assured that your business is protected by defensive tools such as Web Application Firewall (WAF), DDOS protection, and continuous audits and certifications.

Yapily’s commitment to addressing these infrastructure concerns makes it a trusted partner for larger clients in the electronics payments industry, ensuring a seamless and secure experience for you and your customers.

In this article, we have only just brushed the surface of these important considerations so if you do have further questions or would like to find out more, please reach out to us here.


Insights

Yapily branded hero image with brand green colour and lines, with the blog title on the left.
All

Nicole Green, VP Product Strategy & Operations

5th December 2024

8 min read

The UK National Payments Vision: What does it mean for Open Banking?

We take a look at the government’s recently published Nation Payments Vision, and provide our take on how we think it can be implemented to drive innovation, competition, and security in the UK payments sector.

Image description
All

Dominick Peter, Senior product manager

11th October 2024

13 min read

Account information service providers: What you need to know

Discover everything you need to know about Account Information Service Providers (AISPs), how they work, and their key use cases. Learn what to consider when choosing an AISP, common misconceptions, and why Yapily stands out.

Image description
All

Yapily

25th September 2024

11 min read

API for bank transactions: how to pick the right one

Discover how an API for bank transactions can give you access to valuable financial data, streamline your processes, and help you make more informed decisions.


Build personalised financial experiences for your customers with Yapily. One platform. Limitless possibilities.

Get In Touch