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.


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.


Image description


7th June 2024

3 min read

How SEPA Payment Account Access (SPAA) Scheme enhances open banking in Europe

Discover how the SEPA Payment Account Access (SPAA) scheme is supporting the rise of open banking adoption in Europe. Learn about its benefits for Yapily customers and the future of open banking payments.

Image description


30th May 2024

3 min read

Open banking update: May's regulatory shifts amidst upcoming UK General Election

Explore May’s Open Banking update by Yapily, detailing the impact of the upcoming UK General Election on Open Banking legislation and the halt in regulatory developments. Stay informed on how these changes affect the future of financial technologies and industry compliance.

Image description


13th May 2024

6 min read

What is the outlook for Commercial VRP? - Yapily in Conversation

Discover transformative insights in our exclusive interview with Yapily’s CVRP expert, Serenna Cole. Learn how Commercial Variable Recurring Payments can elevate your business’s financial operations. Read now to unlock the potential of CVRP!

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

Get In Touch