Joel Van Arsdale and Nick Telford-Reed (Stormglass Consulting) • 26 November, 2021

A Practical Vision for Payments Platform Rationalization

This article was originally published by The Paypers.

Introduction

Winning in the payments industry increasingly depends on having high-quality, agile technology. In parallel, growth in payments is often driven by M&A. Executing ongoing integration projects while maintaining high availability and reliability and avoiding platform fragmentation is a challenge for even the most seasoned payments companies.

Platform fragmentation can stifle product innovation and limit EBITDA potential. In the last five years, we observed a consensus vision emerge on how payments companies can rationalize platforms without disrupting business growth. We summarize this vision below, noting that this is a simplified, business-level perspective.

Many global payments companies are in the situation of having many acquired platforms as illustrated in Figure 1. Despite best intentions, most of these tech stacks remain in relative isolation for years. But having many siloed platforms is not sustainable - they block scale benefits, encourage technical debt, and often lead to negative customer impacts and satisfaction. 

FIGURE 1: M&A Drives Platform Fragmentation
FIGURE 1: M&A Drives Platform Fragmentation

Source: Flagship Advisory Partners

An Emerging Industry Consensus

The first step in effective platform rationalization is to establish a clear strategic vision, where we can see an emerging market consensus around orchestration (as simply illustrated in Figure 2).

A strategy to rapidly force-migrate everything onto a singular tech stack is impractical. Given the luxury of a complete business freeze, this vision could be achieved, but payments businesses are highly dynamic. Customer needs/impacts and revenue growth trump technical purity and operating efficiencies. Even with strong rationalization strategy and execution, acquisitive payments companies never achieve platform singularity.

Ongoing support for siloed, acquired platforms is also clearly sub-optimal. Many companies will likely compromise here along the journey to full consistency. Other than being an acceptable interim vision, a siloed approach destroys value and is not long-term feasible. 

The consensus vision that we see in the market is one centered around orchestration, in which the various front-end integration layers and the various back-end services are integrated via common data and services hub. While we describe Figure 2 as alternatives, it is more practical to see these as rather milestones along a platform journey. In the first step on the journey, platforms stubbornly persist in silos. An achievable mid-point is orchestration. Finally, as a financial objective, a one platform vision can be a business wish. However, few businesses achieve this final state as the pressures of feature development and further acquisitions are brought to bear. Instead, a constant state of pruning redundant services as new ones are introduced becomes a pragmatic compromise. 

FIGURE 2: Platform Rationalization Alternatives
FIGURE 2: Platform Rationalization Alternatives

Source: Flagship Advisory Partners

Orchestration (many-to-many architecture as illustrated in Figure 3) offers a number of advantages vs. singular/linear platform architecture:

1.    Orchestration allows for services access and interoperability across a company while avoiding

       the duplication of every application/service needing to collect 1-to-1 with every other

       application/service.

2.    If well engineered orchestration can be largely behind-the-scenes and opaque to customers. 

3.    A well-build orchestration hub is built to manage a range of service requests.

4.    API based applications/services naturally lend themselves to being orchestrated.

FIGURE 3: Orchestration Led Platform Rationalization
FIGURE 3: Orchestration Led Platform Rationalization

Source: Flagship Advisory Partners

 The challenge with orchestration is establishing the target services hub and related data architecture. If you are lucky, one of your acquired platforms is natively adapted to orchestration. Unfortunately, this is rarely the case with platforms that were built 10+ years ago. Building or buying the hub is often required. An orchestration hub must be married to a data architecture that can provide consolidated reporting and a foundation for migration of the various datastores in the donor platforms.

A Journey Towards Platform Rationalization

With the vision established, the next step is to develop a plan to guide the execution journey. Figure 4 illustrates one possible high-level roadmap, noting that there are many limitations and dependencies that drive the right sequencing and prioritization. While our vision defines discrete staging, a real journey is always more complicated with many workstreams running in parallel. 

FIGURE 4: Platform Rationalization Journey
FIGURE 4: Platform Rationalization Journey

Source: Flagship Advisory Partners

Stage 1

As an initial priority in rationalizing fragmented platforms, companies often prioritize quick wins, such as enabling product access across the platforms for improved customer offerings (e.g., the ability to access payment methods available on platform #2 from platform #1). Shared access to service does not necessitate disruption of customer/partner interfaces. APIs can be layered using converters/emulators to ensure ongoing API compatibility, with recent developments in API gateways and innovations like GraphQL facilitating this.

In Stage 1, we strongly recommend the creation of a common culture and ways-of-working across the technology organization (which can still allow for different teams to be leveraging different coding foundations). Successfully uniting multiple business cultures is difficult and has the potential to destroy value quickly if done badly. In addition, for legacy on-prem infrastructure organizations, moving to a cloud set-up can exacerbate these cultural challenges.

Finally, but most importantly, we recommend establishing the target data infrastructure as soon as possible and then working to migrate data stores. Siloed data is a major roadblock to driving later stages of platform rationalization; conversely data integration enables a consistent customer view, driving better, easier customer experiences. 

Stage 2

In Stage 2 of the rationalization journey, we generally see migration of services/applications which are easier to move, and where standardization enhances operational and product continuity, for example, implementing a common tokenization service, ID management or fraud management.

At this stage, we often see companies focus on moving to a common accounting (and possibly billing) systems, improving customer experience and executive management of the business (measuring performance, etc.). Migrating to a common billing system can provide revenue upsides via broad execution of pricing strategy. Finally, migrating to a common hosting infrastructure often occurs in this stage given the natural cost savings; noting that migration from physical data centers can introduce roadblocks that extend this timing (for example, if the organization is not yet cloud ready but where the target infrastructure is in the cloud).

Stage 3

Stage 3 of the journey often involves heavy lifting of the more challenging systems to move. For example, we might see migration of core processing (e.g., V/MC auth and clearing), which can offer significant cost savings. Also, at this stage of the journey, we often see migration to a common treasury and settlement infrastructure as well as migration to a common customer onboarding and compliance systems. Standardizing onboarding and compliance systems can be difficult if your business operates across many countries, but fragmentation of this function creates compliance risk and fragmentation of onboarding services becomes expensive.

Stage 4

The final stage of the rationalization journey then involves the sunsetting of legacy customer interfaces and migration of payments connectivity. Interface migration impacts customers, which is why this tends to come late in the process. At this stage, companies can offer clear customer benefit through improved product functionality, helping to ease the burden of customers having to migrate to new interfaces, new data services, and new servicing environments. Payments connectivity migration is painful (driven principally by the need for recertification) and almost always comes last. In fact, it can even be practical to effectively never migrate connections, but rather to simple rebuild them in the natural course of the dreaded compliance or “card scheme mandatory” releases.

A Long Journey

As a CEO or CFO, our vision for platform rationalization as a journey taking years can feel uncompelling. As illustrated in Figure 5, most of the cost sy nergies are delivered at the later stages of the journey. We view these backloading of cost savings as often unavoidable given their dependency on retirement of systems which are also the most challenging to migrate. When formulating a platform rationalization strategy, we like to prioritize continuous progress and pace along the journey while also avoiding pitfalls such as customer disruption. Financial results always matter, but patience is required when delivering platform synergies. 

FIGURE 5: Value Creation via Platform Rationalization
FIGURE 5: Value Creation via Platform Rationalization

Source: Flagship Advisory Partners

For payments companies fueling growth with M&A, platform fragmentation is an unavoidable challenge. Business leaders must attack this challenge head on; platform fragmentation cannot be kicked down the road. Our vision for platform rationalization, informed by a growing market consensus on the topic, is centered around orchestration: a many-to-many architecture, wedded to a well-planned roadmap with steady, realistic executional progress, and underpinned by a coherent integration of people, teams, and culture.

Please do not hesitate to contact Joel Van Arsdale Joel@FlagshipAP.com with comments or questions.