One Hub or Two?

Implementation Approaches for

Enterprise Payment Hubs

Susan Feinberg
Research Director, Payments Practice
April 2008

Executive Summary
As global payments volumes continue to grow, the payments industry is undergoing an
unprecedented level of change in all regions. Pressures of diminishing margins, increased
competition, and regulation are leading to the commoditization of payments processing. Banks
must be innovative to remain competitive and deliver new services demanded by corporate and
retail clients alike. The challenge is delivering this from a “spaghetti-ware” of payments systems
that have evolved over several decades.

TowerGroup sees banks moving from the conceptualization of “enterprise payments” to

implementation during 2008 and 2009. Leading banks will implement service-oriented architecture
(SOA) models that combine expert processing capability and open, standards-based integration.
To address this shift to SOA, technology companies that provide traditional payment applications
are reengineering their traditional solutions to be more componentized and modular. The aim is to
compete with new market entrants that benefit from the concept of service-oriented architecture
in SOA technology era. Integration vendors provide necessary data transformation capabilities,
ideally based on the emerging Organization for International Standards (ISO) 20022 schemas.
Vendors from the two categories are partnering to deliver solutions that meet the requirements of
banks.

An SOA solution enables a bank to migrate payments processing from a monolithic, legacy
platform to a new componentized environment capable of managing payments of all types in a
consistent manner. Conceptually, a single payments hub crossing both retail and wholesale
business units is achievable, but the evolution to that stage may take some time. Every bank has
its own pain points, priorities, and short-term objectives, as do its various business units. In many
ways, organizational issues pose a greater challenge than technology for establishing a single
payments hub.

Banks must identify the gap between the current state and the strategic objective, then select
appropriate technology solutions and map out the phases from day one to the end goal. Such an
approach allows for unplanned changes along the route, as might be imposed by economic
conditions or regulatory requirements. The right technology framework is adaptable to changing
conditions and can adjust to the bank’s changing strategy.

TowerGroup Research is available on the Internet at www.towergroup.com

© 2008 The Tower Group, Inc.
May not be reproduced by any means without express permission. All rights reserved.
TowerGroup is a wholly owned subsidiary of MasterCard Worldwide and operates as a separate business entity with
complete editorial independence. MasterCard Worldwide is not responsible for and does not necessarily endorse any
opinions, statements, or other content presented by TowerGroup.
 One Hub or Two? Implementation Approaches to Enterprise Payment Hubs

The Drive to Achieve Payments Efficiencies

While the volume of global payments transactions continues to increase at a compound annual
growth rate (CAGR) of approximately 12.2%, external pressures on the payments business are
unprecedented. Each year, TowerGroup identifies the top 10 business drivers, strategic responses,
and technology challenges facing the payments industry. For 2008, TowerGroup determined that
three of the top business drivers for the global payments industry are the “Three Cs”:
commoditization, convergence, and competition. Technology changes also present challenges.
Newer, more modern payment methods are challenging the traditional instruments of check,
automated clearing house (ACH), and wire transfers, and emerging economies are leapfrogging
established payments markets in the use of mobile and alternative payments technology.

Unfortunately, at a time when payment revenues per transaction are shrinking, payments
technology costs are rising. As a result, banks are forced to rethink payments technology spending
models. The net effect is that banks need to derive more value from their payments services and
find a way to charge clients for that value added. TowerGroup expects banks to progress from
talking about enterprise payments (taking a holistic view of payments operations and technology
across the bank enterprise) in 2007 to making them a reality and implementing them in 2008 and
2009. (More information on the 2008 payments market is presented in TowerGroup Research Note
V53:43P, Top 10 Business Drivers, Strategic Responses, and IT Initiatives in Global Payments.)

Commoditization
The phenomenon of payments commoditization is occurring in countries with developed payments
systems, which seek processing efficiencies to drive down the cost of operations or at least control
it. Regulation has also forced pricing pressures, such as from the European Commission’s
Payments Services Directive (PSD). This mandate requires that pricing for international
transactions be the same as for domestic transactions throughout the affected European countries,
in effect removing the premium that previously made cross-border payments processing a high-
margin business for banks doing business in Europe. To compensate for the loss of this business,
the banks will have to deliver innovative solutions that generate value for the client and therefore
revenue for the bank outside the vanilla service of payment processing. For example, although
corporate treasurers will not pay more for payment processing, they will pay for cash management
tools and information that save them time or money or both.

Turning to the back office, TowerGroup also considers payment processing to be a commoditized
function. The back office is still regarded as an engine room that must continually strive for
processing efficiencies. Back-office payment operations have typically been funded on a least-cost
basis, with just enough technical development to remain compliant and reliable — innovation has
not been a priority. In recent years, the search of cost savings have often involved outsourcing
technology and moving some operations staff offshore, but the impediments to an efficient
payments operation are typically still in place.

These obstacles to efficiency usually take the form of operations silos performing similar functions,
an inefficient use of technology applications across multiple platforms, and a fixed number of
dedicated support staff skilled on specific applications. Because the walls between the silos are
typically high, staff performing the same function (such as exception management) in one
department may well be unaware of the similar function being applied on the next floor. Even if
exceptions occur for the same client, the exceptions process is handled by separate groups
because the payment types are different. This duplication of effort leads not only to inefficiency,
but also to risk. Banks face two tough challenges: Not only do they need to provide product agility
in a competitive marketplace, but they also must ensure operational efficiencies in the back office.
It is with good reason that European banks refer to the operational aspect as “manufacturing.”

2
© 2008 The Tower Group, Inc.
May not be reproduced by any means without express permission. All rights reserved.
 One Hub or Two? Implementation Approaches to Enterprise Payment Hubs

The back office is in effect a factory through which payments must be processed as reliably,
efficiently, and cost effectively as possible. A payments hub can provide more efficient use of
operational staff and their functional roles by using new technology architectures to achieve
savings in the back office.

Convergence
Exhibit 1 shows the shifting mix of payment types by their percentage shares of the total
payments market.

Exhibit 1

Global Payment Type Distribution

(2000–2010E)
100%

90%
Check
80%

70%
ACH
60%

50%

40%

30%
Cards
20%

10%

0%
2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010

Note: Exhibit #: 1
Check includes paper and image items.ACH (automated clearing house) includes check conversions to ACH. Source: TowerGroup

TowerGroup defines payments convergence as the blurring of the lines between payment types
that have traditionally differed. As payment types overlap or converge and share what were once
separate processing “rails,” product differentiation becomes harder to achieve and processing
flexibility becomes vital. Although convergence of payments types has been in progress for some
time, recent initiatives in the United States and Europe have increased the pace of this trend,
although differently on each side of the Atlantic.

In Europe, the assimilation of the payment types mandated by Single Euro Payments Area (SEPA)
initiative removes the traditional differentiation of payment products, particularly cross-border
payments within the Euro zone. SEPA’s required homogenization of cross-border payment
capabilities will force banks to develop innovative products that add value to the payment process.
The Faster Payments scheme in the United Kingdom, scheduled to go live in May 2008, is in
essence a blend of real-time card switching capabilities and ACH transactions. With confirmations
in near real time and a transaction ceiling of GBP 10,000, Faster Payments will also cannibalize

3
© 2008 The Tower Group, Inc.
May not be reproduced by any means without express permission. All rights reserved.
 One Hub or Two? Implementation Approaches to Enterprise Payment Hubs

business from the high-value Clearing House Automated Payments System (CHAPS). As a result,
banks must find innovative means to deliver payments products and services to reverse the trend
of diminishing margins.

In the United States, the decline in check clearing to this point is related primarily to retail or
consumer transactions. Cards are replacing checks at point of sale, checks are being removed by
ACH conversion, and online payments can be processed as ACH eChecks. Nevertheless in North
America, corporate payments are still dominated by check (TowerGroup estimates up to 70% in
the United States and Canada), but that will eventually change and banks must prepare for a
migration from check to electronic transactions in both retail and wholesale banking verticals. In
this market, banks must offer payment services that facilitate client migration as demanded. At
some point in the next five years, whether driven by a new breed of treasurer or the impact of
new payment standards such as the Electronic Payments Network’s EPN STP 820, the tipping point
will be reached. Banks that do not have a strategy or a solution to migrate this business will face
client attrition and an overbearing cost burden for their check processing systems.

Regardless of the convergence drivers, banks with a flexible architecture will be best positioned for
future market changes. Attaining flexibility requires taking a more holistic view of payments across
the traditional payment silos and implementing a payments hub with technologies that manage
multiple payment types. A payments hub can provide a blended view of payment processing
across the organization. Such a solution also enables a bank to leverage the converged payment
channels to deliver new functionality. An example is the ability the bank would gain to determine
payment routing based either on customer preferences or bank-defined rules. Such decision logic
becomes possible as the data requirements for the clearing systems become more closely aligned
and centrally managed within a bank.

Competition
Banks face competition for payment services in both the retail and wholesale banking segments.
In the retail space, Internet providers such as PayPal offer a variety of person-to-person (P2P) and
consumer-to-business (C2B) payment options. For example, Obopay, a mobile payments
application provider has partnered with Internet communications firm Skype to allow funds to be
sent between Skype users. Although ultimately the banks may process these transactions on their
books, they are in effect suffering disintermediation in terms of delivering a payments experience
to the consumer. To counter competition in the retail space, banks strive to deliver new payment
services through additional delivery channels, either Internet based or mobile based. This strategy
is valuable from the perspectives of consumer choice and competitive differentiation but it makes
service delivery more complicated and costly because few channels are ever replaced. As new
solutions are developed, integration with the traditional back-office environment becomes
increasingly complex. The change in the back office is disruptive and unwelcome. Because of
testing requirements, the time to implement can be considerable, causing possible lack of
competitiveness as well as internal frustrations.

Wholesale banking clients are under the same regulatory and efficiency pressures as their banking
partners. As corporations strive to improve the efficiency of their treasury operations, TowerGroup
believes that up to 30% are actively seeking to reduce not only the number of accounts they
manage but also the number of banks with which they have relationships. Their review of the
number and quality of their banking relationships will result in their consolidating their business
with fewer banks. Competition for payments market share will therefore intensify among the
banks. The most successful banks will be those that can deliver the payments reliably and offer
the breadth of product offering that corporations need.

4
© 2008 The Tower Group, Inc.
May not be reproduced by any means without express permission. All rights reserved.
 One Hub or Two? Implementation Approaches to Enterprise Payment Hubs

Technology Challenges
In addition to challenges of the “Three Cs” (commoditization, convergence, and competition),
TowerGroup notes that the underlying technology platforms supporting the payments
manufacturing operation are becoming an operational challenge. Back-office payment applications
that were developed from the mid-1970s through the 1980s were monolithic systems tied to a
specific processing hardware — typically, mainframe or nonstop computing environments. Over
time, in response to regulatory, product, or operational demands, new technology applications
have been developed and implemented alongside legacy systems. Despite the best intentions, few
applications are replaced — often because of an unforeseen functionality gap or critical, custom
features necessary to support particular business needs or special clients. Decades of development
have resulted in a hodge-podge of technologies and hardware platforms. A typical bank has some
hardware from almost every major manufacturer and several different operating systems spread
across the payments environment. The result is “payment system spaghetti” in the back office of a
bank, as illustrated in Exhibit 2.

Exhibit 2

Payment System “Spaghetti”

EDI/DIRECT
CORPORATE RETAIL
TRANSMISSION DOMESTIC CASH
CUSTOMER GLOBAL CASH CUSTOMER
MANAGEMENT
MANAGEMENT

RISK/AML
CLIENT CARDS ACCOUNT
SERVICE SYSTEM
INFORMATION
REPORTING
RISK/AML
INTERNATIONAL
PAYMENTS

WIRES CHECK
PROCESSING

DOMESTIC
LOW-VALUE SYSTEM LOCAL ACH
SWIFT DOMESTIC
HIGH-VALUE SYSTEM
Note: ACH = Automated Clearing House; EDI = electronic data interchange. Exhibit #: 2
Source: TowerGroup

No wonder inefficiency and duplication exist, given that different combinations of hardware
platforms, operating systems, software packages, custom code, interface protocols, and databases
are used within the same organization to process payments.

Banks are at different points on the curve of technology advancement and dependence on legacy
applications. In cases in which a technology vendor has retired an application or withdrawn
support from it, banks must implement a new back-office solution, which in turn can be used to
spark change in the bank’s payments architecture. In other cases, the institution may be

5
© 2008 The Tower Group, Inc.
May not be reproduced by any means without express permission. All rights reserved.
 One Hub or Two? Implementation Approaches to Enterprise Payment Hubs

committed to its legacy technology and has adopted the approach, as the saying goes, “If it ain’t
broke, don’t fix it” — but these banks still need additional oversight and management of payments
data. In either case, banks face an overwhelming issue: data integration. Rather than rely on
older, proprietary interfaces, current SOA framework technology and emerging payment standards
enable banks to rationalize data and process integration. This is a fundamental component of a
payments reengineering architecture, often referred to as an enterprise payments initiative.

Enterprise Payments, Payment Hubs, and SOA

As banks seek consistency and efficiencies in operations and technology resource usage, they
should not lose sight of the need for product agility in the delivery of payment services in an
increasingly competitive market. An enterprise-wide view of payments and the development of
payment hubs is a prerequisite for agility. “Enterprise payments” requires taking a holistic view of
a bank’s payments activities, providing consistent oversight of all payment operations, and
removing processing and technology inefficiencies. It is essential to reduce the redundancy of
processes and applications, many of which are embedded in the monolithic structure of traditional
back-office systems. The principles of open, standards-based integration and process reuse come
into play in an enterprise approach, yet many banks question the relevance of SOA for payments
processing. Although the term SOA may be relatively recent in payments processing, the concept
is in fact well established in many industries. The following is TowerGroup's definition of SOA for
the payments business:

SOA for payments is a service-based, business architecture that develops and reuses
product, operational, and technology assets to support a scalable, agile payments business
strategy. This model must be underpinned by a technology framework capable of supporting
legacy applications, third-party payment products, and bank-developed payment services as
appropriate to support the payments business strategy.

By themselves, the technology components of SOA do not address any underlying business or
technology issues. However, technology does provide the supporting framework and infrastructure
from which to develop a service-oriented payments strategy. The term "architecture" naturally
sustains the technical mystique of SOA, but the model is relevant to both the payments
technology and business operations. In this regard, it may be beneficial to think of SOA as
"service-oriented payments." TowerGroup asserts that SOA is as much a set of principles as a
technology solution and applies as much to business process organization as it does to technology
architecture.

A basic example of SOA in payments processing is reuse of a processing function. For example,
many legacy applications include proprietary processes for screening to comply with national
regulations, such as those of the Office of Foreign Assets Control (OFAC) in the United States.
Unfortunately this approach often results in multiple instances of a compliance process performed
by different applications and different operational departments. The result is an inefficient use of
technology assets and operations staff. A more challenging example of shared payment services is
exception management. By elevating the exceptions functions that are currently embedded in the
legacy applications, banks can centralize the monitoring and repair of exception conditions across
multiple payment types. Homogenized data formats such as the ISO 20022 XML schema facilitate
centralized transaction management because payments of all types can be represented in the
same data structure. Processing rules can therefore be applied consistently across all transactions.
As a result, operations staff will have a single view into a given client’s payments activity and
therefore can offer not only improved risk awareness but also enhanced client service. Banks

6
© 2008 The Tower Group, Inc.
May not be reproduced by any means without express permission. All rights reserved.
 One Hub or Two? Implementation Approaches to Enterprise Payment Hubs

should determine the value of this enhanced processing and weigh that against the exit costs of
closing down a particular function or consolidating an operations area.

Exhibit 3 shows a business architecture view of a payments hub and its major components.

Exhibit 3

A Conceptualized Payments Hub Architecture

Operations Management

ONLINE Security SWIFT

CORPORATE
CLIENT
Business Rules

Data Management RTGS

PHONE
CONSUMERS Risk, Compliance, Fraud

Formatting and Message Delivery

FILE ACH
Exception Management
FINANCIAL
INSTITUTION
Payment State Management
CARDS CARDS

BANK
DEPT. MOBILE
RISK AML POSTING PAYMENTS APPLICATIONS
Note: ACH = Automated Clearing House; AML = anti- money-laundering; RTGS = real-time gross settlement. Exhibit #: 3
Source: TowerGroup
Source: TowerGroup

The left side of the exhibit shows payment delivery channels that demand agility and flexibility to
bring innovation to market quickly; the right side shows the payment networks. The lower section
of the exhibit shows samples of core payment processing areas. The center of the exhibit shows
how common payment functions and services have been extracted from the legacy payment
processing silos that form a payments hub. It is this area that provides the differentiating
capabilities to a bank’s payment services and creates a layer of separation between product
delivery (to address competitive pressures) and the commoditized function of payments
processing. The glue holding this architecture together is a consistent representation of payments
information throughout the payment life cycle.

The Value of Payments Data

The most important aspect of reengineering payments processing is data management. Whether
the data is related to payments in flight or is stored static data, the management of this vital asset
is the basis on which to build a more reliable, consistent, payments environment that can be
leveraged. Breaking down payment transactions into their constituent components reveals the
same basic data elements: currencies, amounts, dates, parties to the transaction, and some
reference data. The formats of the data may differ somewhat across payment types and
geographies, and the processing rules may be unique to a particular clearing system, but

7
© 2008 The Tower Group, Inc.
May not be reproduced by any means without express permission. All rights reserved.
 One Hub or Two? Implementation Approaches to Enterprise Payment Hubs

regardless of geography, payments of different types have more in common than not. It is only
semantic differences in data formats and business rules that make an ACH payment in Germany
appear different from a wire payment in the United States.

At base, retail payments need many of the same functional processes and services as wholesale
payments. Fundamentally, payments consist of the same components. When considered in this
light, the idea of constructing a central payments hub to provide complete insight into a bank’s
payments processing is not only conceivable but logical. A single instance of a payments
warehouse may not be practical, but a logical data store, using consistent database technology is.
A logical data store may be segregated by geography, payments type, or client type, but must
provide a converged view of payments to the end user or application.

Again, the XML schemas offered by ISO 20022 are pivotal in creating a consistent view of
payments. They can be implemented as a metadata structure for data transformation and also
payments data storage. The SWIFT-driven ISO 20022 XML structure is capable of supporting
multiple payment types, and it forms the backbone of payment messaging required to support
SEPA integration in Europe. The result is a groundswell of major payments market participants
investing in ISO 20022.

Software vendors such as IBM Corp. are adopting ISO 20022 as the internal data structure for
payments delivery in their payments framework solutions. This means the ISO structure can be
supported from payment initiation in a corporate enterprise resource planning (ERP) system,
through the bank processing applications, and out to the clearing and settlement mechanisms
(CSMs) and SWIFT. The effect in Europe is that major banks are investing in ISO 20022 as core
infrastructure — a model that TowerGroup believes has value in all payments markets. The
rationale for adopting this standard is that payments represented in this structure can be mapped
to the data requirements of any major clearing system or payments process. In other words, it
forms the core of payment processing and offers the possibility of true global payments services
interoperability.

Of course, such change doesn’t happen overnight, and TowerGroup recommends a phased
approach to payments reengineering. Fortunately, the loose-coupled nature of SOA processes
lends itself well to this strategy.

Payment Hub Solutions: Fundamental Requirements

By definition, a payments hub is a critical component of a bank’s overall payments and messaging
infrastructure. Therefore, hardware and software choices are critical. When processing a mixture
of payment types, reliability must be built for the most critical of transactions, and that mean’s
SWIFT-like availability. Banks must aim for “five nines” (99.999%) system availability. Equally
important are design considerations. Banks face the challenge of reengineering payment services
while maintaining business as usual. Implementing a flexible, service-oriented architecture in
phases is an advantageous way of meeting this challenge. Once a bank decides to embark on an
enterprise payments initiative, it must consider certain basic requirements in evaluating payment
hub solutions. TowerGroup believes that the following considerations be weighed with the utmost
importance when determining the optimal solution. Whether the bank is a global Tier 1 player or a
Tier 2 regional bank, the following functional areas are vital to the safe and reliable processing of
payments.

8
© 2008 The Tower Group, Inc.
May not be reproduced by any means without express permission. All rights reserved.
 One Hub or Two? Implementation Approaches to Enterprise Payment Hubs

Reliability and Transaction Integrity

A solution is only as strong as its weakest link. Given the difficulties of processing multiple
transaction types with different data semantics, the combination of real-time and scheduled batch
payments in the same payment hub can cause processing resource conflicts. Urgent payments
must be processed as high priority items, and the timing of payment release can impact a bank’s
ability to manage intraday liquidity. The payment hub must be capable of processing batched ACH
payments without loss of performance for urgent payments. Banks running multiple payments
centers around the world will look for a solution sophisticated enough to manage payment cutoff
times across multiple time zones for different payment types. To an extent, this is a software
engineering challenge, but optimal configuration of processing hardware is also required.

Although a payment hub provides greater overall management and control of transactions, the
more touch points in a payments life cycle, the greater the chance of transaction failure. A
payment hub must contain a facility for safely rolling back transactions to a recoverable state in
case of error, particularly when components are distributed across a payments framework.

Availability and Recoverability

Related to reliability is payment hub availability and recoverability. Active/active and
active/passive configurations are both available in the current payment hub marketplace, and
banks must select the option that best suits their respective operational requirements and
recovery service-level agreement (SLA). Again, because of the mix of payments and transaction
types, a payments system outage will have different effects on urgent payments than on
scheduled batch payments (unless a processing window is imminent). Banks may need to support
an operational hub running across multiple data centers to minimize the impact of local disaster
scenarios. The distance across which this must be accomplished will have an impact on the
optimal configuration of both the payment hub and its underlying hardware infrastructure.

Since the data in a payments hub should be generally available to operations users, applications,
and clients alike, the standard operating hours must be longer than the hours of a typical back-
office application. Leading banks will implement solutions that run very close to 24x7x365 to
support global operations with limited maintenance windows. Since payment information is so
valuable, it is typically consumed at all hours of the day, not just during regular business hours.

Security
Because a payments hub solution must be capable of processing different transaction types, it
may also be available to multiple operational areas. Inevitably, some of these areas will place
greater emphasis on secure access to the information. As George Orwell noted in Animal Farm,
“All pigs are equal, but some are more equal than others.” The same could be said for payments.
Naturally, the information contained in payment transactions must be secure, but the levels of
security required can differ among transaction types. High-value, urgent payments will often
command more restricted access than low-value payments. The payments hub should be flexible
enough so that variable levels of security can be applied and the security policy and rules are
defined in a central location. Subject to regulatory compliance requirements, the cost and
complexity of security administration should be proportional to the value of the information being
protected.

Business Scalability
With respect to enterprise payments hubs, TowerGroup defines business scalability as a means of
changing the business paradigm. How can the current processing model be transformed to support
new products, new business models, and client requirements? For example, banks and
corporations alike place increasing emphasis on the reconciliation of payments and remittance

9
© 2008 The Tower Group, Inc.
May not be reproduced by any means without express permission. All rights reserved.
 One Hub or Two? Implementation Approaches to Enterprise Payment Hubs

data. An inability to perform these functions automatically is certainly seen as a barrier to

acceptance of ACH payments in the United States. Payments information and related transaction
details should be available to internal bank departments and clients via a variety of delivery
mechanisms (file transfer, Internet, mobile) but should remain consistent in timeliness and quality
of data. New value-add services, such as the creation of customer cash positions in real time, or
integration to trade finance solutions, could be created from the payments data in such an
environment.

Process Management and Improvement

Important functional benefits can be gained from a payments hub. Because the SOA model
enables the sharing of payment services across multiple payment lines, operational and
technology efficiencies can be derived. Among the benefits are savings in the technology costs for
software and hardware as support and maintenance of multiple applications become consolidated
into a single application. A bank can also consolidate operations and technology support staff as
processing becomes more focused on fewer application components. Another area of improvement
is payments risk management. By centralizing this function, and making risk management
services available to all payment types (rather than managed locally in each business silo), banks
can gain increased awareness of payments risk across all clients, geographies, and payment
types.

A payments hub allows flexibility in configuration through the use of business rules. The trend
toward managed configurations rather than hard-coded processes allows a business to adapt
quickly as processes or products dictate. For example, changes might include the integration of
new delivery channels, or the creation of new security validation rules for international payments.
This avoids the traditional development cycle of code, test, and deploy.

Strategic Sourcing
As the payments market and its participants evolve, banks must remain flexible in their approach
to payments processing. For example, as check volumes decline and clients move to electronic
payment methods, a bank may choose to outsource this declining volume business to focus on
areas of growth. Technology and operational flexibility play a major role in this. A service-oriented
payments operation enables the externalization of select processes or functions yet retains the
operational management of the process.

Trends Among Vendors of Payment Hub Technology

With the solutions available in the marketplace, TowerGroup believes few banks will develop
bespoke or custom-built payment hubs. The typical payment hub will be a combination of core
payment processing and strong integration capabilities running on a resilient hardware
configuration.

Software
The supporting software industry has developed solutions from different ends of the technology
spectrum. On one hand are traditional payment application providers seeking to leverage their
products and expertise by redefining their applications to accommodate the enterprise strategy.
These vendors often have deep roots in payment processing, but in their current technology state
find it difficult to provide more focused solutions in an open standards payment framework.
Consequently, such vendors have embarked on a strategy to deconstruct monolithic payment
applications into smaller, more focused modules. On the other hand are integration or
infrastructure companies with technology frameworks, such as IBM WebSphere. To a large extent,
solutions in the latter category rely on the integration of expert payment applications. The

10
© 2008 The Tower Group, Inc.
May not be reproduced by any means without express permission. All rights reserved.
 One Hub or Two? Implementation Approaches to Enterprise Payment Hubs

integration is usually achieved through payment industry standards such as SWIFT or the
emerging XML payment data models such as ISO 20022, whose influence is expanding.
TowerGroup believes that a combination of advanced integration technology coupled with expert
payment processing capabilities is in fact the optimal combination, as shown in Exhibit 4. Equally
important is what TowerGroup terms “payments intellectual capital.” A deep understanding of the
applied use of technology within a payments environment is required to design and build new
payment models.

Exhibit 4

Enterprise Payments Technology Sweet Spot

(2008)
Hardware
Enterprise
Integration Payments
Vendors Sweet Spot
Integration Expertise

Hardware

Application
Vendors

Payment Domain Expertise

Exhibit #: 4
Source: TowerGroup

A major consideration when choosing vendor software is the cost of implementation. In a typical
payment system replacement, the cost of integration (interface design, development, and testing)
can exceed 50% of the total project cost. To reduce implementation costs, banks can:

• Conduct in-depth analysis and document interface requirements so as to eliminate

duplication and redundancy of many point-to-point interfaces. Banks must think about the
future requirement, not rely on the current interfaces as a requirements baseline.
• Select a technology that leverages open standards and is supported by banks and the
vendors to the financial services industry. Many software vendors are investing in tools to
ease application integration as much as in the product’s feature/function list.

TowerGroup believes that an SOA approach to business operations and technology infrastructure,
coupled with open standards integration technology, can reduce system implementation costs and
help manage project risk. The SOA approach allows modular components to be designed and
integrated over time. Implementing deliverables in phases makes the complexity of a large

11
© 2008 The Tower Group, Inc.
May not be reproduced by any means without express permission. All rights reserved.
 One Hub or Two? Implementation Approaches to Enterprise Payment Hubs

reengineering project becomes more manageable because the project is broken up into more
smaller, tactical subprojects. Banks will opt for a gradual migration to new architectures rather
than a big-bang application replacement.

Hardware
Centralized payments hardware can help banks meet the challenges of capacity, processing, and
reliability described earlier. As distributed open systems hardware platforms have become more
common in banks, the total cost of ownership (TCO) of multiple such hardware components in the
payments environment has come into question.

Although the shift to open systems offered greater flexibility than was previously possible, banks
never replaced the mainframe. In light of pressures on IT spending, banks are continually
evaluating whether payments applications can be migrated to mainframe technology. It is almost
as if the hardware cycle is coming full circle: from mainframe infrastructures, through the
revolution of open systems and distributed UNIX platforms, back to a centralized hardware
solution, but running a modern operating system. Software vendors such as ACI Worldwide are
now offering alternative versions of traditional application solutions on the revitalized IBM
mainframe, System z. With many software applications capable of running on multiple platforms,
banks must choose both software solutions and strategic hardware platforms carefully to minimize
the total cost of ownership, yet still deliver resilient payment services.

For a single vendor to achieve the sweet spot is challenging. As a result strong partnerships are
being formed between integration vendors, hardware vendors and the payments application hub
vendors. All three components are vital to deliver a robust payment hub capable of processing
complex payments throughout multiple geographies and in diverse technology environments.

Payment Hub Implementations

One major challenge of implementing a payments hub is determining the scope of an enterprise
payments project: Should enterprise payments cover just the wholesale bank (as is often the
case) or be broader and encompass the retail operation as well? Is system replacement desired
(or required), or is management of the overall payments environment a more pressing problem?

Retail, Wholesale, or Both

Although it is tempting to continue treating retail and wholesale business units as separate
technology entities, banks could be missing out on a strategic opportunity not only to generate
efficiencies but also to fully understand their payments business. The traditional separation
between retail and wholesale payments technologies arose because niche market players
developed solutions based on the semantic requirements of the clearing and settlement
mechanism (CSM). For example, the characteristics of a card networks drove development of
switching applications such as ACI BASE24. The demands of Fedwire and SWIFT determined the
design of high-value payment applications. To enable these systems to stand alone, vendors
embedded functions such as posting and exceptions monitoring. However, in TowerGroup’s
opinion, with the advent of SOA, data integration tools, and homogenized payment standards,
banks can benefit by implementing a consolidated payments hub based on the intrinsic
characteristics of payments data if they do so in phases over time, as described above. Exhibit 5
shows the benefits of such a strategy.

12
© 2008 The Tower Group, Inc.
May not be reproduced by any means without express permission. All rights reserved.
 One Hub or Two? Implementation Approaches to Enterprise Payment Hubs

Exhibit 5

Benefits to a Bank of Implementing a Consolidated

Payments Hub

Benefit Details
Uniform payments processing • Hub promotes process and operational consistency.
• Payments services can be reused by multiple payment types and leveraged
across multiple business units.
Payments data consistency • A single data warehouse of payments data provides a consistent and
consolidated view of the payments business.
• Internal operations derive value for managing risk and exceptions.
• The bank can leverage consistent view of payments data to provide value to
product management and bank clients.
Reduced operating costs • Reduces the duplication of function and process in operations units (e.g.,
compliance scanning and exception management).
• Staff can be deployed more efficiently.
Reduced IT support costs • Use of a hub reduces the number of physical payment applications and
hardware infrastructures requiring IT support.
• Support skills requirements can be consolidated.
• Savings in recurring license and maintenance fees are realized.
Consistent recovery • A hub provides a consistent, managed disaster recovery process.
• Having a hub simplifies recovery of both technology operations and business
to remote locations.
• Multiple hubs will process transactions differently and have different recovery
characteristics.

Exhibit #: 5
Source: TowerGroup

Countering the efficiencies and potential technology cost savings to be gained are some significant
challenges. Many are arise from the cultural legacy of a divided banking organization rather than
from technology. Banks must address these challenges organizationally to move forward with a
central payments hub.

Politics, Goals, and Objectives

The retail and wholesale payments business units of a bank are organizationally and politically
different. The wholesale business has higher margins and lower volumes than its retail payments
counterpart. Although the two payments businesses face common pressures, the most acute pain
points may not be shared across these business units in a single organization. As a result, the
incentive and reward structures for senior and executive management may not be aligned across
these verticals.

Current State Technology

The underlying legacy technology platforms of the retail and wholesale business units are likely
different. Although not an inhibitor to a consolidated platform, the starting point for an enterprise
payments project is different for each entity. Migrating to a new platform presents challenges with
exit costs, particularly for a legacy environment supporting another application. A bank’s
payments business strategy and current technology constraints must ultimately determine the
implementation approach for a payments hub. Although the business case will depend

13
© 2008 The Tower Group, Inc.
May not be reproduced by any means without express permission. All rights reserved.
 One Hub or Two? Implementation Approaches to Enterprise Payment Hubs

predominantly on the merits of a hub for wholesale payments since that is where the highest
margins are generated, the objective of a combined, shared payments hub is a worthy goal that
leading banks will strive to achieve.

With a cross-business-unit mandate and collaborative involvement of payment services

management across the organization, several global banks have been able to develop cohesive
payments strategies. The key to attaining a single hub objective is the governance of the
necessary tactical projects that are necessary to implement the solution. Exhibit 6 shows an
abstract migration path from the “spaghetti-ware” of the current environment to a single
payments hub.

Exhibit 6

Road Map for a Bank’s Phased Implementation of a

Payments Hub

Phase n..
ap
adM Potential legacy application
Ro replacement
Phase 3:
Incremental product or
operational improvements
Phase 2:
Solutions to address critical pain points,
cost savings, recognizing revenue
Phase 1:
Base software, integration technology,
database, and hardware
Exhibit #:6
Source: TowerGroup

The critical feature here is agreement on a strategic road map for the implementation of a
payments hub. Strong sponsorship and governance is required to ensure that projects align with
the end goal. Although the details and project road map will be different for any given institution,
with appropriate project governance a consolidated hub can provide operational and technology
efficiencies to both the retail and wholesale banking business units.

The starting point for a road map will differ by institution. Typically the start is driven by a
pressing need to exit a technology or cost (by replacement or outsourcing), capitalize on an
achievable revenue opportunity, or to generate some other form of operational efficiency. Every
bank is different, but the basic steps to a gradual transformation are shown in Exhibit 6.

14
© 2008 The Tower Group, Inc.
May not be reproduced by any means without express permission. All rights reserved.
 One Hub or Two? Implementation Approaches to Enterprise Payment Hubs

The initial road map can be likened to a cross-country road trip from the east to the west coast of
the United States. Starting points could vary from New York to Miami, and the destination could be
between Los Angeles and Seattle. Once those parameters have been set, the next decision is to
select the most appropriate vehicle for the journey, and then define the stopping points, or check
points, along the route.

Returning to a payments strategy, banks must identify the gap between the current state and the
strategic objective, select appropriate technology solutions, and then map out the phases from
day one to the end of the journey. Each day of the journey is an achievement and provides value
in its own right but also acts as the starting point for the next phase. Such an approach allows for
unplanned changes along the route, as might be imposed by economic conditions or regulatory
requirements. The right technology framework is adaptable to changing conditions and can adjust
to the bank’s changing strategy.

Payment Reengineering at Wachovia

Wachovia is the fourth largest bank in the United States, with assets of over $700 billion. In
addition to its vast US presence, Wachovia also maintains 44 offices overseas to support its
correspondent banking operations. For a bank of this size, payment processing is of strategic
importance not only as a sustainable revenue stream but also as a vehicle for future growth. The
bank sees innovation as a key differentiator to remain competitive and attract new business, and
it desired a new breed of flexible payment solutions to offer client value beyond the traditional
commodity of payment processing.

In selecting a payments solution, Wachovia set out with three fundamental goals:

• Integration of multiple payment types and systems

• Tracking and tracing of payments
• Rapid development of new products and faster time to market

Wachovia implemented a payments solution from IBM based on WebSphere components. Using an
SOA model and leveraging the intellectual capital and development assets of IBM’s Dublin lab, the
resulting solution provides payment services that are reusable across multiple payment types. The
solution allows for the integration of multiple payments systems and provides Wachovia with the
payments management and tracking capability demanded by the operations unit. A separation
layer was created between the front-end delivery channels and back-office processing applications
to reduce complexity of integration and to ease future product development. Wachovia claims the
solution saves up to 50% in the time and cost of delivering new payments services to the
marketplace and sees this as a strategic payments platform of the future.

15
© 2008 The Tower Group, Inc.
May not be reproduced by any means without express permission. All rights reserved.
 One Hub or Two? Implementation Approaches to Enterprise Payment Hubs

Conclusion
TowerGroup concludes that banks should implement a payments hub starting with the wholesale
business unit. The implementation should be phased and evolve to include retail payments if the
strategy and political climate of the organization permit. Any reengineering project should be
based on a SOA model that addresses business and technology services. TowerGroup believes that
the ISO 20022 XML schemas can play a foundational role in the integration and management of
payments data. A road map of phased developments, funded through a series of tactical initiatives
(but governed by an overarching strategy) is a requirement to manage project scope, cost, and
risk. Over time, such an approach allows the bank to remain agile in its strategy and achieve its
reengineering goals.

Every bank has its own pain points, priorities, and short-term objectives, as does each internal
business unit. Although a consolidated retail and wholesale payments hub is technically feasible, in
many ways organizational issues pose a greater challenge than technology.

IBM Corp. and ACI Worldwide commissioned TowerGroup to conduct independent research and
analysis of trends in the global payments industry and the adoption of payment hubs. The content
of this report is the product of TowerGroup and is based on independent, unbiased research not
tied to any vendor product or solution. Although every effort has been taken to verify the accuracy
of this information, neither TowerGroup nor the sponsor of this report can accept any
responsibility or liability for reliance by any person on this research or any of the information,
opinions, or conclusions set out in the report.

16
© 2008 The Tower Group, Inc.
May not be reproduced by any means without express permission. All rights reserved.