payments-transformation-global-payments-white-paper

Fundtech WHITE PAPER

Implementing a global payments system is a journey that every bank

must consider undertaking. This white paper will help banks worldwide

to map out and navigate the optimal route to a major payments project.

Payments Transformation: The Global Payments Journey

PAYMENTS TRANSFORMATION WHITE PAPER

Payments Transformation white paper

1

1. Introduction: The Context for Payments Transformation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . pg. 2

2. Trends in Global Payments Transformations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . pg. 3

3. Preparations for Embarking on a Payments Transformation Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . pg. 4

4. The Global Payments Transformation Program Organization and Management . . . . . . . . . . . . . . . . . . . . . . . . pg. 9

5. Execution for a Global Payments Transformation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . pg. 10

6. Post-Production Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . pg. 12

7. Conclusions and Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . pg. 13

8. About the Authors and Contact Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . pg. 15

9. About Fundtech and Contact Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . pg. 16

10. About IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . pg. 16

Table of Contents



2

Introduction: The Context for Payments Transformation

Today’s banking customers expect—and demand—efficiency, reliability and flexibility when making payments, no matter what service they are using or where in the world they operate. Any bank that fails to carry out every payment instruction quickly and without mishap risks facing immediate negative publicity and severe reputational damage. At the same time, banks are finding that the payments arena has become increasingly competitive, with a growing focus on fee-for-service revenues, intensifying pressure to reduce operating costs, and the need for rapid responses to industry and regulatory initiatives.

Given these pressures, a growing number of banks are setting out on the journey to implement a single, integrated global payments system to support a wide variety of transaction banking objectives. These programs aim to transform a bank’s payments operations by replacing fragmented legacy payments engines with centralized payments hubs at a global or regional level. By definition, this is a complex and business-critical undertaking at the core of the bank—one in which the achievement of friction-free end-to-end straight-through-processing (STP), domestic and cross-border interoperability and seamless integration both within the bank’s applications and externally with other bank systems is key to competitive differentiation and success.

The scale, complexity and criticality of payments globalization mean implementing such a platform is fraught with challenges at each stage, ranging from building the business case, to defining and sequencing the steps needed for a successful implementation, to addressing all key considerations in post-production. To help banks worldwide map out and navigate the optimal route to the future of payments in a transaction banking context, experienced industry specialists from IBM and Fundtech have collaborated to produce this white paper, with the aim of highlighting practices that banks can adopt to successfully deliver a global payments system rapidly and cost-effectively.

How Does “Global Payments Transformation” Differ From Other Programs?

Payments hub implementations are complex and have some unique characteristics, such as:

• Very complex integration requirements, involving numerous internal bank systems (such as internet channels, customer and account information systems, compliance, accounting and so on); highly-regulated external clearing and settlement networks (such as SWIFT, FEDwire, SEPA, TARGET2, G3, and so on); and doing it all on the global scale;

• Performance of time- and mission-critical functions, needing to meet daily cut-off times and liquidity targets as defined by the clearing schemes and regulators;

• Compliance with frequent and, in some cases, massive regulatory changes.

Global payment hub implementations also introduce a number of additional requirements, such as the need to:

• Support multiple languages, time-zones and base currencies depending on the location of branches;

• Support local branch-specific requirements while adhering to the bank’s global policies and guidelines;

• Provide a global, consolidated view of payments and administer access to the various branches’ payments and reference data;

• Provide 24x7 operations – such that while one branch is carrying out its end-of-day processing, another branch at the other side of the world is starting a new day.

As these requirements underline, global payments transformation requires the bank to define a payments business and operational model that will fit numerous criteria. This in turn requires looking beyond the individual projects in the replacement program and approaching the change holistically as an enterprise-level transformation with goals, implications and linkages that impact the entire organization. Put simply, post-transformation, the bank will never be the same again.

Equally important, the transformational impact of moving to a unified, standardized payments hub structure does not end with the successful implementation of the new payments platform. Once a bank has standardized globally on one payments platform and process, it will then open up further opportunities to rationalize and optimize activities and support systems in other parts of the bank such as compliance, foreign exchange (FX) and credit-checking systems.

Key Success Factors: Beyond “On-Time, On-Budget”

Moving to a global payments system represents not just a shift in technology, but a major business change with profound implications across the bank’s strategy and operations. Yet experience shows that payments transformation programs are all too often stalled or delayed by sectional interests, or sidetracked and then shelved because of a shift in management focus to other strategic priorities. The programs that suffer this fate tend to have a number of flaws in common; while conversely, those that proceed successfully to completion share several positive characteristics.



3

In each case, the characteristics that drive or hamper delivery reflect the degree to which the bank is able to look beyond “on-time, on-budget” as indicators of the program’s success. To lay the bedrock for effective realization of the targeted outcomes, the bank should ensure three things:

1. Generate solid management buy-in for the transformation;

2. Empower the project team with the authority and “clout” to drive the program through;

3. Maintain clear and sustained communication across and beyond the program around goals, benefits and progress.

With these fundamentals in place, there are several steps that will determine the ultimate success of the global payments program. Experience and research highlight the overarching importance of developing the right strategy and value proposition, followed by rigorous management of the budget process and process change, and a strong governance regime [see Figure 1].

We will examine all these factors in greater detail later in this paper. But first, we will take a look at the current wider industry trends in payments transformation.

Trends in Global Payments Transformation

The Drivers of Payments Transformation

Payments transformation is being driven by demand from banks’ own clients. Increasingly, bank customers of all types want access to payments services and capabilities that are specifically tailored to their own needs, yet delivered in a consistent and standardized manner across all geographies.

Banks are responding to these requirements by seeking mass-customizable systems—with differentiated fees and charges being a key element—supported by automation and operational standardization, and by productivity aids where full automation is not possible.

This focus has triggered an accelerating transformation in banks’ payments operations in recent years, characterized by payments globalization and convergence through the implementation of payments hubs—a way to orchestrate end-to-end payment flows through all the relevant areas of the bank. Since 2010, around 30 of the top 50 banks globally have engaged in payments transformation programs in one form or another.

Figure 1: Experience Shows that Program Success Depends on a Wide Array of Factors, 2013, IBM Institute for Business Value Survey and Analysis



4

Today, progressive banks are using payment hubs to drive forward their architectural vision of the “orchestrated enterprise.” Turning this vision into reality enables them to deliver their the full suite of payment capabilities to their entire customer base—retail, small and medium-sized enterprises (SMEs), large corporations and governments—regardless of geography or of the channel that the customer uses to engage with the bank.

The Transformation Journey

While different banks use different terms to describe this transformation journey, the characteristics and underlying dynamics are similar. Fragmented legacy infrastructures that have grown up through many years of acquisitions, bolt-ons and customizations will simply not allow the levels of payments visibility and transparency, clearing channel integration, and customer responsiveness required today.

At the same time, the need for change has been intensified by rising cross-border competition from banks based in emerging markets, and growing numbers of multinationals consolidating their strategic banking relationships in search of better payment services. These trends underline the fact that banks that are not competitive in payments risk, losing a significant slice of their wider client business in both their domestic and international markets.

Investments in payments transformation have been further boosted in recent years by the renewed focus on transaction banking following the decline in capital markets revenues from 2008. As a result, payments have become seen as a distinct area of opportunity rather than simply a cost center in a commercial or investment bank.

Preparations for Embarking on a Payments Transformation Program

Using the Business Case as a Program Management Tool

A robust business case for the required investment is a fundamental tool for convincing management and stakeholders why the payment transformation program should be undertaken. Given the scale of effort and expenditure required, the business case represents a vital enabler not only for initiating the program, but also for getting budgets approved at gate-points and sustaining the momentum through to completion.

In this role, the business case balances the costs and business implications of staying with the status quo against the costs and potential benefits of the proposed transformation. It explains the scope and nature of the program, its duration, the resources required, the investment involved, and the benefits it will deliver—revenues, savings, efficiencies and other positive business

outcomes arising from making this investment. These elements are set against the costs of ownership of the existing payments environment, including the opportunity costs of business and revenues that the bank is presently unable to tap into because of the complexity and limitations of the current systems.

Typical factors in the business case include:

• Increased revenues resulting from attracting new clients and achieving faster time-to-market with new offerings, due to new product capabilities and higher flexibility, greater ability to charge for new services, etc.;

• Reduced costs driven by consolidation of systems & operations, reduced hardware and maintenance costs, higher STP, etc.;

Figure 2: Payment Service Hubs - Banks Perspective, 2012, Celent

Benefit Drivers (Illustrative, Not Exhaustive)

Benefit Relatively Easy Relitively Hard Drivers to Quantify to Quantify

• Lower cost of IT • Reduced architectural development and complexity maintenance

• Reduced cycle time and manual processing due to increased STP

• Lower operations cost due to increased STP

• Reduced FTE’s due to centralized operations

• Reducted cost of transaction execution (e.g., more On-Us)

• New chargeable services • Accelerated client for customers on-boarding

• Payment processing • Improved customer insourcing service - uniform channel experience more information, etc.

• Improved fraud and • Improved payment flow anti-money laundering visibility management management

• Reduced error rates • Improved controls

• Increased system • Improved payments resiliency analytics

• Speed-to-market for new • Improved ability to products or channels integrate aquisitions

• Improved ability to respond to regulatory requirements

Revenue retention and enhancement

Risk and liquidity management improvement

Increased agility

Cost reduction



5

• New business opportunities such as entering new markets, expanding to new territories;

• Client attrition due to reputational damage caused by existing systems and poor quality of service;

• Regulatory penalties related to regulatory non-compliance of the existing systems.

• Once it is formulated and approved, the business case can be leveraged as a valuable tool for helping to manage the program and capture value throughout the transformation. The business case should be a living analysis that is updated quarterly or at financial gates and milestones, and burned into financial forecasts and budgets. By identifying and quantifying the key benefits on both the cost and revenue sides, it provides a basis for prioritizing and scheduling different activities and projects

within the program. By helping to bring forward changes that deliver the biggest business and financial benefits, this approach also helps to sustain stakeholder engagement and the program’s overall momentum.

The Target Operating Model: Aligning and Measuring the Business, Technology and Operational Objectives

Global payments transformation involves much more than technology: it also requires fundamental changes to business processes, operations and roles. All these changes need to be coordinated and interlinked to ensure they are driving in the same direction and at the same pace towards the bank’s future view of its payments environment, while avoiding any unintended conflicts, delays or pain points.

Figure 3: A Payments Target Operating Model Framework, 2013, IBM Corporation



6

A first step in preparing for the transformation is for the project team to draw on the reference architecture, Business Requirement Documents and strategic business goals to create a Target Operating Model—or TOM—for the “to-be” payments environment. The TOM plays the critical role of aligning and measuring the business, technology and operational objectives and incorporating them into a clear working model of how the new environment will function, including all moving parts and interdependencies.

Figure 3 shows the key elements incorporated, aligned and measured in the TOM.

In designing and developing the optimal TOM, it is beneficial to use an approach based on a clear framework which supports a consistent end-to-end strategy and operations methodology, and helps to align and measure the various payments business, operations and technology imperatives. Such a framework is illustrated in Figure 3, starting with the payments strategy, and then sequencing and linking the activities around processes, data, process control, organization & governance, people, sourcing & location, and technology. The figure also summarizes the key steps in each of these areas.

The TOM will not only define the operating model of the new payment environment at the bank, but will also include measurements for effective operations and KPIs at all levels of the payment organization, together with ways to measure the KPIs and quality criteria. A key part of the TOM definition is to define and analyze the payments process catalog that includes all the payments operation processes. Each process in the payments process catalog, such as “conduct compliance audits,” has unique characteristics that help determine who, where, when, and how it can be executed in the future state TOM. Examples of process-level characteristics to analyze include:

• Headcount and full-time-equivalent staff performing a process;

• Process location;

• Regulatory requirements;

• Client-facing activities;

• Skill/education requirements;

• Operational risk.

Stakeholder Management: Deliver Early, Deliver Often

A key success factor for the payment transformation program is keeping all relevant stakeholders engaged and on board throughout the duration of the program. A key characteristic

of this type of program is that it has multiple stakeholders from various parts of the organization, including business, operations and technology. As well as differing from those of other stakeholders, their motivations may vary during the course of what will be a multi-year engagement. This is why it is so important to ensure they all remain engaged throughout the program’s entire lifecycle.

Identifying the right stakeholders, and then keeping them committed to the program, can help to drive the program in the right direction and—even more importantly—assist in shaping the organization’s responses if and when problems arise. Experience shows that where payment transformation programs suffer delays, do not meet their objectives or even fail altogether, it is generally the case that the stakeholders were not participating actively in the program and their guidance and commitment were lacking.

To minimize these risks, the program leaders must establish clearly from the start who the most important stakeholders are at all levels across the bank—both within and beyond payments—and then deliver early and often against their various needs. This delivery should include both tangible business benefits in stakeholders’ specific areas of responsibility, and also up-to-date, relevant information on the program’s progress against milestones. Successful programs must have one or more stakeholders who take a proactive role in staying involved, engaged and informed.

A common approach used to sustain stakeholder engagement on large multi-year projects is to deliver new capabilities to the business every six to nine months, thus helping the stakeholders to see concrete business impacts and benefits on a regular basis while keeping the level of organizational change and customer impact at manageable levels. With this objective in mind, the aim should be to deliver tangible results to the business once or twice a year.

Think Big, Start Small, Scale Fast – And Stay Flexible

Given the scale, complexity and timeframe of a payments transformation program, managing stakeholder expectations across business lines, product lines, and geographies is vital to maintain momentum. To achieve this, a useful mindset is to think big, start small and scale fast. This approach can be summarized as:

• Think Big – Create the payments vision and strategy for the enterprise-wide transformation. Show how stakeholders across business lines, product lines, and geographies will be affected, and the benefits they will receive;

• Start Small – Select and execute a meaningful scope of functionality that can be implemented fast—a “quick win.” This



7

quick win should demonstrate value for the entire payments transformation;

• Scale Fast – Prioritize the projects in the payments transformation roadmap such that quantitative benefits are delivered early, in continuous short periods and on schedule. Increase the scope of each deliverable as the organization gains experience;

• Stay Flexible – To maintain the momentum of “scale fast,” be ready to adjust scope, bring features forward or defer features to the next release.

Preparing the Business Requirement Documents

The Business Requirement Documents (BRDs) define the business needs that the new payments system must meet—so collecting and recording this information is an essential stage in defining and specifying the solution. If the BRDs are incomplete or inaccurate, the system will not be fit for purpose, resulting in under-delivery and/or costly remediation and disruption at a later stage. In creating the BRDs, it is important to remember that the mediation and orchestration requirements—along with the surrounding infrastructure—are as important at the pure business requirements in ensuring that the solution meets its business goals.

To make the requirements listed in the BRDs clear and accurate, it is vital that the business, operations, technology and change management resources are all involved cooperatively and iteratively in defining them. The best BRDs are developed through an approach that involves starting with business requirements (independent of the design considerations and system constraints) and then applying progressive refinements from business capabilities to operational features to the specific roles and responsibilities of individual systems.

The business must initiate this process, stay involved throughout, and also approve and sign off on the final elaborated versions of the BRDs to ensure they are aligned with—and can be traced back to—the business requirements as originally stated. While the business’s needs may change over time, or new requirements may emerge, establishing clear definitions early will save time and money later on. It is also important that the BRDs are not filed away and forgotten about: they should be easily referenceable, and consulted through the program to keep the business needs front and center. It is important to remember that changes to the BRD may affect the business case and the scope definition, deliverables and timelines, so these should all be managed through a tight change-control mechanism.

Program Governance: Assessing the Capability and Capacity to Manage a Major Transformation Program

The right governance structure is pivotal to making sure that the transformation program runs in a smooth, efficient and coordinated way, with each participant in the program able to bring its own strengths to bear in support of the overall goals. Although many banks have their own methodology in place for governing major programs, they generally share many common elements:

1. An overarching Project Management Office (PMO), supported by a steering committee that includes the stakeholders and senior management for executing the governance process. With the PMO taking responsibility for aligning the program activities across multiple domains, the steering committee meets regularly to review progress against milestones and take decisions including sanctioning funding for the next phase to begin at each “funding gate.”

2. The main areas that are defined by the governance structure:

• Roles and responsibilities of the various partners: the bank (including the various units that participate in the program), solution vendor and systems integration partner;

• Working processes of the various partners in the program;

• Status reporting and controlling;

• Issues escalation processes;

• Risk management;

• Regular meetings at both project and program levels;

• Financial management;

• Change management;

• Communication plans (internal website, bulletins, etc).

The key to making these governance elements work is to align governance processes between bank, vendor and SI using the ladder principle (where each rung of ladder exists in each process), to have champions and leaders for each major governance area empowered to act, to utilize both formal and informal communication channels up, down and across to keep everyone aligned and focused on the goal.



8

Proof-of-Concept (PoC) or Pilot: When the “Rubber Meets the Road”

Once a bank has selected one or two potential solution suppliers for its global payments platform, there is a growing trend for it to conduct a “proof-of-concept” (PoC) exercise, involving in scope functional and non-functional use cases. The purpose of a PoC is effectively to act as a “bake-off” where the competing solutions demonstrate their ability to address the issues that are important to the bank as part of its transformation. The PoC also gives the bank the opportunity to work closely with the vendor and evaluate the implementation capabilities of the vendor.

To work effectively, PoCs should be tightly-focused initiatives aimed at demonstrating the vendors’ functional coverage of very specific aspects of the desired solution, or their ability to meet unique performance or reliability requirements. By showing what happens when the “rubber meets the road” in key areas, the PoC can help the bank ensure it selects the right solution. Further benefits of PoC include enabling the bank gain a more granular understanding of the product, and providing additional information that can help to inform the implementation approach.

For example, a PoC can clarify what the solution’s rules engine enables the bank to do, thereby indicating how much additional specification and design work will be needed.

It is important for the bank to time-box and limit the scope of the PoC to the essential proof points. If not planned and managed correctly, it may tie up many of the bank’s resources for a long period of time, delay decision-making and postpone the project kickoff, resulting in the delivery of the program benefits to the bank taking longer than necessary.

Roll-Out Planning: Phased Migration or “Big Bang?”

The roll-out and migration from the legacy to new payments system and wider environment can be handled in many different ways. These range from a “big bang” strategy of migrating all payments globally at once, to an approach based on a phased migration across different geographies, business units or types and sizes of payments. In general, a big bang roll-out is likely to be faster in terms of delivering all the targeted benefits, but higher-risk in terms of potential issues at “go-live,” as well as not supporting the approach of delivering benefits in a gradual manner. The approach chosen in the roll-out plan can have a

significant impact on the business case, as it defines the total time the project will take, the number of parallel streams, the number of people from the bank and the vendors that are required for each roll-out phase, and the timeframe in which the bank can start reaping benefits from the new system.

While it is still imperative that the roll-out strategy is carefully planned and thought-through, advances in technologies and methodologies in recent years mean phased roll-outs can now progress at a much faster pace than in the past as the scope can be increased within the same risk profile. Historically, rolling out a new payments system and processes to a country might once have taken up to a year, but today it may be possible to roll out to five, six or even up to twelve countries in that time. The decisions on how to group countries together, and on whether to implement high-value payments first globally and only then move on to mass-payments, represent a balancing-act between where most of the pain/gain ratio lies versus which approach has higher potential risk.

RACI: Clear Accountability Out-of-the-Gate for All Participants

RACI stands for “responsible, accountable, consulted, informed,” and preparing a RACI chart for the project is a key part of creating the governance structure for running the project. By providing clarity on the responsibilities and accountabilities of all the solution participants, RACI is an essential starting-point for successful end-to-end program management. It is also a vital tool and methodology for ensuring the right decisions are taken at the right time by the right people, with the right checks and balances, and a clear definition of the role of each party in each activity. This enables everyone to focus on what they need to do to deliver the best results.

When applied in a collaborative and coordinated way by the bank, the solution vendor and systems integration partner, RACI enables the participants to hit the ground running with a very strong and integrated team of complementary resources from day one, rather than being thrown together on a “blind date” through separate procurement processes. This underlines the fact that best practice for a global payments program is to focus holistically on delivering the end-to-end solution, in collaboration with partners that have already worked out their respective roles and the accountabilities through working together successfully on other similar projects in the past.



9

The Global Payments Transformation Program Organization and Management

Program Versus Project Management Processes: Applying the Seven Key Principles

When initiating a global payments transformation, it is vital to start off with the right mindset and focus on ensuring tight management and control of the program’s moving parts, some of which will be under the direct influence of the program management, and some not. This means adopting and maintaining an end-to-end view of the wider program as a whole—including the impact on other areas of the bank—as well as focusing rigorously on the project processes around the core solution implementation. The weekly project meetings and the monthly steering committee meetings will play a key role in achieving both goals.

Equally importantly, it is vital to put the right processes in place—linked to the governance structure—for managing, coordinating and controlling the activities of the various internal business units and external partners involved in the program. These processes should include weekly project management meeting for each project, together with RAG (‘red/amber/green’) KPIs that measure all key metrics, including overall program status, milestones, quality, timelines, budgets, and so on. This will enable funding gates to be met, while also enabling early warning, detection and mitigation of emerging issues before they escalate into problems.

The RAG status and other controls are presented in a dashboard that acts as the principal management control tool for the senior management and steering committee to oversee and control the project.

Maintaining Effective Communication

The ongoing communications effort around the program needs to take place via multiple channels and at multiple levels, as well as across the program and within each project, and with both internal and external stakeholders. Key areas to cover include progress, risks and any issues that may be higher priority and require immediate action. It’s also important to keep the organization as a whole informed and mindful of the benefits, progress and plans, through regular staff newsletters and an internal web site. The overall goal is to ensure that by the time the transformation takes place, every employee is fully aware of its impact and there are no surprises.

Alongside formal communication, the communications effort should also include informal communication, taking the pulse of the stakeholders and “walking the halls” to discuss, understand and manage what is going on. The situation to avoid is one

Barclays’ Journey to Global “Follow-the-Sun” Payments

When Barclays decided it was going to up its game from primarily a single currency player in its two domestic markets – the United Kingdom and South Africa – to become a worldwide force across currencies, it knew it would require significant investment in its people, platforms and processes.

Barclays’ Global Payments unit employs over 1,000 staff in 13 locations, including London, Frankfurt, Dubai, Johannesburg, Mumbai, Tokyo and New York. To bring an advanced level of service to these global operations, the bank set about overhauling its entire payments infrastructure, all the way from the initial channel contact with customers to the final production of statements and reconciliation. A key element of this transformation was the implementation of a standardized global payments platform.

“Customers want quick and efficient payments, so we were looking for an STP rate of at least 95% for all payments,” says Dan Pilling, Head of Business Architecture and Strategy, Change Management Barclays Corporate Banking. From a short-list of candidate applications, Barclays chose Global PAYplus from Fundtech. Pilling explains: “Replacing a payment system is a long journey. You have to be comfortable not only that the product fits, but also that you can work in partnership with the vendor at every stage to reach your goal.”

The switch-over was too big and complex to take the risk of a big-bang approach. So the bank decided on a phased migration, running both systems simultaneously and moving payments from the old to the new platform in batches. With the new platform in place and fully integrated and tested, Barclays began the migration process. It started with inbound credit payments, because they are simpler and lower operational risk than outbound payments. The bank further subdivided the payments by currency, then amount and channel.

The deployment of new technology is also enabling operational transformation. Barclays has created payment hubs located in India, the UK and the US, to provide rolling 24-hour operations. “Having a standard platform enables a follow-the-sun model and enables global operational efficiency,” comments Pilling. “So now, rather than having different payment systems in each country, we have centers of excellence at each location and customers have a consistent experience no matter where they are.”



10

where the chart shows all projects as green, and then all of a sudden they go red, catching everybody by surprise. This helps to ensure that even problems whose root causes lie outside of the payments transformation project itself are monitored, caught and addressed.

Execution for a Global Payments Transformation

Best Practices in Executing the Program Stages

Once the bank has approved the budget for the program, selected the vendors, defined the TOM and built the program organization, the time has come to execute the program. The four key stages in executing a payments transformation program can be broadly defined as: analysis & design; implementation; verification; and deployment.

Each of these stages requires a high level of ongoing coordination between the various program teams/groups. The parallel execution includes the following main streams:

• Payment Hub Stream – the lead stream which is responsible for the delivery of the global payment services hub;

• Perimeter Systems Stream – this stream focuses on the changes required to all the perimeter systems to support the payments transformation;

• Payment Operation Stream – delivering the new payment operation organization and processes, this stream may also include responsibility for the user acceptance testing (UAT);

• Environment Preparation Stream – this stream is responsible for the physical elements related to the payment transformation including hardware, data center upgrades, office space, etc.

The recommended delivery methodology for the payment hub stream is a combination of proven best practices for payment transformation programs aligned with the bank’s current methodologies and processes. Fundtech and IBM have worked together closely over many years, and the methodology presented below is result of our joint experience of ensuring successful delivery throughout these stages and in the handover interfaces between them.

We will now examine each of the four key stages in turn.

Analysis and Design

The initial stage of the execution phase involves outlining and scoping the proposed solution, and developing a shared understanding both of the bank’s requirements and also of the

capabilities and value of the vendor’s product. The functional and non-functional requirements will drive the solution’s functional and technical architecture, respectively. These are critical in aligning the technical specifications with various functional needs that may have emerged across the bank, while also playing an important role in ensuring high availability and effective disaster recovery capabilities.

Typically a cross-functional team that includes business and solution architects is formed early in the project to resolve conflicts between functional and non-functional requirements. This team will also have representation from the business to ensure that the end result meets the business and operational requirements. The service-level agreements (SLAs) for both functional and technical performance also need to be taken into account, and set accordingly.

On the technical side, with the proof-of-concepts or pilots having already brought an understanding of the technical capabilities of the solution’s various components, there is a need to develop a clear definition of the hardware, software and security aspects needed to support the system, as well as the middleware that will connect all the components. These elements have to be brought together in such a way as to ensure that the required levels of availability and resilience will be met after go-live, as well as external requirements such as cross-border data protection regulations. In cases where these considerations are left to the end, this can result in the need to significantly rework the project, causing delays and extra costs.

In order to improve the overall execution process, the product vendor should provide a set of standard operating models and take a collaborative approach to analysis and review. The operating models are based on the vendor’s experience of payment systems and encapsulate, at a high level, the ways in which payments can be funded, accounted for and executed. For example, payments may be pre-debited, or it may be the responsibility of the payment system to check and reserve funds. These models help to develop a shared understanding of the bank’s payments operations and the way that the product would be expected to operate.

The insights gained from comparing and contrasting the bank’s operating approach and the standard operating models allow the alignment and value of the product to be assessed quickly, in turn reducing the time it will take to establish the “fit” and identify any high-level gaps. The review process should include a demonstration of the product to help the bank in the assessment, and should also be supported by collaboration tools to ensure the documents are shared and can be updated and reviewed online.



11

For the detailed scope analysis a reference payment process model can be used. This model breaks payment processing down into a series of discrete functions, such as BIC/IBAN validation and provides a standardized approach and terminology for the elaboration of the requirements, irrespective of the bank’s chosen Target Operating Model. This helps reduce the time taken to develop a shared understanding, and provides a functional checklist that can be used to validate the statement of requirements.

In cases where a gap is identified, the bank should require the internal users to provide business justification and priority for the gap to assess if it is a business differentiator or an artifact of a legacy process. For gaps that don’t advance business strategy, staying with the “out-of-the-box” capabilities will reduce the scope and the risk of the delivery and will result in a more maintainable solution and with a lower TCO (total cost of ownership). The gaps and non-gaps are cross-referenced using a Requirements Traceability Matrix (RTM) which ensures that all the requirements have been addressed. The end result of this stage is a scope analysis document detailing the requirements which require code changes and the requirements which only require setup and configuration changes.

The scope analysis also looks at the design of the integration interfaces between the payments solution and the perimeter systems to which it will need to link. Again, the key question is whether reconfiguration of the out-of-the-box interfaces will be sufficient without additional efforts, and if not the division of labor between the bank, solution provide and SI in bridging the interface gap.

Bringing together the key documents including the scope analysis of the chosen solution, the BRDs and the functional and non-functional requirements, the program can now proceed to the specification phase. This includes the definition of the changes and additional development work that need to be undertaken to ensure the solution meets the various requirements, with a specification document being drawn up for each change. The documents then need to be signed off by the internal bank customers to confirm that their requirements are being met and that everything is being covered in the right way. With the sign-off process completed, it is time to move on to the implementation stage.

Implementation

The implementation stage is where the specified development work is undertaken in a coordinated way by the vendor and bank. Working closely with the system integrator, the solution vendor carries out the package configuration, if necessary recoding of the core package,

while the bank makes any adaptations and/or enhancements needed to its own upstream and downstream systems to integrate with the new payments engine and maintain the end-to-end workflow. All parties collaborate to ensure the interaction interfaces between the various components are fit for purpose.

The development approach should be based on agile principles while still supporting strong monitoring and control. This requires the development process to be features-based and limit work in progress. Features are a collection of changes that the bank is interested in making, and therefore provide better alignment with business needs and improve transparency of the related costs. A feature may be a simple change related to improving a matching algorithm for return of funds or implementation of a new payment type. The development methodology should also include continuous integration, which improves the overall quality of the delivery.

The product should allow the bank the ability to participate in the development of non-core features in order to gain more knowledge of the product and reduce the cost of implementation. It is recommended that the bank and the vendor should exchange interface simulators to allow for better testing of the interfaces prior to SIT.

Verification

Having built the system, it’s time to test whether it meets the various stakeholders’ needs as defined in the BRDs and in the functional and non-functional requirements. The testing phase generally includes four distinct types of testing:

• Systems Integration Testing (SIT) involves testing not only the functionality of the solution itself, the interfaces with other systems and the code that has been written in the previous phase, but also the end-to-end flow of payments and the way the system will be set up and configured to operate in production. It is recommended that prior to executing the full SIT plan, a pre-SIT period of a few weeks should be set to “shake down” the interfaces and bring the overall system to a point where all types of messages are exchanged successfully between all the systems. In larger implementations, the “shake-down” period can be considerably longer, as new solution features and integration points are delivered progressively and iteratively into the SIT environment.

• User Acceptance Testing (UAT) involves testing the solution in a “real world” environment with end-users in the business and operations, with a view to highlighting and addressing any issues that may arise in practice in its business functionality.



12

The findings may feed into both technical changes and also training and orientation programs. Prior to the UAT, testers should get appropriate training on the product to improve their efficiency and reduce the number false positive defects.

• Non-Functional Testing (NFT) tests the system’s compliance with the non-functional requirements in terms of factors such as throughput performance, availability and resilience. The NFT can be done in parallel to the UAT. It is recommended that the prior to executing the full NFT, the bank should work with the vendor to simulate the NFT test at the vendor site.

• Operational Acceptance Testing (OAT) aims to establish that the new system and processes work effectively in the bank’s wider operational environment. This testing will likely feed into changes, improvements and refinements in operational procedures, since the procedures applied under the previous system will no longer be fit for purpose. The new procedures need to be clearly defined and documented before deployment.

Throughout the verification stage, it is recommended that the bank should work closely with the vendor’s testing team in areas including:

• Sharing and joint review of the test plan and test design;

• Certification/witness testing involving the vendor executing sample bank scripts using the bank’s target setup and configuration prior to the delivery to the bank;

• Maintaining bank resources on-site to be involved in the vendor testing, and vice-versa;

• Synchronizing the vendor and the bank test environments to facilitate the reproduction of bank defects at the vendor’s site;

• Jointly defining the defect lifecycle process and tracking tools, in order to make the process as efficient as possible.

The vendor product should come complete with automated test scripts which can be used by the bank to do sanity and regression testing. As part of the UAT phase, the bank should use production data to run several production days and compare the results to the existing production system to cover cases that were not represented as part of the UAT scripting.

Deployment

With the various forms of testing and wider preparations completed, the new payments system is ready for deployment into the live production environment. The deployment process will be determined by the strategy chosen for the roll-out. As part of the delivery of the payment application, a migration middleware layer

should be provided to reduce the need for changes to the existing and proposed system. The middleware sits between existing perimeter systems and the payments hub, and supports mapping of existing message formats to those used by the payments hub, thereby reducing the need for change. This functionality may be provided by a product such as IBM’s WESB.

The use of this middleware layer not only reduces the need for change, therefore simplifying the task of interfacing the old and new systems, but also supports parallel running and phased migration of payments. The ability to use the existing systems interfaces, without change, means that the existing feeds can also be fed through the payments hub to achieve parallel running. The middleware can also be used to phase the migration by redirecting certain payments to the payment hub while the remaining payments are serviced by the existing payment system.

Data and Technical Migration and the Final “Go-Live”

Data and technical migration take place in parallel with the planning process. This represents a key phase in the switchover to the new system, and any shortcomings here in terms of data integrity or technical interfaces will return to plague the system in the longer run. This is an area where the capabilities, experience, skills and global reach of the systems integration partner come to the fore. Ideally, the bank will have chosen a partner that has very strong data and technical migration experience with many of the world’s largest banks, including projects across and beyond the payments business. The existence of a joint migration methodology between the systems integration partner and solution vendor is a further positive sign.

At “go-live”—the moment when the new payments system and processes move into production—the value of all the planning, hard work and collaborative effort of the previous months and years is put to the test. However, go-live is not an end in itself. Instead, it sounds the starting-gun both for the bank’s realization of the benefits of the new payments hub, and also for an ongoing series of post-production efforts aimed at optimizing the system’s operations, driving continuous improvement, meeting new requirements, reinforcing business continuity, and enhancing employee usage and engagement.

Post-Production Considerations

Production Support Processes – And Driving Continuous Improvement

A bank whose payments hub has entered the post-production



13

phase must enable the production support group (through training and select staff augmentation) to take on the responsibility for all the processes required to run the new environment. These will include the end-user help desk managed against relevant KPIs and SLAs, and ongoing monitoring of the system’s databases, servers and communications links to identify and address any problems that arise. The bank should also set up a static data maintenance team, tasked with ensuring that the operating procedures defined before go-live are being carried out fully and consistently. It is recommended that the static data maintenance teams should be kept small and tight-knit to maximize focus and sharing of information.

The production support team works hand-in-hand with the static data maintenance team to help drive continuous improvement in the service delivered to internal customers across the bank. On the technical side, the ongoing examination and monitoring of the new payment environment’s processes and performance on a continuing basis are also key for spotting and capitalizing on opportunities for improvements.

Alongside technical improvements, functional enhancements may be requested by the business to seize emerging commercial opportunities or meet new regulatory obligations and/or the needs of new clients or product sets. Initially these will come in parallel with the hub rollout and are typically incorporated into the release scope under the hub governance process. Once the hub is fully rolled out, these then follow the bank’s normal investment process. It is recommended, that if previously the process was highly regional, that a global overlay be provided to allow the bank to take full advantage of the global nature of the hub and to easily take local innovations and best practices to the global level.

In responding to requests for functional and/or technical changes springing from shifts in business needs or regulation, the bank needs to decide whether these amendments can be handled in-house through reconfiguration of the solution’s parameters and rules, be handled in the other bank’s systems or require it to go back to the vendor for changes to the solution itself. A governance process that involves all stakeholders—bank, solution provider and systems integration partner—will bring together all the necessary expertise to arrive at an optimal decision.

Knowledge Transfer and Training Planning

The rapid global escalation in payments transformation programs has inevitably created significant pressure on the availability of key payments skills and resources—a shortage that now affects vendors, systems integrators and banks themselves.

This talent squeeze has put the emphasis even more strongly on knowledge transfer and training planning, and has underlined their importance to maintaining robust business continuity. If users of the new payments system and processes understand not just what they are doing but why, and are able to articulate this to colleagues, then the environment will not only work more effectively and efficiently, but the risks of errors and misuse are also greatly reduced.

To help banks maximize the payback from their knowledge management framework and processes amid the current scarcity of resources, an approach that leading providers have adopted is to create joint global centers of excellence, and make these available to clients to share knowledge with and train as many people as they need. These centers can also generate additional benefits, including helping banks map out and manage their future technology and skills strategies more effectively, and reduce their reliance on their vendor and systems integration partners to drive the future development of their payments environment.

Conclusions and Summary

Clearly, it is important to apply best practices at every stage of a payments transformation program; but payments transformations are highly complex undertakings, and it is too simplistic just to slavishly follow generic best practices. Instead, to deliver the full benefits they are seeking, banks need to work out how to take the best practices and tailor them to their own unique needs. This is a task where systems integrator and solution vendor analysts can make a major contribution, helping to navigate and accelerate the bank’s journey to a successful program.

However, mapping out the route raises a further question: what does a successful payments transformation look like? While the detail will vary from bank to bank, there are a number of common elements. At an operational level, these include consolidation of payments processes and systems. More strategically, success lies in enabling the bank to classify its capabilities and processes as either commodity or value-additive, and then ensuring delivery of the right solution and cost structure to sequence the journey to get to value sooner and with lower risk.

Picking the Right Solution – And the Right Partners

To achieve the “model bank” outcome, it is imperative that banks take great care in selecting the right payments solution and systems integration partner. In terms of the solution, banks seeking to compete effectively in the fast-changing payments landscape need to be sure they identify, choose and implement a



14

payments platform that is:

• Global – reflecting the increasingly global nature of today’s business;

• Real-Time – reflecting current and emerging trends of mobile and other instantaneous payments;

• Responsive to Change – allowing for the introduction of new products and regulatory mandates in radically compressed timeframes;

• Cost-Efficient – removing duplication, manual interventions and costs – and simultaneously boosting speed – by concurrently processing multiple payment types; leveraging the existing strategic assets via rapid and seamless integration; and utilizing leading infrastructure products in an optimal way;

• Future Proof – using standards, tools, and approaches that ensure that the scalable platform will remain current and can over its operating lifespan.

A good “payment services hub” has all of these attributes. Banks should base their hub around the solution that delivers most effectively against these criteria while also best meeting their business needs.

However, successful transformation demands much more than simply selecting the right payments technology. For the chosen solution to deliver the desired benefits, the bank must also choose the right solution provider and the right systems integration partner to implement the product and integrate it into the bank’s overall systems landscape. Given the strategic importance, level of complexity of overall program, its global nature and its extended timescales, the bank should focus on selecting the right team:

• Solution and Integration partners with expertise and track record in delivering these kinds of initiatives globally, jointly and at banks similar to yours in size, scope, scale and complexity so that they can bring practical lessons learned as well as domain expertise to the initiative. Value and speed for the bank are likely to be higher where the system integrator’s collaboration with the vendor has extended to joint investment over several years in the development of implementation and integration accelerators, including off-the-shelf, repeatable and reusable

interfaces.

• Solution and Integration partners that can commit resources for the long term, adjust the size flexibly and rapidly as bank’s requirements dictate;

• Solution provider with the resources to support evolution of the bank’s road map over decades;

• Integration partner with the resources and capabilities to support the bank globally and to continually de-risk the implementation.

With these partners on board, the chances of a successful transformation are several magnitudes greater.

Mapping Out Your Future in Payments

In today’s fast-changing and increasingly competitive payments environment, banks face a stark binary choice. Some will decide to allow their payments business to wind down, and to handle payments through correspondents or white-labeling.

However, for those banks that are committed to being leaders in this business, payments transformation is no longer an option, but an imperative. Getting the program wrong derails its momentum, wastes resources and potentially throws the bank’s payments business into a death spiral.

Conversely, by tailoring the tried and tested best practices a bank can ensure that its payments business enters a virtuous circle of rising efficiency, effectiveness, economies of scale, customer take-up and revenue growth. The choice is yours.



15

About the Authors

Ravi Kadiyala is an Associate Partner in IBM’s US Financial Services Strategy and Innovation practice. He has over 20 years of experience in developing and executing General, IT, and Operations strategies with a focus on Growth, Cost Reduction, Post Merger Integration, and Organization Design programs. Ravi has extensive experience in the Transaction Banking (Trade Finance, Cash Management, and Payments) and Financial Markets industry sectors where he has worked with leading global Financial Institutions to develop and implement Target Operating Models to drive organizational transformation. He can be reached at [email protected].

Uri Melzer is Executive Vice President Global Customers & Services. Uri has more than 25 years of experience in the IT industry; development and deployment of Information Systems and project and account management, mainly in the banking and telecommunication markets. He is responsible for managing Fundtech’s customers, projects and services globally. Before joining Fundtech, Uri was a Delivery VP in the APAC Division of Amdocs, an international provider of billing and CRM solutions to the telecommunication market, VP of Marketing and International Operations at IFN, a company that specializes in enterprise content management and BPM solutions and SVP at Surecomp, a company that specializes in Trade Finance Banking solutions. Uri holds a BA in Economics and Computer Sciences and an MBA. He can be reached at [email protected].

James Methe is an Associate Partner and is the worldwide leader of the Payments and Transaction Banking Solutions team in Global Business Services (GBS) Division of IBM. Having begun his career in international commercial banking in the United States he has significant experience working in Asia, where he worked expanding the bank’s global presence. James has over 30 years of experience in international corporate banking, payments and transaction banking business and technology. James has been involved in many complex banking transformation consulting and solution delivery projects for top 100 banks globally in over 30 countries. James is a founding member and heads of the payments team of the IBM Banking and Financial Markets Center of Competency (CoC). He can be reached at [email protected].

Gene Neyer is a Senior Vice President of Product Management for Fundtech (www.fundtech.com). Mr. Neyer has 20+ years of experience in the industry in a variety of roles from Product and Business Management to Software Development & Management Consulting. Prior to joining Fundtech, he was a Principal for NG Group, focusing on Global Payment Architectures and Operational Efficiency; a Managing Security Executive for FSTC (www.fstc.org) a consortium of leading US banks; a Head of Engineering and

Security for EBS and Head of Development for US payments at Deutsche Bank and Bankers Trust. Mr. Neyer began his career at AT&T Bell Labs as a Member of Technical Staff. He holds a B.S. and M.S. Degrees in Mathematics from City College of NY, and Executive Master in Technology Management from Wharton/University of Pennsylvania. He can be reached at [email protected].

Robert Snider is the chief architect of IBM SWG Banking Industry Framework Payments and Transactions domain. He is responsible for the architecture and technical strategy of SWG products, and services assets in the finance sector. Robert has over 25 years of experience in the design and implementation of financial services systems across a variety or retail and commercial banking systems. These systems include: teller platforms, check sorter / reader, front office loan origination applications both mortgage and personal lines et. al. Roberts focus area for the past nine years is financial messaging systems that include wholesale payments, treasury systems, cash management platforms, and trade finance systems. He can be reached at [email protected].

John Walker is a Senior Managing Consultant and is worldwide leader for Payments Hubs Solutions in the IBM Global business Services. John has over 35 years of experience in solution development, project delivery and transformation program governance at major banks around the globe and has played pivotal development, delivery and managerial roles in premier banks and independent software vendors in the payments and core banking space. John has been involved and led many complex banking transformation consulting and solution delivery projects globally and has been a leading contributor to IBM payments program best practice development in his current role in IBM’s Banking and Financial Markets center of Competence. He can be reached at [email protected].

Isaac (Zack) Yaniv, Executive Vice President, joined Fundtech in 1994. Zack manages the Global Payments Business Unit which includes the flagship GPP and CLS products. Zack has over 25 years design and development experience in technical and management positions in the financial industry. He previously held positions as CEO of 2001 Systems and Services Ltd., a software development and systems integration firm; Development Manager for Digital Equipment Corporation for the financial institution division, and Project Manager in funds transfer systems for Bankers Trust. He holds a B.A. in Computer Science, Economics and Criminology and an MBA. He can be reached at [email protected].

mailto:rkkadiya%40us.ibm.com?subject=

mailto:uri.melzer%40fundtech.com?subject=

mailto:jamethe%40us.ibm.com?subject=

mailto:Gene.neyer%40fundtech.com?subject=

mailto:Gene.neyer%40fundtech.com?subject=

mailto:rsnider%40us.ibm.com?subject=

mailto:jrwalker%40us.ibm.com?subject=

mailto:Isaac.Yaniv%40fundtech.com?subject=

PAYMENTS TRANSFORMATION WHITE PAPER16

About IBM

The right partner for a changing world! At IBM, we collaborate with our clients, bringing together business insight, advanced research and technology to give them a distinct advantage in today’s rapidly changing environment. Through our integrated approach to business design and execution, we help turn strategies into action. And with expertise in 17 industries and global capabilities that span 170 countries, we can help clients anticipate change and profit from new opportunities.

© Copyright IBM Corporation 2013. All Rights Reserved.

IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries, or both. If these and other IBM trademarked terms are marked on their first occurrence in this information with a trademark symbol (® or ™), these symbols indicate U.S. registered or common law trademarks owned by IBM at the time this information was published. Such trademarks may also be registered or common law trademarks in other countries. A current list of IBM trademarks is available on the Web at “Copyright and trademark information” at: ibm.com/legal/copytrade.shtml.

Other product, company or service names may be trademarks or servicemarks of others.

References in this publication to IBM products or services do not imply that IBM intends to make them available in all countries in which IBM operates.

www.fundtech.com

Fundtech Regional Headquarters

North America Corporate Headquarters 30 Montgomery Street, Suite 501 Jersey City, NJ 07302-3821 Tel: +1-201.946.1100

EMEA United Kingdom 42 New Broad Street London EC2M 1SB Tel: +44-207.588.1100

Asia-Pacific Singapore 3 Church St #22-05 Samsung Hub 049483 Singapore Tel: +65-6372 3123/ 6372 3131

12/13

About Fundtech

Fundtech offers a comprehensive line of transaction banking solutions to banks and corporations of all sizes around the world. As a strategic supplier, Fundtech’s customers benefit from lower operating costs and an enhanced end-user experience through integrated and feature-rich solutions. The firm’s major product lines include: global and regional payments, corporate cash and liquidity management, financial messaging, electronic invoice presentment, supply chain financing, remote deposit capture, merchant services, credit card gateway and mobile banking products. Fundtech offers its software through a traditional software license and a Software-as-a-Service (SaaS) contract. The firm is also the world’s largest SWIFT service bureau operator. Thousands of financial institutions and companies worldwide rely on Fundtech’s innovation to improve operational efficiency, increase revenues, and provide greater competitiveness through business-to-business services. Founded in 1993, Fundtech was acquired in 2011 by GTCR, a Chicago-based private equity firm. For more information please visit www.fundtech.com.

© Copyright 2013 Fundtech All rights reserved.

Fundtech reserves the right to alter the specifications and descriptions in this publication without prior notice. No part of this publication shall be deemed to be part of any contract or warranty unless specifically incorporated by reference into such contract or warranty. All brand or product names are the trademarks or registered trademarks of their respective holders. The information contained herein is merely descriptive in nature, and does not constitute a binding offer for the license of the product described herein.

http://www.ibm.com/legal/us/en/copytrade.shtml

http://www.fundtech.com

payments-transformation-global-payments-white-paper

Documents

future of payments

payments arena

global payments journey

banks payments operations

centralized payments

major payments project

payments hub implementations

fundtech white paper