Built over decades, banks’ payments processing
systems have evolved as disconnected silos resulting in costly
functionality duplication and impediments to competing against
non-bank entrants into the market. A solution to this pressing
problem is to be found in the relatively new concept of payment
hubs.
Intensifying competition, regulatory change and
keeping pace with rapidly evolving customer demands are but a few
factors working to put pressure on banks’ profit margins in the
payments space. A solution being increasingly promoted by
technology vendors is the centralised enterprise payments hub
which, as consultancy TowerGroup puts it, addresses the problems
created by a ‘spaghetti-ware’ of payments systems that have evolved
over several decades.
A leading proponent of payments hubs, Belgian
payment processing technology vendor Clear2Pay, put the evolution
of the payments spaghetti-ware into perspective in a recent
analysis.
Three decades ago the automated clearing house
(ACH) made its appearance to process low value high volume payments
that today originate from a diverse array of channels including
cheques and other paper instruments, telephone, file transfer,
branch and internet. Each of these channels, stressed Clear2Pay,
usually has its own infrastructure, including technology and
people, to ensure that payments are pre-processed correctly before
they are forwarded to the ACH for settlement.
A more recent development was the introduction
of real-time gross settlement (RTGS) systems for low-volume,
high-value payments. Unfortunately, noted Clear2Pay, advantage was
not taken of a significant amount of overlap between ACH and RTGS
systems which are, in essence, both just a different payment type
that require an account to be debited and an account to be
credited. Instead, banks and clearing houses created a new set of
infrastructure that includes both technology and people.
Complexity was further entrenched by rapid
growth in cross-border payments for which neither ACH nor RTGS
systems were designed to cope. This led to the creation by a number
of major banks of the Society for Worldwide Interbank Financial
Telecommunication (SWIFT) payments messaging service.
SWIFT brought with it yet another separate
infrastructure and due to the nature and complexity of instructions
often requires a large back office staff to manually repair
payments that have been entered into the system in error. Clear2Pay
highlighted that it is also very common for SWIFT payments not to
utilise straight through processing. As an example, a significant
number of internet banking systems only capture the cross-border
instruction and a bank clerk is required to re-key the instruction
into a SWIFT terminal, a process that Clear2Pay stressed “is costly
and fraught with error”.
Add to ACH, RTGS and SWIFT credit and debit
card payments that are typically housed in a separate division with
its own infrastructure and the complexity of bank’s overall
payments universe soon becomes, as Clear2Pay aptly put it,
exponential.
Duplication can also lead to other bizarre
situations such as one noted by TowerGroup where staff performing
the same function, such as exception reporting, in one department
may be unaware of the similar function being performed on the next
floor, even if it is for the same client.
Complexity has been compounded by consolidation
in the banking industry as mergers and acquisitions have not, as
may have been hoped, been the catalyst to merge
infrastructure.
“It is not unusual to see the combined entity
having two ACH systems, two RTGS systems and at least two card
systems,” noted Clear2Pay.
Highlighting the inefficiency of the current
situation, Clear2Pay cited research by Boston Consulting Group
which revealed that although banks on average generate 35 percent
of total revenues through payments, payment infrastructures account
for 40 percent of their total costs.
Concluding its review of the current situation,
Clear2Pay warned: “Without a major rationalisation of
infrastructures, many bank groups will be unfit for the upcoming
strategic decisions. Payments, instead of bank-rolling strategic
expansion will inhibit growth and constrain developments.”
Rationalisation is however easier said than
done. Not only is there a multiplicity of payment silos within the
typical bank, TowerGroup emphasised there is also a multiplicity of
legacy back-office payment applications dating back to the1970s and
1980s running alongside new technology developed to meet new
product and regulatory demands.
Clear2Pay underscored this point in its
analysis noting many of the payment systems still in use are
outdated, difficult to support, and in many cases are running on
technology platforms that are, or will soon be, no longer
supported.
Enter the payments hub

Numerous technology vendors have produced solutions to solve the
spaghetti-ware problem. All the solutions essentially revolve
around the use of service oriented architecture (SOA) to create a
payments hub providing interoperability between and centralised,
enterprise-wide control of disparate payments systems.

SOA itself is, however, a vague concept.
Tower Group proposes the following
interpretation: “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.”
Tower Group noted that a basic example of SOA
in a payment processing environment is re-use of a processing
function. Expanding on this the consultancy explained that, for
instance, many legacy applications include proprietary processes
for screening to comply with national regulations such as those of
the Office of Foreign Asset Control in the US. 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,” stressed TowerGroup.
The focus of a SOA-driven payments hub strategy
is to eliminate wherever feasible inefficiencies. In addition it
should provide operations staff with what TowerGroup terms “a
single view of a given client’s payments activity,” thus providing
improved risk management and the ability to enhance client
service.
In essence, features common to payments hubs
are:

• All transactions go through the hub

• All payment initiation methods are
accepted
• There is a standard interface for existing
and new payment systems
• Payments are automatically routed to the
least-cost method.

An insightful description of a payments hub is provided by
consultancy Gartner which defines it is as: “An intelligent and
central engine, enforcing the capture and mapping of payment
information, as well as the rules for all the different workflows,
clearing and settlement routes and risk mitigation
procedures.”

GlobalData Strategic Intelligence

US Tariffs are shifting - will you react or anticipate?

Don’t let policy changes catch you off guard. Stay proactive with real-time data and expert analysis.

By GlobalData
Expanding on its definition Gartner explains
that the payment hub manages the commonalities between existing
payment ‘silos’ and acts as the ‘middleman’ between payment
origination, settlement systems, payment services and support, and
payment processing. It contains routing functionalities, handles
repair and exception, processes flow control and monitoring, and
contains an audit logging and security features.
“In other words, all payment instructions go
through the payment hub, which behaves according to pre-set rules,”
stressed Gartner.
One of key benefits derived from payment hubs
which analysts and vendors highlight is the ability to deliver
enhanced customer service. This, they emphasise, is vital in a
world where banks are increasingly facing competition from
alternate payments service providers such as PayPal and potentially
mobile phone service operators eager to exploit emerging mobile
payments opportunities.
The conventional response of banks to
competition from new payment market entrants has been to add new
services through additional delivery channels such as the internet.
However in the absence of a flexible payments architecture provided
by a payments hub approach, integration with the traditional
back-office becomes increasingly complex and disruptive, noted
TowerGroup.
Underscoring this view Clear2Pay noted in its
analysis: “Organisationally, banks have traditionally not viewed
payments as a line of business but more as a hygiene factor; you
need it and as long as it works, it is fine.”
However, Clear2Pay stressed: “It is becoming
widely accepted that for a bank to maintain a competitive advantage
and for payments to become an asset this view has to change.”
Central to that change, believes the vendor, is
that payments processing should be managed “across the enterprise,”
something a payments hub is designed to facilitate.
Sentiment among US banks towards payment hubs
was brought under the spotlight by a survey undertaken by bill
payment service specialist CheckFree, a unit of US financial
services technology developer Fiserv, conducted at its 2008
software customer conference. The conference was attended by more
than 200 treasury, operations and technology executives and
managers from banks.
CheckFree’s survey revealed that bank
executives responsible for managing payment systems agree that
capturing information across multiple payment channels is a big
challenge. However, despite 85 percent of survey respondents
agreeing that gathering and compiling information across multiple
payment systems is difficult within their organisation there was no
consensus on when and how payments hub technology will be ready to
meet the challenge of managing and reporting on all payments across
those different channels.
Indeed there was disagreement among bankers
working in payments responding to the question: “What is a payments
hub?” Some 60 percent said a payments hub was a fully integrated
common platform for managing all payments processes; 20 percent
viewed it as a reporting tool that overlays existing payment
systems; while 10 percent believed it entails using disparate
technologies within one staffing center. The remaining 15 percent
had yet other definitions.
Education of bankers appears to be needed. Only
25 percent of survey respondents agreed with the statement that a
payments hub is “a solution whose time has come” while 15 percent
viewed payments hubs as “an appealing idea, but the technology is
not yet available.” The largest group – some 45 percent – said they
wanted to learn more before commenting on the promise of payment
hubs.
Certainly Wachovia, the US’ fourth largest
bank, believes the payment hub’s time has come and earlier this
year implemented what the bank’s senior vice-president and
technology MD, Leigh Ferrante termed “a more hub-based business
model supported by an SOA-based IT strategy”.
Assigned to IBM, the planning and design phase
of the project lasted two months while implementation was completed
in eight months.
Wachovia’s objective in what represented a
radical revamp of its payments infrastructure was to move toward a
more flexible platform that would enable it to move more quickly in
response to market opportunities and rapidly changing compliance
requirements by substantially reduce testing requirements when
systems changes were made. In Wachovia’s case each of the 25
interfaces into its payments system employed a point-to-point
integration scheme that needed to be retested anytime the system
was changed, a costly and time consuming exercise.
IBM explained that a key part of the bank’s
goal was to put in place an architecture that would insulate its
backend payments systems from any changes that may take place on
the front end of the system, such as plugging in a new application
or incorporating the payments system of a recently acquired bank,
an increasingly common scenario in the banking industry.
What makes Wachovia’s payments solution so
flexible, stressed IBM, is its reliance on SOA to ‘unbundle’ rigid
standalone interfaces into a pool of generalised, loosely-coupled
and reusable services that can be reassembled as needed.
In IBM’s solution many functional components
that are common – such as rules engines, account validation and
auditing – IBM’s WebSphere MQ communications software is used as
the messaging backbone to access existing core services through
standard connections. Points of difference, such as data formats
and protocols, are handled by IBM WebSphere Message Broker which,
IBM terms ‘an intelligent hub’ that allows business information to
flow between disparate applications across multiple hardware and
software platforms.
Wachovia was the first bank to implement this
type of enterprise payments platform based on IBM middleware and
results have clearly lived up to expectations. Among benefits to
Wachovia highlighted are:
• A 50 percent reduction in the time and cost
required to modify, upgrade and add new interfaces into the
payments system
• Significantly lower compliance costs
• Faster time to market through streamlined
application development
• Enhanced ability to differentiate through
value-added, payments-oriented services
• Improved adaptability to changes in global
payment standards
• Increased customer satisfaction and
retention.

“SOA has given us a clear advantage in the kinds of attributes that
banks now have to excel – speed, flexibility and efficiency,” said
Ferrante.