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 rkkadiya@us.ibm.com.
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 uri.melzer@fundtech.com.
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 jamethe@us.ibm.com.
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 ATT 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 Gene.neyer@
fundtech.com.
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 rsnider@us.ibm.com.
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 jrwalker@us.ibm.com.
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
Isaac.Yaniv@fundtech.com.

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.

payments-transformation-global-payments-white-paper

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à payments-transformation-global-payments-white-paper

Similaire à payments-transformation-global-payments-white-paper (20)

Plus de Asish Mohanty M@Vodafone Group

Plus de Asish Mohanty M@Vodafone Group (13)

payments-transformation-global-payments-white-paper