Tower Group Report - Payments

Commonwealth Bank of Australia's Universal Payment
Capability: A Case Study in Payments Hub Creation
Analyst Author: Andy Schmidt
Research Director, Global Payments
October 18, 2010
Reference # V65:03P
TowerGroup Key Findings
Report Coverage
Payment systems support one of the primary functions of a financial institution: the movement of
funds from one point to another. Banks face challenges today because many of their systems were
installed decades ago when reuse and interoperability were neither considerations nor
requirements. Growing payment volumes and pressures on efficiency, resilience, and compliance
are driving many financial services institutions (FSIs) to replace aging legacy systems with modern
payment capabilities centered on a suite of shared services.
This TowerGroup Research Note examines Commonwealth Bank of Australia's initiative to
revitalize its payments infrastructure and integrate its constituent banks on a common platform by
implementing a payments hub. This case study reviews critical success factors, ongoing
challenges, and lessons learned during the project, and it outlines the issues that banks like
Commonwealth Bank of Australia must consider when deciding to implement a payments hub.
A Brief Overview of Payments Hubs
TowerGroup has written extensively about payments hubs in the past, outlining the drivers of and
barriers to adoption as well as identifying the key payments hub vendors and their offerings.
Originally, payment infrastructures consisted of mainframe applications designed to meet the needs
of an individual line of business or payment type and included tasks such as authorization and
sanctions screening. These applications were self-contained, often monolithic installations that
were not designed to share resources because it was assumed that each payment type was
different. Over time, these applications grew into payments silos requiring extensive customization
to meet changing market needs.
• Many banks are examining payments hubs as a solution for modernizing payments
infrastructure in order to remain competitive and assuage regulators' concerns over their
resiliency and compliance.
• The embedded nature of legacy payment systems impedes the accurate quantification of the
costs of existing infrastructure or the future benefits of modernization.
• The assessment of infrastructure reusability as a complement to return on investment is
becoming increasingly important for projects involving a move from siloed to enterprise
architectures.
• Commonwealth Bank of Australia implemented an integrated solution that will support the
evolving needs of its corporate and retail customers across all payment types within a single
environment.
• The creation of the bank's Universal Payments Capability is part of a much larger core
replacement project designed to upgrade the bank's systems overall.
© 2002 - 2010 The Tower Group, Inc. May not be reproduced by any means without express permission. All rights reserved.
1

Today, the use of service-oriented architecture (SOA) means that business logic that resided in the
payment silos can be made available as a service to multiple applications as needed. This
approach provides banks with much greater flexibility in constructing systems because key
elements can be reused repeatedly, enabling banks to modernize their payments systems step by
step rather than having to undertake wholesale replacement of systems.
Creating the Universal Payment Capability at CBA
Overview of Commonwealth Bank of Australia
Headquartered in Sydney, Commonwealth Bank of Australia (CBA) is one of the largest banks in
Australia, reporting total assets of $646 billion (AUD) ($553 billion USD) as of June 30, 2010. CBA
is also the largest transaction processor in Australia, processing more than 5 million transactions
per day.
CBA is a leading provider of financial services in the Australian market. These services include a
full suite of services for the retail, wholesale, institutional, and high-net-worth markets as well as
insurance, brokerage, and investment services. Supporting these services is the bank's strong
commitment to customer service.
The bank is a multinational institution with branches in Auckland, Hong Kong, London, Mumbai,
New York, Shanghai, Singapore, and Tokyo and is an institution focused on international
expansion. In addition to ASB Bank in New Zealand, the company owns Commonwealth Bank
Indonesia as well as minority stakes in banks in China and Vietnam. In 2008, CBA bought
Bankwest (Bank of Western Australia) from HBOS for $2.1 billion AUD ($1.5 billion USD) to gain
coverage of Australia's west coast to complement the traditional CBA group's coverage of the
country's east coast and south.
Project Drivers
CBA's move to a payments hubs strategy was part of a larger core-infrastructure modernization
program. The bank's deposit and lending systems had become heavily siloed and inflexible, which
led to the bank's decision to update its infrastructure in order to meet its future needs and remain
competitive in a changing marketplace. The result was the $750 million (AUD) Core Banking
Modernization program, which began in 2007.
The bank's payments hub strategy evolved from a realization that the interaction between the
bank's payments systems and the core infrastructure required a similar modernization effort. The
payment infrastructure had grown to more than 70 payments-related systems, including
assemblers, mainframe applications written in COBOL, and numerous applications dating back as
many as 40 years and rapidly approaching obsolescence. Having multiple point-to-point
integrations with payments logic scattered across channels, integration layers, and product systems
meant that changes necessitated significant regression testing frequently costing more than the
development effort. The fragmented state of CBA's payment infrastructure prior to its payments hub
project is shown in Exhibit 1.
2

Exhibit 1
Commonwealth Bank of Australia's Payment Infrastructure: Before Payments Hub Project
Source: Commonwealth Bank of Australia
The fragmented architecture left the bank concerned about payments system obsolescence and
agility, especially because CBA was already modernizing other systems in the channel and product
spaces. Adding to this concern was the strong interest expressed by the Australian Prudential
Regulation Authority (APRA) in increasing competition in the Australian market via payments
innovation, an outcome that an inflexible payments infrastructure would certainly hinder if not
prevent outright.
Further examination of the payments infrastructure revealed 10 major projects that were touching
the bank's payments systems. CBA combined the projects and used the opportunity to modernize
the payments infrastructure and establish a clear architecture for what the bank calls the Universal
Payment Capability (UPC). Although the ROI for making incremental changes to existing
infrastructure would have been more advantageous than the ROI for moving to a payments hub
environment, CBA's executive leadership realized that (as is the case with most established banks)
years of underinvestment had left the bank ill positioned to meet changing market and regulatory
needs. This realization led the bank's CIO and CEO to champion the additional investment needed
to move the bank's payments capabilities to their target state.
CBA's long-term strategy focused on reusability of the payments hub. The argument was that
creating a common payments platform would reduce the bank's cost/income ratio and remove risk
from subsequent payments projects while positioning the bank to be able to respond to emerging
payments trends, including mobile payments and real-time payments. The benefits of reusability as
a complement to ROI are discussed in greater detail in Exhibit 2, which lists the business drivers
3

behind the bank's payments hub project.
Exhibit 2
Business Drivers of Commonwealth Bank of Australia's Payments Hub Project (2010)
Source: Commonwealth Bank of Australia, TowerGroup
Evaluating Solutions
In 2007 and 2008, Commonwealth Bank of Australia's Enterprise Services Group defined the
bank's payments infrastructure requirements, taking into consideration the bank's broad business
and geographic footprints to create the target architecture. The bank also examined two possible
approaches for obtaining a payments hub.
The first approach called for the bank itself to build a payments services hub. However, in light of its
past experience with outside providers and the importance of taking an enterprise approach to
payments, the bank quickly ruled out this option.
The second approach involved selecting a vendor with very specific technical and business
expertise. The desired technical expertise centered on the vendor's ability to create a modern SOA
architecture and structured development framework. To CBA, this meant the vendor would have to
be familiar with J2EE, IBM Websphere, and Oracle databases and have expertise with AIX and x86
Linux systems.
Once a vendor satisfied the project's technical requirements, it would have to align with CBA's
business strategy. Six vendors made it to CBA's short list, and two vendors made it to the proof-of-
concept stage in October 2008. Shortly thereafter, CBA selected Clear2Pay and its Open Payment
Framework to help create the bank's payments hub, the UPC. As discussed in TowerGroup
Research Note V63:21P, Payments Hub Vendor Roundup: More Players, Greater Capabilities,
4

Belgium-based Clear2Pay was founded in 2001 and focuses exclusively on payments processing
solutions. Its product lines include remittance processing and electronic bill payments solutions in
addition to the comprehensive enterprise payments solution.
Released in 2006, Clear2Pay's Open Payments Framework (OPF) is sold as a unified payments
solution for all payment types, including real-time card transactions, across all lines of business.
Clear2Pay uses open standards such as ISO 20022, ISO 8583, and Java J2EE and markets OPF
as a universal platform designed to accelerate and streamline payment processing. The payments
hub portion of OPF is a central payments hub designed to process payments of any type within a
single system (from batch low-value payments to time-critical high-care payments to real-time cards
payments). The vendor has defined numerous hub services, including validation, routing, and
formatting of payment transactions as well as auto-enrichment, reconciliation, and exception
management.
For CBA, the selection of Clear2Pay was the result of a number of factors. The primary factor was
CBA's perception that Clear2Pay's solution offered the best product architecture regarding open
payment standards like ISO 20022 in addition to a structured development framework. CBA also
believed that Clear2Pay had the most mature solution of the vendors it considered, meaning that
the bank would not be tied to ongoing development efforts. Reinforcing the choice was the
relationship the two companies already had through a company named Sienna, which Clear2Pay's
APAC division had purchased in 2004. CBA has been using Sienna's BillView Integrator since 2003
as part of the bank's BPAY View offering, which enables customers to receive and view their bills
online.
Implementation Strategy and Solution Components
Support of the core banking platform was a major driver in the implementation phase of the bank's
payments hub. CBA created a tightly integrated project team from across the bank's Enterprise
Services Group. This team included members of the banks' architecture, infrastructure, project
management, and risk teams as well as numerous Clear2Pay representatives. The involvement of
these key stakeholders was critical to the successful rollout of the first iteration of the CBA UPC.
CBA relied heavily on Clear2Pay for architectural input to meet the payment requirements of the
core banking platform. CBA benefited from Clear2Pay's deployment experience in high-
volume/high-availability environments requiring low latency. Clear2Pay also delivered
customization and configuration services specific to CBA systems as the bank became more
familiar with the Clear2Pay stack, performing the necessary software development offsite and
providing successive releases back into the CBA environment.
The initial phase of the project began in October 2008 with the bank building the infrastructure
needed to route payment flows through the payments hub to the core banking system. These flows
of automated teller machine (ATM) transactions and payments via electronic funds transfer at point
of sale (EFTPOS) from retailers' locations are processed bilaterally across financial institution
interchange links. The payments include credit, debit, and charge card payments made at point of
sale as well as cash back at the point of sale. The initial project went live in July 2009 and was
followed by a project to route all of the bank's SWIFT messages through a central sanctions
screening engine within the hub, a phase that was completed in February 2010.
Results: Progress Toward the Target State
The project phases have been successful in moving Commonwealth Bank of Australia toward its
target architectural state, and CBA has been busily bringing its many banks and information
streams into the hub environment, though it will take time for CBA to reap the full benefits of its
payments hub, the UPC. The current state of the bank's payments infrastructure, reflecting the first
stage in the migration of business logic from the payments applications to the payments hub, is
shown in Exhibit 3.
5

Exhibit 3
Commonwealth Bank of Australia's Payments Hub: Current State (2010)
The results of the initial phases of CBA's payments hub implementation through the end of
September 2010 are as follows:
System Migration into the UPC
ATM and EFTPOS volumes already flow through the hub for the Australian state of Tasmania; the
volumes for the five remaining Australian states will follow by the end of 2010. After this milestone,
the bulk of the bank's ATM and EFTPOS transaction volume will transfer from the bank's legacy
systems to the payments hub flow over the subsequent few months when approximately 10 million
transaction accounts are migrated to the new core banking platform.
SWIFT traffic has ramped up quickly as all SWIFT messages for CBA, Bankwest, ASB, and the
bank's Mumbai office currently flow through the payments hub for sanctions checking against a
single list. SWIFT traffic within Asia will be added shortly (and quickly) based on the integration and
configuration information the bank has gained in bringing the ASB and Mumbai into the hub without
Clear2Pay's involvement.
Bulk payments will move into the hub in October 2010, replacing the three systems previously
performing this function.
6

Compliance, Payments Visibility, and Uptime
Commonwealth Bank of Australia reports that the UPC also provides greater system uptime and
payments visibility than its legacy predecessor systems. The SWIFT implementation has seen
nearly 100% uptime since launch, and the screening of all SWIFT traffic against a single sanctions
list creates greater consistency among the bank's anti-money laundering activities.
Reusability, ROI, and the Enterprise Architecture Score
A positive ROI was not the primary criterion in moving forward with the payments hub. Instead,
CBA focused on strategic reusability of the enterprise architecture. This focus represents a cultural
change that has opened discussions with the bank's lines of business about platform capabilities
rather than development costs.
The change led CBA to create an "Enterprise Architecture" (EA) Score, which measures a project's
alignment with the bank's IT principles. The EA Score is gauged in addition to ROI when examining
new projects. The score, a composite of four technical measures and one experiential measure,
has been required for all technology projects with budgets greater than $1 million (AUD) since
August 1, 2008.
Exhibit 4
Components of Commonwealth Bank of Australia's Enterprise Architecture (EA) Score (2010)
When CBA developed its EA score, the architectural measures for each project received a score of
+1 or –1. A score of +1 is given if the measure advances the bank's Enterprise Architecture goals
toward the target state and using payment standards; a score of –1 is given if it does not, although
a negative score only indicates that there isn't a benefit to CBA beyond the financial ROI.
7

A score of zero was seen as "sitting on the fence" and thus was not allowed. A score indicating
whether the project improved the user's experience was added to reflect the bank's focus on
customer service. Once the architectural and customer measures have been scored, the project's
final score is tabulated and assigned to the project for the solution delivery life cycle and
governance processes ensure that the project does not deviate from the intended outcome.
The purpose of the EA score is to indicate whether a project's scope supports the reuse of existing
architecture. For example, the original portion of the bank's payments hub project received a
negative EA score because it required new architecture. The EA scores for subsequent projects
related to the hub have gradually improved because of the projects' reuse of the hub architecture.
Lessons Learned
In addition to the elements described above, CBA has been able to use the Clear2Pay framework
to integrate systems into the payments hub on its own because the architecture and necessary
configurations have already been built. This environment turns integration into a relatively simple
configuration exercise instead of requiring new business logic. The benefit is twofold: CBA is able
to integrate additional banks and lines of business into the hub environment more quickly than
originally anticipated, and it can do so without the expense of professional services fees.
Platform for Discussion and Knowledge Sharing
Although still in the midst of implementing the UPC, CBA is using its payments hub as a platform
for discussion with other banks seeking to modernize their own payments capabilities. TowerGroup
believes that forums such as these add significant value to the industry by creating a dialogue on
the capabilities and shortcomings of a payments hub infrastructure. These dialogues can also
clarify the differences between various pieces of payments infrastructure (as well as when to use
them), a topic that TowerGroup will be examining in greater detail.
What All Banks Must Consider Regarding Payments Hubs
TowerGroup believes that payments hubs greatly aid banks in developing agile, efficient, and
resilient payments systems capable of supporting current and future client needs. However,
TowerGroup also believes there are a number of issues for all banks to consider when deciding
whether to implement a payments hub.
Ongoing Challenge of Calculating Costs and Monetizing Efficiencies
In building a case for a payments hub, CBA highlighted a challenge faced by many institutions: the
inability to calculate the true cost of their payments infrastructure. Without a starting point, it is
impossible for banks to measure the impact that any project has on performance or development
costs other than in a holistic manner based on the assumption that products and systems using
flexible processes require less time and effort to build and are easier to maintain.
Banks seeking to become best in class must take strides to measure, manage, and understand the
cost of doing business both before and after implementation of a payments hub. And they must
develop a methodology for tracking subsequent development costs (e.g., for new products) once
they have a clearer understanding of the infrastructure to add science to the art of payments
infrastructure spending. Neglecting to do so will further obfuscate the very costs the hub is intended
to reduce, making it impossible to gauge the impact of future projects.
Reusability May Only Work for Large Banks
In many ways, CBA's payments hub is a unique case in that it rode the coattails of a significantly
larger project. While the EA Score is truly a valuable measure, many banks, especially in the
middle tier by assets and smaller, will still maintain cost discipline by focusing on tangible results
like ROI despite the inherent efficiencies of a service-oriented architecture. CBA has greatly
mitigated its potentially negative focus on reusability by instituting its EA Score methodology.
However, the growing trend to consider past underinvestment in payments infrastructure as
justification for sidestepping ROI when seeking to create a desired state is an unsustainable
8

business model.
Likewise, most announced payments hub projects are compliance based (e.g., for compliance with
the Single Euro Payments Area, SEPA) in a world where compliance projects get funding in order
to avoid potential consequences. Although this project does have an element of compliance to it in
the form of pressure from APRA, the demand for a positive ROI will be higher in regions lacking
similar compliance pressures.
Executive Sponsorship Is Paramount
CBA's executive leadership aligned the pioneering nature of the UPC with the bank's corporate
objectives and had the clout to get funding via its Core Banking Modernization program. Because
the move from a siloed infrastructure to a payments hub is a completely new way of doing business
for most FSIs and can have an impact that is difficult to measure despite the costs involved, these
decisions must often come from the top of the organization to succeed. This is because line-of-
business heads, though keenly aware of the benefits a payments hub provides, often lack the
institutional gravitas necessary to guide these projects to fruition.
Next Steps
CBA is maintaining the momentum gained in the ATM and EFTPOS projects by moving more
functionality into the hub environment. The bank expects to move all of its ATM/EFTPOS payment
volumes into the hub by May 2011 and will be moving the following systems into the hub over the
next 24 months:
• Real-time transaction monitoring
• Liquidity management
• Payment message triage, repair, and enrichment
• Alert triggers
• Rerouting of transactions from one clearing stream to another to increase efficiencies
• Removal of significant portions of payment logic from two of the bank's payment channels (CBA's
customer service portal, NetBank, and online business banking portal, CommBiz) for integration
into the hub
These actions will allow CBA to achieve its desired target state, in which all business logic and
payment volumes have moved from the siloed applications into the payments hub as shown in
Exhibit 5.
9

Exhibit 5
Commonwealth Bank of Australia's Payment Hub: Future State
Summary
Commonwealth Bank of Australia's decision to modernize its core banking and payments platforms
simultaneously was a bold statement that the systems of the past cannot support the business
needs of the future — or even the present. Many banks face similar decisions as they examine
whether their past investments position them to compete in a rapidly evolving payments world as
increasing global payment volumes and market initiatives like mobile and real-time payments push
legacy systems to their limits.
Investing in a flexible, service-oriented architecture enables financial services institutions to meet
these challenges head on by simplifying integration, maintenance, and new product development.
Likewise, the improved resiliency and visibility provided by these systems can put regulators' minds
at ease. However, any bank pursuing an SOA strategy must strive to understand its cost structure
before and after implementation if it is to manage its payments business in a fully enterprise
manner.
1 0

Tower Group Report - Payments

Recommended

Recommended

More Related Content

What's hot

What's hot (15)

Viewers also liked

Viewers also liked (14)

Similar to Tower Group Report - Payments

Similar to Tower Group Report - Payments (20)

Tower Group Report - Payments