Can serverless fix fintech’s scaling problem?

Technology leaders in the financial services sector constantly struggle with the daily challenges of balancing cost, performance, and security — the constant demand for high availability means that even a minor system outage could lead to significant financial and reputational losses. Add to this the escalating costs of maintaining legacy systems, which often act as bottlenecks for scalability. 

Therefore, back in 2019, when I served as the chief architect of a mid-size commercial bank I was looking at a few options that could enable the technology teams to continue and deliver value-driven features at a high velocity: accelerating cloud transformation, robotic process automation, business process automation and serverless computing to name a few. The latter option had emerged as a compelling solution, offering the promise of enhanced agility, reduced operational costs, and seamless scalability. 

With serverless components, there is no need to manage infrastructure, and the inbuilt tracing, logging, monitoring and debugging make it easy to run these workloads in production and maintain service levels. The built-in elasticity in serverless computing architecture makes it particularly appealing for unpredictable workloads and amplifies developers’ productivity by letting developers focus on writing code and optimizing application design industry benchmarks, providing additional justification for this hypothesis. McKinsey highlights that serverless architecture enables companies to overcome traditional IT transformation obstacles, offering cost reductions of around 60% and facilitating access to ecosystem functionalities.  

Financial services’ unique challenges 

However, it is important to understand that serverless architecture is not a silver bullet. Specifically, when it comes to financial services, specific challenges unique to the sector need to be taken into account, in addition to other areas to pay attention to. For instance: 

• Regulatory compliance, security and data privacy. With stringent laws like GDPR and PCI DSS, technology leaders must ensure serverless providers support compliance requirements. This includes implementing robust encryption, access controls, and monitoring mechanisms. 
• Cost forecasting. While serverless offers a pay-as-you-go model, accurate cost forecasting is critical to avoid unexpected overruns. 
• Scalability. Managing fluctuating workloads, especially during peak times, demands flexible and scalability management solutions. 
• Legacy infrastructure. Maintaining and upgrading outdated systems can be resource-intensive and hinder innovation. 
• Architecture complexity. Specifically in the managing of a large number of serverless functions. 
• Vendor lock-in. Relying on a specific hyperscaler to provide serverless computing can lead to vendor lock-in, making it difficult to switch providers or move applications to a different hyperscaler. This can limit flexibility and increase dependency on a single provider.
• Limited capabilities for in-depth monitoring and debugging. The black-box nature of serverless components does not allow for granular observability.
• Cold start limitation. The cold start characteristics of serverless components need to be carefully evaluated when implementing use cases — when serverless components are not actively being executed, they are spun down to save on costs. This leads to predictable delays when the component needs to be executed again, as resources get reallocated. 

Putting serverless to the test 

In 2020, we made an architecture decision to leverage serverless architecture for implementing a fraud detection use case. We had a legacy solution that was built on-prem using .NET and monolith patterns with many components reaching end-of-life, with the concomitant high maintenance costs and slow time-to-market for introducing business features. Being aware of the limitations and pitfalls, we made several design decisions to maximize the efficiency of using the serverless architecture patterns. Our cloud strategy was to use a single cloud provider for our enterprise cloud platform — AWS. Therefore, concerns around hyperscaler lock-in were not applicable 

• We did not have a large infrastructure engineering workforce, which drove our strategy towards favoring the use of Software-as-a-Service (SaaS) offerings or Platform-as-a-Service (PaaS) components on our enterprise cloud platform. Although serverless and PaaS are not the same, they do have similar characteristics in terms of not needing to invest capacity and not maintaining computing, which fit right into our approach. 
• To avoid creating too many microservices using serverless FaaS (Function-as-a-Service) patterns, we decided to align to an enterprise capabilities framework to help us define the number of components and leverage a domain-driven design approach. We selected BIAN (Banking Industry Architecture Network) and used many of the out-of-the-box definitions for APIs and microservices. This approach helped us keep the number of microservices to a reasonable number, which enabled us to effectively monitor and maintain those components in production. 

Given this use case was our first foray into serverless computing we decided on a set of KPIs to measure success: 

• Cost efficiency. We compared the operational costs of the legacy system as a baseline with the pay-per-use model of serverless-built application. This included both the hardware cost, the operational staff required to support the solution and the cost of building the features. 
• Time to market. How long does it take to develop comparable features on our new ecosystem compared to legacy. To make sure we are comparing apples to apples we used Agile story point to identify comparable features. 
• Developer productivity. This one was a bit trickier to measure accurately and we decided to focus on code quality and number of successful commits. 
• Operational efficiency. To accurately measure this metric, we decided to look at the number of hours spent on computing-related issues and the number of incidents overall. 
• Scalability. Measured by persistent response time to peak time load.  

The results? 

After deploying the solution into our AWS production environment and letting it stabilize for 30 days, it was time to start looking at some of the metrics. The results largely confirmed our hypothesis regarding some of the benefits serverless computing brings to bear: 

• Cost efficiency-wise, we saw an improvement of about 35%. 
• Time to market got shortened by 15% on average. 
• We detected a big bump in developer productivity, with a 25% increase across the board. 
• Operation efficiency-wise, we did see a steep reduction of 55%-60% in the number of hours and incidents. 
• Scalability-wise, the metrics across the two systems showed parity. 

In a post-mortem, given the favorable results and positive metrics, we decided to add serverless computing as an enterprise pattern and started to leverage serverless architecture patterns and components for additional use cases. 

Serverless computing is here to stay 

Is serverless the one pattern to rule them all? No. Is it a powerful enterprise pattern to leverage on use cases, using architecture guiding principles? Definitely. There is somewhat of a learning curve your technical workforce will need to go through but the benefits and increase in metrics is demonstrable. 

As for the future, I am a big believer that serverless computing is here to stay. Hyperscalers and providers of LLMs and SLMs will continue to work towards abstracting some of the complexities related to running those language models, and serverless commuting is a key technology in enabling that. Furthermore, the latest development in cost-efficiency LLMs with the introduction of the LLM DeepSeek R1 model deployed on Azure container apps with serverless GPUs is yet another testimony toward the potential of adopting serverless computing as an important toolset in your enterprise.

Yaron Yaniv is a seasoned chief architect with extensive experience in the fintech and technology sectors and currently serves as a senior VP and the global chief architect at GM Financial. Yaron has previously held leadership roles at Visa, SVB and Google, where he was instrumental in managing large-scale architecture and engineering organizations and driving digital transformation and innovation. He is passionate about mentoring teams and fostering a culture of continuous improvement, leveraging technology to solve complex problems and enhance customer experiences.

This article was made possible by our partnership with the IASA Chief Architect Forum. The CAF’s purpose is to test, challenge and support the art and science of Business Technology Architecture and its evolution over time as well as grow the influence and leadership of chief architects both inside and outside the profession. The CAF is a leadership community of the IASA, the leading non-profit professional association for business technology architects.