Over the years IT engineering departments have had to deal with many paradigm shifts. Sometimes older ideas come back into fashion, and sometimes technology enables new ways of doing things.

In my role as a Solutions Architect, I work with engineering teams across various enterprises, including many of the larger European banks. As 2024 comes to a close, let's explore some of the major trends I've observed in engineering in financial services, and predictions for how these trends will evolve in 2025.

Today, change is the only constant in FinServ

Before diving into trends and predictions, it's important to understand the context. The banking industry has been facing significant change in recent years for various reasons:

  • Regulations, already extensive, have evolved further following the banking crisis of 2008 and the turmoil in 2023 to ensure the stability of the banking sector.
  • The impact of the Covid-19 pandemic continues to impact us, driving expectations of doing more online.
  • New competition continues to arise, especially from startups that take a fully digital approach and move faster than traditional brick-and-mortar banks.
  • The rise of technology companies has changed how businesses implement and operate enterprise scale solutions. (Will banks become tech companies? - A debate that rages.)

Ultimately, banks must be more agile because the financial industry is evolving at a speed never before seen. To stay competitive and profitable banks need to deliver new capabilities ahead of the competition, while maintaining the strict rules for regulation, security and scale. This means taking a close look at the structure of engineering organizations as well as the technology and architectures used to deliver services.

Prediction 1: The shift to agile will continue

New technologies like microservices architectures, and PaaS and SaaS services, combined with the rise of agile software delivery methodology have driven change in engineering over the past two decades. Modern engineering organizations tend to have small teams (for example, the Amazon two pizza team) that seek to provide deliverables every sprint (typically two weeks), incrementally adding value with each delivery.

However, many banks are still trying to adapt to this new methodology. Historically, financial services engineering departments have been organized to deliver new projects and functionality with a hierarchical waterfall approach. This approach results in long analysis and extensive documentation, and it can take months or years to deliver projects. Much of the focus is on documentation.

Changes to processes which have been built up over decades at banks cannot be altered overnight. In 2025, I predict banks will continue to shift their organization to align with modern practices, gradually changing their processes to fit in with agile development and gain the benefits of microservices architecture.

Prediction 2: Migration to microservices and event-driven architecture will be a top priority

Banks, in particular, have relied on the mainframe at the core of their business to this day. Often services have been extended/created with applications using client/server or a tiered architecture - frequently referred to as monolithic applications. However, using this legacy architecture is not conducive to the new agile delivery methods. Typically the deployment frequency is very low, change risk is high, scaling is non-trivial, and production operations become complex.

I've observed various levels of maturity in the adoption of microservices architectures. New products and services use microservices. Older services remain on legacy products with plans to modernize frequently getting stalled by processes which have been built up over many years. However, as more teams want to benefit from modern architecture and methodologies, we will see these legacy products move to microservices in 2025 and beyond.

Prediction 3: Platform teams will be critical for modernization success

A well-written microservice will follow the 12-factor principles and address a specific domain problem, which ultimately results in many microservices being used to deliver a business process. Providing a run-time environment that ensures availability, scalability, security, and the communications needed for thousands of microservice instances is a non-trivial task.

Platform teams have evolved as a critical part of engineering departments at banks to handle the increased complexity of the engineering environment. They must create a stable, easy-to-use, secure microservices environment to let engineers deliver application-ready services. Often using DevSecOps concepts to automate the management of these complex platforms.

Platform teams will be critical to the success of banks in 2025, as they expand the use of microservices. Platform teams must ensure they treat the platform as a product with a full lifecycle. They will need to add new capabilities to the platform in line with market trends, developer needs, architecture changes, improved security, and new technologies. Older functionality may be replaced by more elegant and customer-friendly solutions to make developers more successful.

Prediction 4: AI usage will expand

Any view on recent trends in technology has to include a reference to Artificial Intelligence (AI) and its subset, Machine Learning (ML), which are permeating everyday life. AI technology is still fairly nascent, but is of great interest to financial institutions, particularly to improve customer experience, security and efficiency. For example it can be used in:

  • Fraud detection - analyzing spending patterns and identifying unusual transactions
  • Credit scoring - analyzing customer data to provide more informed credit decisions
  • Customer support - AI powered chatbots and virtual assistants
  • Investment strategies - studying investment opportunities

AI developers must consider two sets of critical processes to deliver value to the business. Firstly, they have to consider how to build up Large Language Models (LLMs) and to train the AI applications in using the data and keeping them current. Then there is the consideration of using the data to deliver business value, this often means developing processes that chain together multiple AI applications or look to enhance the AI answers with data from other sources - Retrieval-Augmented Generation (RAG).

AI and ML developers often bump into rough edges of system orchestration as they look to build these processes. Ideally an AI developer wants to focus on the models, training and data flows. They don’t want to have to think too much about failure scenarios, consistency and scheduling.

AI is clearly a major trend happening in all industries, and as it matures we will see expanded usage in Financial Services in 2025.

Microservices enable business agility and ease of scaling, but as microservice usage increases, so does complexity. Platform teams help manage that complexity. However, engineers still encounter issues. As banks adopt microservices, they are more frequently running into the various challenges.

  • Transactional integrity may be at risk. In monolithic systems we had the option of using Global or XA Transactions, which would allow us to have a high degree of confidence that a commit has occurred to two or more persistent resources. In a microservices world, the services should “own” only the data they use, and are generally accessed using web protocols. This means two-phase commit is not an option. Developers must then implement rollback or compensating transactions (often using the Saga pattern). Having the certainty of completing transactions or successfully compensating is critical to Financial Services.
  • It’s difficult to understand and manage business processes. Business processes frequently involve multiple services being chained together to ensure client requests are fulfilled. There are several strategies to accomplish this, each with their own drawbacks:
    • Microservice-to-microservice calls. Microservices can propagate context/control between microservices. However, this ends up with business logic scattered in many locations. Inadvertently, the microservices can have dependencies between them, leading to fragile systems where updates are risky to implement and end-to-end testing is difficult.
    • Central choreography service. Some teams introduce central services to coordinate all the microservices, but that central service can become a performance bottleneck or introduce functional limits on the business logic that can be defined.
    • Event-driven architectures. Some teams have elected to make the data key to managing the process and are using Event Driven Architectures, where every event gets put onto a queue and those interested consume the event to perform processing. Tracking the status of any given business then means understanding many different services and querying the data to observe progress. It is very hard to follow, and full end-to-end testing becomes labor-intensive.
  • Business processing is mixed with system error handling. Complex business logic can become obfuscated by the need to add system logic performing retries to handle failures.
  • Observability is challenging. With the business logic implemented in many microservices, it becomes hard to observe the status of a business process.
  • Reliability is challenging. If a component fails while processing a request, it can be difficult to ensure that this request is processed and not lost.

Many engineering teams at financial institutions understand the issues with microservices, but the benefits outweigh these problems. The ideal answer is to implement solutions to make microservices work better. This is where new, code-first workflow technologies can solve many problems. In 2025, I predict more banks will realize the need for code-first workflow technologies and begin evaluating and implementing them.

FinServ organizations need to modernize legacy services to deliver new capabilities at the speed expected by customers. Implementing the modern technologies following many of the trends mentioned in this post will help in this journey, but there are a lot of potential pitfalls in creating a golden path to production.

By empowering developers through a workflow-as-code approach, Temporal unlocks the value of microservices and resolves much of the complexity associated with distributed systems. It makes mission-critical services more reliable, and lets development teams rapidly build complex systems and AI applications.

To find out how Temporal achieves this, check out the following: