Five Common Fintech Integration Challenges– and Best Practices for Addressing Each One (Challenge 3: Middleware Selection)

Middleware is the engine behind every fintech integration strategy. It comes with decisions such as whether to build or buy as well as how to vet middleware vendors and service providers. Making the right decision enables fintechs to scale quickly while getting it wrong puts their business at risk. In this third of a five-part blog series , I’ll share my team’s unique knowledge in this area and their recommendations on how to make the right middleware selection.

Middleware Overview

In some cases, fintechs choose to build their own middleware and service it internally or with the help of a partner. Most fintechs, however, prefer to leverage external middleware products and service providers. Selecting the right middleware is difficult and the consequences of making the wrong choice can be painful. Understanding how middleware has evolved and the types of solutions available today is a helpful starting point.

?

Legacy Point-to-Point Solutions

With the legacy point-to-point approach, custom code installed on one server communicates with software on another one.?

?

The legacy point-to-point approach often proves brittle, which is why it’s frequently referred to as “spaghetti architecture”. Maintenance and updates require a few key resources with tribal knowledge, which results in schedule delays and an inability to do things at scale. Some middleware providers still use this approach but prefer not to tell you. A fintech CEO told me that he once rejected a middleware provider because when he asked them how they managed change requests or new features, they told him that each one was effectively a new engineering project.

Enterprise Integration Platforms

Enterprise integration platforms each contain a proprietary stack with their own connectors. Some fintechs choose to standardize on one of the leading platform vendors such as Tibco, MuleSoft, Informatica, Boomi, or Workato to name a few.?

Standardizing on an enterprise integration platform and building with sound architectural principles can introduce a comfortable level of stability, speed, and scale. It also requires you to use the vendor’s proprietary technology stack, which introduces the risk of vendor lock-in and the need for specialized resources. For Fintechs, looking for a nimble and scalable integration approach, investing in an enterprise integration platform could either fit their needs or feel like introducing a pickup truck to a motorcycle race.

?

Open Source Microservices Architecture

More middleware solutions are beginning to leverage open-source technologies such as Kubernetes, a layer that acts as a resource manager. Out of the box, Kubernetes can allocate CPU, schedule tasks, and monitor the health of services. When combined with an effective mapping and orchestration solution, Kubernetes can be quite powerful. As a result, instead of buying proprietary software, many organizations are building integration solutions that leverage a microservices architecture and Kubernetes to orchestrate integration services.

?

While open-source solutions are often cost effective, they also require a variety of skilled resources to manage different components. Where traditional integration platforms have evolved from years of research and development, providers of open-source solutions may still be learning as they go, not only in terms of technology but also the operating processes required for a stable platform.

?

AI in the Middle

Middleware is rapidly evolving to include intelligence in the middle, enabling required changes to occur on the fly.?

Instead of abstracting systems with static interfaces as in many of the previous middleware examples, this approach enables interaction with AI agents fronting target systems. This provides a dynamic, robust, self-adjusting system that can adapt to new requirements as fintech features evolve. The result is a dramatic reduction in time, effort, and cost, especially when it comes to refactoring and deployment.

?

Middleware Selection Challenges

The process for selecting the right middleware vendor comes with numerous challenges. Understanding and planning for these, increases the likelihood of making the right decision and avoiding unnecessary risk.

Vendor Landscape

The sheer number of integration vendors and the range of their offerings makes fintech middleware selection challenging. The leading enterprise integration platform companies offer specific technical capabilities such as data management, API development, or business process automation, which may or may not be a natural fit for specific fintech use cases. Some vendors focus specifically on financial services integration and may be better positioned to understand and deliver fintech use cases. The challenge is to make sure that their offerings are as robust and reliable as the more established enterprise integration platform companies. Today many middleware vendors advertise AI as part of their offering. Understanding how they use AI, its potential relevance, and the balance of risk vs. reward further complicates the middleware vendor landscape.

Overall Stability?

With middleware, stability is a concept that extends beyond just platform uptime SLAs. Stability also translates to things like the responsiveness and quality of the vendor’s support team including their willingness to do more than just validate whether or not their platform is not the root cause of an issue. Arguably a middleware platform’s stability is also based on the validity of what the vendor promised during the sales cycle. If the vendor pitched features that don’t really exist, or outcomes that they can’t deliver then this misalignment is also inherently unstable. Stability means that the middleware will deliver everything it is supposed to in a comprehensive and meaningful manner.

?

Staffing Requirements

Middleware requires specialized resources that can be costly and difficult to find. Fintechs must determine whether they will take on ownership of the middleware solution and delivery of the integration projects or outsource these things to vendors.

?

Schedule Alignment

Rapid time to market is important for fintechs who want to quickly onboard as many new customers at a time as possible. When working with a middleware vendor, however, fintechs are entirely dependent on that organization’s resources and processes. Schedule delays typically occur in the following phases:

1. Time gap between contract signature and the project kickoff meeting.
2. Time gap between requirements definition and the start of hands-on technical work.
3. Diluted staff allocation resulting in multiple implementation delays.?

?

Total Cost of Ownership

It is often difficult to determine the true costs of a middleware solution. License models can be confusing especially since middleware vendors frequently update them. Traditional SaaS models charge license seats while recently there has been a broad shift toward consumption-based pricing. Customers often find that it takes patience and repeated inquiry to understand exactly what the vendor is charging and whether they will incur hidden costs over time. Apart from the license fees, the cost of implementation, training, support, and managed services must also be considered.??

?

Middleware Selection Best Practices

As someone who has sold, bought, implemented, and used middleware I’ve seen the disconnect that can happen between sales promises and the post-sales experience. To avoid this kind of risk, fintechs should subject vendors to a level of review that extends beyond typical due diligence activities.?

?

Consult Independent Integration SMEs

When reviewing different middleware vendors, fintechs will want at least one unbiased integration SME to be with them on the journey. If fintechs don’t have such a person on the team, then the next step is to find and engage these experts from within their ecosystem. Generally, this can be done at little or no cost.

?

Review Vendor Publications

Most middleware companies have a financial services story and pitch themselves as fintech-friendly. Researching some of their publicly available information takes little time and can be very illuminating:?

1. Prior to sales engagement, review the middleware vendor’s white papers and blogs. It should be easy to determine if they truly understand this space or are simply sprinkling financial services examples on top of their standard messaging.?
2. During sales engagement, take a look at any of their financial services accelerators. Is the vendor providing tools that are applicable to specific fintech use cases, or are they simply taking work product from another engagement and claiming that it will help?

?

Challenge Vendor Sales Promises

During the sales cycle, middleware vendors are going to make some very compelling promises. Fintechs need to challenge these promises in a polite and surgical manner:

1. List Claims. Document each outcome that the vendor pitches, for example take note if they claim that they can connect you to the core at “light speed.”
2. Obtain Evidence. Ask for evidence that they have delivered specific outcomes in the past. For example, ask to see the operating plan that got a previous customer connected to the core at “light speed.”?
3. Interrogate. Ask targeted questions about any artifacts that the vendor shares and dig into any discrepancies. The goal here is not to trip the vendor up but to see if they answer thorny questions with logic, confidence, and consistency.?
4. Validate. For each promised outcome, ask to speak with a customer for whom that outcome has already been delivered. For example, ask to speak with customers who have experienced having the middleware connect to the core at “light speed.”?
5. Take the pain. Yes, this will take more effort, but given the high stakes, it’s worth it. Capable vendors with a proven track record will enjoy responding to rigorous questioning.

?

Scrutinize Demos

At some point middleware vendors will show you a demo. The demo experience is a good indicator of how you will likely be treated once you sign with that vendor. Some key findings that even non-technical reviewers can discern are:

1. Content. Are you getting mostly slideware and very little tech, or a healthy balance of the two?
2. Attitude. Does the vendor seem passionate and engaged with the demo process or are they just trying to get through it?
3. Clarity. Does the demo have a coherent narrative and clear visual examples, or are you being rushed through confusing code snippets??
4. Context. Is the vendor relating the demo to your use case or walking you through a general example of how their product works?

?

Request a Proof-of-Concept

While demos are helpful, proof-of-concept (PoC) exercises are a more effective way to determine if a middleware vendor is a good fit. A PoC should focus on one or two representative use cases that highlight the middleware’s technical viability and showcase how the vendor delivers. The PoC may surface hidden issues such as the vendor being disorganized or understaffed. It can also demonstrate the vendor’s willingness to go above and beyond, for example by converting the PoC into a reusable sales demo for the fintech to share with its prospects.?

Focus on People and Processes

Middleware selection is effectively an integration partnership. Two important components of this partnership are people and processes.

People

The vendor should be able to walk you through a staffing solution that addresses specific fintech onboarding requirements. As part of this, they should explain:

1. How they support delivering multiple concurrent fintech onboarding projects.
2. Whether they have a strategy to deliver at scale, for example by leveraging delivery partners.
3. How their staffing partners perform, preferably including references.

Processes

The vendor should be able to produce detailed documentation on how they provide operational support for fintech customers. Some of these might include their methodology for project delivery, staffing, data mapping, training, maintenance and support.

Back Channel

While reference customers are a good start, vendors probably provide them knowing that they will say positive things. Back channeling enables fintechs to get a more objective view of how customers feel about their middleware vendors including:

1. Their ability to keep promises.
2. Timely delivery.
3. Whether the licensing model is clear, fair, and helpful.
4. Technical stability.
5. If they are committed partners dedicated to their customers’ success.

Two financial services leaders told me that they ultimately selected or rejected middleware vendors based on what they learned about them from their industry peers and from experts in their network.

?

Avoid Common Pitfalls

When evaluating and selecting middleware vendors, common pitfalls can sneak up on you including:

1. Sunk costs. Middleware selection should be based on a high likelihood of potential gains and not in the hope of recouping spend that is non-recoverable.
2. Yesterday’s technology. Some middleware vendors offer solutions that are either obsolete now or soon will be. It is better to invest in technology that will be relevant for years to come than in technology that is increasingly more difficult to support.
3. Vaporware. Sometimes the promise of tomorrow’s technology does not extend beyond a few compelling presentation slides. It is important to recognize when a new technology is mature enough to use verses when it is still at the concept phase. It’s fine to invest in an emerging technology if the vendor is honest about their stage of development and fintechs are willing to take the risk.

Conclusion

Having the right middleware solution is critical for a successful fintech integration strategy but the selection process can be daunting. There are many middleware vendors to choose from and getting the selection process right involves sorting through a lot of history, context, and details. If, however, fintechs work with independent SMEs, learn the lay of the land, and follow some simple rules of thumb, then they can accelerate the process and reduce risk. In the next article in this series, I’ll cover Challenge 4: Building a Delivery Engine.