The payments industry is under significant disruption across the world driven by changing customer demands, regulatory influences, new business models and the advent of innovative new players in the market. The traditional banks are still grappling with inherent challenges of the legacy application landscape that lacks flexibility and agility to change leading to a high cost of ownership and cost of change.
Traditional banks understand the urgent need to re-architect the payments application landscape to adhere to new industry regulations and compete in the competitive marketplace. However, most are struggling to define an approach to take on this complex transformation. And while regulatory compliance is a central focus for banks, the key objective for a transformation should be to build flexibility and scalability for any future needs, rather than building point solutions for regulatory adherence.
Architecture Transformation Considerations – Why Transform?
Traditional Banks are challenged on two fronts. On one hand, the changing customer expectations and the entry of innovative players in the market are driving them to be highly competitive to stay relevant. On the other hand, new regulations are striving for changes that promote more competition and collaboration in the ecosystem. As a result, payment platforms and associated architecture within banks are expected to be highly flexible and scalable than ever before.
Re-architecting the payments application landscape is an opportunity to re-assess the challenges with current systems and processes and redesign them for future use. There are essential considerations to keep in mind when defining the new architecture to meet industry demands. These considerations include flexibility for change, agility for change, resilience by design, scalable on-demand, standards oriented and incorporating data-driven insights. Following a structured transformation methodology can ensure that all these considerations are addressed in the new architecture.
Recommended Methodology for Transformation
Given the unifying trends across the globe, the architecture transformation for payments will typically center around the following key pillars:
- New payments processing with significant straight-through processing capability
- Simplified and flexible architecture that supports faster time to market and seamless support for new customer journeys
- Consumption oriented data strategy centered around future ISO 20022 use cases
- Infrastructure that supports self-resilient capability and on-demand scalability
Based on Wipro’s interactions and engagements with multiple customers, following the methodology below can simplify the approach to payments architecture transformation in a structured manner while keeping these important pillars in focus.
1.Defining Business Outcomes
The first step in the process is to define the business outcomes. Some of the typical areas of transformation include:
- Transforming the core engine capabilities to support ISO 20022, new payment schemes and improvement of straight-through processing
- Customer/colleague channel integration transformation
- Payment system resilience and scalability
- Payment Ops experience transformation
If possible, bring in an outside perspective to avoid the pitfall of building the current process on the new tech stack. It is important to understand the new digital bank’s customer/colleague journeys to understand the feasibility and future possibilities and this is usually best accomplished with an outside perspective.
2.Current State Assessment
While it may be tempting to jump right in and define the target state, it is critical to understand the current state landscape, to ensure the best results. Payment value-chain (segregating as Payments Initiation, Payment Execution, Settlement and Reconciliation, Customer Support, etc.) is a good method to categorize the functionality, systems, workflows and provide a common understanding between business and IT. This analysis should ask detailed questions like what the different types of channels and customer types are, what systems are involved, what is the purpose of each system and what data reports are needed.
3.Defining Target State Architecture
The third step is to define the target state architecture. While the target state architecture will depend on the scope and scale of the transformation, for best results address the four areas outlined below.
a)Formation of product domains
As previously mentioned, one of the main pitfalls while defining target architecture is that many organizations end up rebuilding their current state architecture with new products and technology stacks. The goal should be to address current challenges and redefine architecture for the future. The best way to accomplish this goal is a top-down approach. Apply domain-driven design and product-oriented thinking and reclassify the payments estate as a set of loosely coupled service domains.
b)Addressing payments hub/engine
While most payment transformations focus on the adoption of a new payment engine, it is equally important to take a broader view of the Payment Engine (PE) product strategy while selecting the PE. Some of the key criteria to assess when selecting a payment engine vendor include:
- Payment schemes supported: Does the new PE support all required payment schemes?
- Product strategy and roadmap: Does the PE product roadmap include upcoming models and regulations?
- Data strategy and ISO readiness
- Business Ops enablement: Does the PE provide easier Ops functions?
- Interfaces and integration capabilities: Does the new system include seamless integration to supporting functions?
- Technology strategy: What is the readiness for leveraging a modern stack (Cloud, DevOps, etc.)?
c)Addressing the integration challenge
While the major focus of an organization is selecting a new payment engine, it is equally important to address the complexity of periphery system integration. In some cases, payment engines (COTS products) do not offer open standards-based APIs/interfaces and are not flexible for customized integrations. Ignoring this complexity results in spending more on system integration.
d)Addressing data strategy
Data is the new lever for a competitive edge in the market. Payment transaction data is a valuable source of information to drive intelligent insights into customer spending behavior, patterns, etc. Unfortunately, most legacy systems have siloed data that do not allow rich, real-time, easily accessible information. Develop a data strategy that includes the quality of data and availability of real-time access to information needs in the target architecture. A view of the current and future data consumption use cases upfront will help to define the right data strategy for payments. Many payment transformations will address centralizing the data lake with real-time payments information utilizing event-driven architecture.
Payment operations is a critical function as it handles business-critical processes of the organization. It is important to address payment operations requirements as a precursor to transformation. Consider including transparent operations based on real-time dashboards, predictive and proactive issue resolutions with AIOps, inherent focus on resilience by design by leveraging new technology capabilities like auto-healing, self-recovery, etc. and new ways of working by adopting methods like SRE models.
Benefits of Transforming Payments Architecture
While addressing industry pressures that are pushing banks to transform their payments architecture, in conversations with our customers, Wipro has identified a common set of business drivers that are contributing to the conversation on payments transformation. The strategy outlined above is based on an analysis of multiple customer landscapes. It provides a methodology to approach this complex transformation systematically and provide positive outcomes for large banks to target a resilient, flexible, scalable payments platform for the future.