The Payments Hub Spectrum

Farrow:JSC page.qxd 05/04/2011 17:19 Page 52

Journal of Payments Strategy & Systems Volume 5 Number 1

The Payments Hub Spectrum: A model for
the design of payments hubs

Gary S. D. Farrow
Received (in revised form): 18th February, 2011
Triari Consulting, UK. Tel: +44 (0)7554 423009; Fax: +44 (0)161 445 6508;
e-mail: gary.farrow@triari.co.uk

Gary Farrow is Director of Triari Consulting, payments hub — and the design considerations
provider of systems integration and IT architec- in meeting the current payments industry busi-
ture services for the financial sector. A lead ness drivers. A conceptual model of a payments
architect on many projects, he has undertaken hub is introduced and its business benefits
senior architect roles at major banks. He has described. The functional capabilities of a pay-
broad expertise in large-scale systems integra- ments hub are presented, categorised into three
tion, enterprise service bus architectures and areas: process services; business services; and
service-oriented architecture (SOA) and deep integration services. The technical justification
domain specialism in payments systems. He has for a hub is presented, highlighting its role in
written many articles on SOA and payments pro- reducing integration complexity and in support-
cessing. Gary is a member of the IT Architecture ing modernisation initiatives within a bank.
Certification Board for the Open Group and is an The ‘Payment Hub Spectrum’ is introduced,
Associate Lecturer at the Open University. describing an ordered range of functional serv-
Professional qualifications include Member IET, ices. Depending on the specific business needs of
Chartered Engineer and Open Group Master a bank and its underlying IT systems land-
Certified Architect. He holds BSc and PhD scape, these are shown to dictate a functionally
degrees from Manchester University and a light or a functionally rich payments hub. The
Certificate in Business Administration from business and technical factors affecting the posi-
Warwick Business School, UK. tion on this spectrum are highlighted. In conclu-
sion, the Payments Hub Spectrum is shown to
ABSTRACT be a useful model for solution analysis, inform-
Recent events in the financial sector have given ing the architectural decisions on technology
a high profile to financial services governance. In choice and on the apportionment of payments
the area of payments, there is a need to provide processing capability between the key collaborat-
transparency and traceability of monetary move- ing components.
ments. Other changes in the market environ-
ment include the strengthening of regulations Keywords: payment services hub, pay-
and the introduction of new euro zone payment hub design, payments integration,
ments frameworks. The credit crunch further liquidity management, payments capa-
highlighted the need to monitor systemic risk bility model
exposure associated with settlement — espe-
Journal of Payments Strategy &
Systems
cially for the major clearing banks that process
Vol. 5 No. 1, 2011, pp. 52–72 payments for their agency banks. This paper PAYMENTS HUB OVERVIEW
᭧ Henry Stewart Publications,
1750–1806 describes a specialised IT component — the Figure 1 shows a context diagram of a

Page 52


Farrow

Figure 1
Payments high-level
Business partners
system overview
Agency
Other banks
schemes

Payment hub

Product
systems

payments hub at a conceptual level. Sub- received from and sent to the schemes and
systems that interact with a payments hub business partners in a variety of industry
are: formats.

• Product systems: these systems domicile Capabilities
the banking ledgers that are the source Consider a service-oriented architecture
and destination for payments. (SOA) perspective applied to payments
• Channel systems: these systems support processing. Using a simple layered refer-
the customer channels through which ence model for SOA,2 a payments hub can
payment services are offered. These typ- be considered to provide three major cat-
ically include: branch; Internet; and egories of service capability:
telephony. In the future, it is expected
that new channels such as mobile pay- (i) process services;
ments, will be introduced.1 (ii) business services;
• Payment gateways: these constitute the (iii) integration services.
gateways to the various payment
schemes. The combination of these different service
types infers that a payments hub is a com-
Electronic payment instruments are plex, ‘compound’ component spanning

Page 53


The Payments Hub Spectrum

three architectural layers. Since the hub • liquidity monitoring;
supports these three different service • liquidity information provision;
types, a single, product mapping is difficult • scheme cap monitoring.
to achieve. Rather, a combination of soft-
ware packages and middleware products is A payments hub can thus track debit and
typically required. credit payment value, and accumulate and
A payments hub contains a variety of maintain a net settlement position against
detailed functional capabilities, each cate- each of the schemes. Related to this, the
gorised into one of these three types. payments hub may also provide informa-
Furthermore, it is shown that specific tion services for enquiring on and report-
capabilities may be apportioned across the ing the liquidity position.
other high-level architectural components, There are several business benefits asso-
ie product systems and gateways. The ciated with undertaking such activities,
exact capabilities required and their appor- and these are described below.
tionment are always uniquely dependent
on the specific business and IT scenarios Integration services
within the bank. Payments processing requires significant
integration capability to connect the
Process services scheme gateways and the product systems.
Payment process services relate to the con- In this respect, a key role of the payments
trol of processing for the completion of hub is to receive all inbound and out-
inbound and outbound payments requests. bound payments and perform:
A payments hub fulfils the role of the
‘process services’ layer in SOA. It will typ- • routing to and from the requisite prod-
ically offer coarse-grained payments serv- uct systems and gateways;
ice, these being themselves composed of • transformation of the payments mes-
several, finer-grained services provided by sages into an appropriate format for
a SOA ‘business services’ layer. In this way, processing by the schemes, product sys-
the systems processing necessary to realise tems and the bank’s business partners.
the value chain3 of a payment can be
achieved. This infers a requirement to support all
Given its role in coordinating fine- bank payments volumes. Similarly, owing
grained business services, the hub is also to the critical nature of payments process-
the sub-system best placed to provide a ing, non-functional characteristics of a
view of the state of a payment as it pro- payments hub are high reliability and
gresses through its value chain. The granu- robustness to systems failure.
larity of the services orchestrated in turn
determines the number of state transitions Justification for payments hubs
defined. This section provides the business and
technical justification for the payments
Business services hub architectural component. The justifi-
A payments hub, potentially, gives visibil- cation is irrespective of any specific vendor
ity of all payments into and out of a bank. technology selection.
On this basis, it is considered the system
component that is best placed to provide Support for core banking modernisation
some specialised business services. These A common banking scenario is the
include replacement of heritage product systems

Page 54


Farrow

Table 1: Example product migration roadmap for a UK clearing bank

As is Release 2 Release 3 Release5 Release 6
Product system 2008 2009 2010 2011 2012

Heritage Retail

Heritage Corporate

Heritage Insurance

Heritage Mortgages

Treasury

Heritage Credit Cards

New Retail

New Corporate

Acquired Mortgages

New Credit Cards

with a new core banking engine. The infers a long-term role for a payments
phasing out of the heritage product sys- hub, rather than a transient role support-
tems and the phasing in of the new core ing the duration of the modernisation
banking product system over a defined programme only.
timeline are illustrated in Table 1, for an
example modernisation programme. Payments integration complexity
A further common scenario is a merger A payments hub solves the classic integra-
with or acquisition of another financial tion problem of reducing the number of
services organisation. This infers the point to point integrations required. The
inheritance of additional product systems complexity of the integration between the
(in the example shown, an additional schemes (S) and the product systems (P) is a
mortgage product system). Realisation of well-known S × P problem. Simplistically,
a given bank’s business strategy may neces- introducing a payments hub, through
sitate future mergers/acquisitions. Hence, which all scheme and product system con-
providing an architectural capability to nections are made, reduces this to an S + P
support efficiently the integration of more problem.
product systems in the future is considered In practice, the scheme integration
good practice. complexity is lower, as not all schemes
From Table 1, it can be seen, even at connect to all product systems. This
the end of the modernisation pro- reduction, however, is partly offset, as the
gramme, that there is still a requirement integration complexity associated with
to support multiple product systems. This certain schemes is very high (eg UK Faster

Page 55



Figure 2
Commonality of
processing in a
SOA process
services layer

Payments) and duplication of integration payments hub is the central point for rout-
effort is not desirable. Any large bank will ing of payments. It may also have a similar,
typically maintain multiple product sys- centralised role in validating inbound and
tems, and so there is a strong justification outbound payment messages. These capa-
for a hub purely on the strength of its bilities require the reference data described
integration role alone. above.
In this respect, adopting a payments hub
Data management simplicity architectural style allows for the reference
Another benefit of the payments hub is data required by these capabilities to be
that it can reduce the complexities associ- deployed once only (or at least a signifi-
ated with master data management of cer- cantly reduced number of times), greatly
tain reference data. Examples of reference simplifying the master data management
data include: problem.

• Industry Sort Code Directory (ISCD). This Architectural simplicity
consists of a database of meta-data Architectural simplicity can potentially be
about all the bank/building society achieved through commonality of pay-
branches and bank offices that partici- ments processing across payments schemes
pate in one or more of the UK clearing (Figure 2). Key to this is the manipulation
systems. These data are necessary to val- of the payment in a common data format.
idate destinations for payments and to In this respect, processing proceeds by first
determine the characteristics of the des- transforming the payment into a common
tination, such as the ability to support a data representation. Once in this ‘canoni-
given scheme. cal form’, a common service can then be
• Internal routing tables. These data equate performed on a payment, irrespective of its
to bank-specific information as to scheme origin. While, overall processing
which IT systems accounts are domi- steps for a payment from a specific scheme
ciled. This allows inbound payments to may be unique, this approach allows reuse
be routed to the correct product system of common processing steps across
and posting applied accordingly. schemes.
Upon completion of this generic pro-
In the conceptual model presented, the cessing, the payment may then be trans-

Page 56


Farrow

Table 2: Payments modernisation benefits and enabling capability of the payments
hub

Customer benefit Description How

Latest payment Customers can benefit from Changes to the heritage product
processing features improved speed to market of future systems are made difficult by the
payments initiatives. lack of documented code and are
constrained by rigid release cycles.
These factors lengthen the delivery
cycle.
By decoupling the product systems
from payments functionality, any
changes required for new payments
initiatives or for regulatory
compliance are less extensive.
The use of specialised middleware in
the implementation of a payments
hub allows new message types and
schemes to be introduced rapidly.

Consistency of service Customers (including bank back The payments hub leverages
office) can benefit from a single commonality in payments
consistent payments service processing. This enables consistency
supporting all schemes. in the way that payments data is
The customer is shielded from captured in the channel, providing a
complexities of scheme simplifying unified and simpler customer
the customer experience. experience.
Common payment processes and
services will be incorporated into
payments processing increasing
consistency of service. Eg:
• data validation services;
• payment submission service;
• scheme independent Fraud
checking;
• anti-money-laundering checks.

Improved transparency The completion of large financial The payments hub has visibility of
transactions by customers is very payments and monitors of the state
important and can often lead to of a given payment.
stressful situations. For example, a The payments hub can expose
customer may be making a major services to specific channels (CRM,
purchase and wish to know that e-banking) to support enquiries on
transfer of credit has completed. the state of a specific payment
The provision of information request.
relating to the status of their The importance of particular
payment information can reassure sensitivities (such as quarantine of
customers that a payment has been potentially fraudulent transactions) is
concluded. This is of great benefit in recognised. Such enquiries will
reducing uncertainty and stress. therefore be sensitive to the specific
reasons for any delay to payments
processing.

Page 57



Table 2: Payments modernisation benefits and enabling capability of the payments
hub (continued)

Customer benefit Description How

Reliability of service Customers will benefit from a robust The payments hub IT architecture
and reliable payments processing should:
service. • operate continuously
Given growth in digital channels, • not permit any loss of payments
payments services must operate on a instructions
24-hour basis, supporting payment • not permit duplication of
requests outside nominal banking payment messages across all
hours. payments schemes
• provide validation of payment
instructions to reduce the
likelihood of payments errors.
Internal customers
Monitoring of liquidity Treasury can benefit from timely The payments hub is the single
position and risk exposure and accurate information on the component that has visibility of all
bank’s settlement position against payments into and out of the bank.
each scheme. It is therefore best placed to
This allows the bank to monitor determine the bank’s financial
exposure against a particular scheme position against a particular payment
and pro-actively manage deferred scheme.
net settlement risk.

Scheme cap monitoring Payment operations benefit from The payments hub may perform
being alerted to situations where the scheme cap monitoring and is able
settlement position is nearing to provide information services
scheme cap limits. In this way they relating to the scheme position
are able to closedown payments for relative to the cap.
a particular scheme in a controlled
way. Payments are diverted to
another scheme, continuing
customer service.
This also prevents a bank from
exceeding the scheme cap limits
with associated disbenefits.

Reduced operational errors The bank’s internal payments The payments hub promotes
operation will benefit from reduced commonality and automation of
errors and higher straight-through payments processing. This simplifies
processing, improving efficiency payments processing, in turn
within the operation. reducing operational errors,
improving efficiency and overall
service quality.

formed into a specific format suitable to Customer benefits
the target sub-system. A design objective The benefits of a payments modernisation
of ‘develop once reuse many times’ is approach provided by a hub are captured
achieved, which can greatly simplify pay- in Table 2. The role of the payments hub
ments processing. in enabling the benefits is also described.

Page 58


Farrow

Figure 3
Payments capability
model

Scheme Limits
Management

Two categories of customer are The model distinguishes between the
observed: realised capabilities and capability facades
— calls to external components. The latter
(i) Bank external customers: These are the are considered equally important, as they
retail and wholesale customers of the relate to a design decision as to the point of
bank. control where the underlying capability is
(ii) Internal customers: These are actors called. For example, a complex underlying
internal to the bank, for example, the capability may be realised by an external
payments operations team and treas- component, but its services may be called
ury. from either the payment hub or the prod-
uct system. It is the placement of the call to
the capability that is significant in the
THE PAYMENTS HUB SPECTRUM design, and therefore the model reflects
such service call placement considerations.
Capability model An overview of the capabilities in the
The functionality required to undertake model is now provided.
payments processing is illustrated in a
capability model. The model illustrates the Account Posting (facade)
payment domain functions in a technol- This capability represents the ability to
ogy and vendor-neutral way. update a product system account.
Subsequently, it is shown that there are Ultimately, the service must be provided
many options for apportioning capabilities by the product system itself. A key design
between the key payments sub-systems issue is whether the posting service is
(Figure 3). called by the payment hub as an internal

Page 59



service of the product system or indirectly AML Service (facade)
through another component facade. The Anti-Money Laundering (AML)
Service is also complex, fulfilling regula-
Account Validation tory requirements relating to anti-money
Account Validation refers to the capability laundering. This capability represents the
to validate the existence of accounts. ability to call the AML Service. This is also
Successful validation of the account may a service call placement issue.
provide the type and status of the account.
Failure to validate the account will typi- Enrichment
cally lead to the rejection of an inbound This capability refers to the enhancement
credit and a return of the payment to the of the payment instruction with additional
scheme. data to enable value-added services to be
performed by the bank. An example of
Almanac this relates to collection accounts. The
The Almanac represents the collection of Enrichment provides for the original col-
meta-data relevant to support the interac- lection account number to be propagated
tion of the bank with its payments scheme with the payment instruction to the target
providers. product system. If there is subsequently an
The meta-data include, for example: issue with the posting of the payment, the
original collection account number is still
• scheme daily operating times; available in the payment instruction for
• scheme non-operating days; use by the payment business operation in
• public holidays. problem analysis.

Diary Management File Validation
The Diary Management capability is This capability refers to format validation,
dependent on the Almanac. Given the against an industry specification, of
meta-data defined in the Almanac, the inbound and outbound bulk payment
Diary Management capability uses these files, eg Bankers’ Automated Clearing
data to determine specific diarised events Services (BACS) Standard 18 file valida-
on a given day. For example, the schedule tion.
of inbound and outbound payment files
expected within the operational working Funds Control (facade)
day. The schedule can be used in turn to Funds Control refers to the capability to
generate alerting mechanisms should, for assess the funds available to fulfil the pay-
example, a file not arrive from the scheme ment, resulting in a pay/no-pay decision.
or be ready to send to the scheme at the Funds Control checking must take into
diarised time. account intra-day payment commitments
and associated fund reservations on a cus-
Fraud Service (facade) tomer’s account. In the case of a retail cus-
The Fraud Service is generally complex, tomer, this is generally a relatively simple
fulfilling regulatory requirements relating assessment. In the case of a corporate cus-
to fraud detection. This capability repre- tomer, this may become more complex,
sents the ability to call the Fraud Service. with Funds Control assessment taking into
As with the Account Posting capability account a net funds position determined
facade, this represents a service call place- from several accounts and perhaps an
ment issue. agreed collateralised credit line.

Page 60


Farrow

Intelligent Payments Routing Payments Repository
Intelligent Payments Routing refers to the The Payments Repository is provided to
capability to select the most appropriate enable a store and forward paradigm. An
method of payment based on general, cus- example is the ability to store future-dated
tomer-defined characteristics of a pay- payments until the scheduled payment
ment. Typical characteristics include cost date. An outbound payment is held until
and speed. the future date is reached, when it subse-
Such selection may also take into quently is released to a scheme. Payments
consideration other factors such as should be held in the preferred canonical
scheme limits on settlement exposure data form until their validity date and then
against the scheme. If the scheme limits converted into the selected scheme-spe-
are being approached, the Intelligent cific format on creation of the payments
Routing capability may discount that instrument.
scheme from the selection process. This
approach is preferable to exceeding the Repair
scheme limits, which would result in the The Repair capability refers to an ability
closure of the scheme to payment sub- to repair payment instructions and hence
missions. improve ‘straight-through processing’ rates.
A repair may relate to simple formatting
Liquidity Monitor repairs, eg the removal of white space in
The Liquidity Monitor refers to the capa- the account number. It may also refer to
bility to accumulate the bank’s settlement more advanced repairs, eg the lookup of a
position against the scheme. In the simple disused sort code/account number and its
case, this may be achieved through a sum- mapping to a successor.
mation of inbound and outbound pay-
ment value. More complex liquidity Routing
monitoring may involve matching of This capability refers to simple payments
notices (eg Society for Worldwide routing, which consists of two main activ-
Interbank Financial Telecommunications ities:
(SWIFT) 210 matching).
(i) destination determination;
Message Validation (ii) logical routing of the payment based
This capability refers to the format valida- on the derived destination.
tion of inbound and outbound payment
instructions for message based payment The Routing capability requires ISCD
schemes, eg SWIFT messaging for data and also IBAN reference data
Clearing House Automated Payment (depending on schemes supported).
Systems (CHAPS) payments.
Scheme Limits Management
Mandate Management Limits refer to the maximum allowable
Mandates refer to both standing order size of the bank’s exposure to the scheme.
mandates for outbound credits and direct Above the scheme limit, payments submit-
debits mandates for outbound direct debit ted to the scheme will be rejected.
instructions or inbound direct debit vali- Exceeding the scheme limit may result in
dation. The Mandate Management capa- a loss of service for a customer — they
bility refers to the creation, maintenance will no longer be able to use that scheme
and execution of such mandates. to fulfil their payments. It is desirable to

Page 61



Figure 4
Payments Hub
Spectrum

achieve a more graceful degradation of the range of potential capabilities with the
service as the scheme limit is approached. capabilities ordered, loosely, by increasing
In this respect, the Limits Monitoring functional richness. This is illustrated in
capability enables this by totalling the Figure 4, showing the placement of the
bank’s exposure to the scheme. When the capabilities from the model within the
limit is approached, within a certain toler- spectrum.
ance, this can trigger an alert to the bank’s A hub design at each of the extremes of
payment operation. the spectrum will have significantly differ-
ent characteristics. The factors affecting
State Machine the positioning of the hub design on this
The State Machine is a technical capability spectrum are now discussed.
which enables the status of a payment to
be specified as it progresses through its
value chain3 until certainty of fate is accom- DESIGN ISSUES
plished. A State Machine is a well under- This section discusses some key issues for
stood capability, but in this case it must consideration in the design of a payments
specifically reflect the specialised events hub. The issues identified are discussed in
and states that occur in payments process- terms of how they influence the position-
ing within the organisation. ing of the hub on the defined spectrum.

Transformation Service granularity
Transformation refers to the capability to Service granularity relates to the coarse-
transform payment instructions from one ness of the services orchestrated by the
data representation to another. This capa- payments hub in processing a payment.
bility is essential for transforming scheme- The following design characteristics are
specific formats into the organisations’ observed:
preferred canonical data form.
• Service granularity becomes finer
The Payments Hub Spectrum defined grained at the right-hand side of the
The Payments Hub Spectrum constitutes hub spectrum shown in Figure 4. This

Page 62


Farrow

side is termed the ‘high-frequency’ end model towards the left of the spectrum is
of the spectrum, as a relatively high adopted, a coarse-grained service model is
number of fine-grained service calls are inferred. Visibility to the hub of the inter-
expected. nal payments processing steps by the prod-
• Conversely, service granularity becomes uct system is not likely, and knowledge of
coarser at the left-hand end of the spec- certainty of fate therefore lies with the
trum. This side is termed the ‘low-fre- product system.
quency’ end of the spectrum on the In a model towards the right-hand end
basis of a lower number of coarse- of the spectrum, finer-grained services are
grained service calls. prevalent, and full visibility of the process-
ing steps is more likely. Knowledge of cer-
Consider a simple illustration. If the target tainty of fate within the payments hub is
product system is rich in capability, there therefore more achievable in this hub
are few services for the hub to coordinate. model.
The interactions of the hub are few and
are typified by a single coarse-grained Technology selection
service call to the product system — effec- Figure 5 shows the mapping of portions of
tively a handoff of the payment for pro- the hub spectrum to the suggested optimal
cessing by the product system. The hub technology selections. For each spectrum
positioning is therefore at the left-hand portion, the characteristic features of the
side of the spectrum. technology are highlighted and the advan-
If the hub contains the capability to tages and disadvantages of its selection.
fulfil or orchestrate certain steps in the Some example technologies are given
value chain, the product system is effec- within each defined portion, but this is
tively tasked to perform much finer- illustrative and not exhaustive.
grained services. For example, an inbound
debit requires that a Funds Control check Low-end segment
is performed. If the result of the check The low end of the spectrum is considered
indicates funds are available, the debit may well suited to pure middleware technology
then be posted to the account. This sup- implementations. Functional processing
ports the premise of finer-grained services by the hub is simple or lightweight, as
towards the right of the spectrum. business services are provided by the prod-
uct systems (or other components). In
Certainty of fate these circumstances, there is little or no
Certainty of fate refers to knowledge of business functionality to build, or it is con-
the outcome of a payment, ultimately sidered practical to build the functionality
identifying the account to which the pay- of the simpler business services in the base
ment was posted (or other outcome). The middleware technology, perhaps supple-
extent to which certainty of fate is known mented by a procedural programming lan-
by the hub is determined by the service guage.
granularity.
Consider the principle that the pay- Mid segment
ments hub is the single system with full In the middle segment, functionality is
visibility of the payment processing states. richer. A pure middleware solution in this
This is perhaps a desirable goal, but may portion of the spectrum may require sig-
not be achievable, and a factor affecting nificant enhancements to base functional
this is the service granularity. If a hub capability. Given the richer functionality

Page 63



Figure 5
Technology
mapping of the hub
through the
spectrum
Middleware Framework Engine

Features Pure middleware product Pre-build sub-flows, Pre-built scheme level
supporting messaging/ Payments Repository, processing
transformation Scheme transformations, Black box component,
Stateless Stateless/full Stateless/full
Grey box component

Advantages Low technology cost Standard based, Low implementation cost if
Relative low cost Modular implementation
‘out of the box’

Disadvantages Building enhanced functions Customisation can still be Customisation cycle slow
is costly extensive Black box component
High product cost

Examples IBM MQ/Message Broker, IBM Enterprise Payments
Oracle (BEA Weblogic) Platform, Clear2Pay, Dovetail Fundtech GPP

specified in this portion of the spectrum, it • a richer set of pre-configured transfor-
is considered less cost effective to provide mations;
this via custom build. It is more effective • ‘out of the box’ advanced components,
to start from a position of some base func- such as a Liquidity Monitor;
tionality. A payments framework technol- • pre-build processing flows for specific
ogy solution therefore becomes more cost payment instruments.
efficient in this portion of the spectrum.
For example, the framework technology For these reasons, a full package solution
may already be provided with an ‘out of may become more cost effective at this
the box’ State Machine capability and with end of the spectrum.
pre-built transformations for some
scheme-specific formats. Canonical data zone
Industry-standard formats are important,
High-end segment as they are required by a scheme to sup-
In the high end of the spectrum, func- port routing of payments between banks.
tional capability is richer still and broader A selection of relevant industry standards
in scope, containing all process, business used within payments processing is shown
and integration capabilities. The scale of in Table 3.
the customisation, even for a framework A significant issue in the design of pay-
solution, may make this particular technol- ments processing systems is considered to
ogy selection less cost effective than for be the selection of the data standards for
the mid portion of the spectrum. A full the representation of the payments instru-
payments engine package solution may ments, as they progress through processing
offer: stages in the various system components.

Page 64


Farrow

Table 3: Sample data standards in payments processing

Data standard Description Type Classification

SWIFT Standard for SWIFT Fin payments processing Closed De facto
UNIFI (ISO20022) Standard for non-realtime payments Open De Jure
ISO8583 Standard for near-realtime payment instructions Open De Jure
APACS Standard 18 Standard for BACS processing Closed De facto

An obvious design approach would be • Additional meta-data are generally
to select one or more of the industry stan- required to enhance the original mes-
dards as the internal canonical data stan- sage received from a gateway.
dard. Bank-specific business processes and
the practicalities of the actual systems real- In summary, there are technical and busi-
isation, however, typically dictate that ness reasons why a de jure payments stan-
additional meta-data are required. For dard is not appropriate as the choice of
example: canonical data for use within a bank’s pay-
ments systems. In practice, an extended
• Head Office Collection Accounts version of a de jure standard is considered
(HOCA) processing — mapping of appropriate, this being unique to each
collection accounts to actual current bank.
accounts. It is necessary to retain the
original HOCA sort code such that Service placement issues
exceptions relating to subsequent pro-
cessing can be handled manually. Account servicing
Payment operations personnel may The centralisation of payments capabilities
need the original account data as a within the hub and the associated use of a
context to process the exception man- canonical data model create opportunities
ually. to improve broader customer account
• Addition of technical meta-data is servicing and internal operational activi-
often required: for example, pertaining ties.
to the destination system, sequence One potential area of benefit is
numbering or prioritisation of the pay- Enquiries and Investigations. This opera-
ments instruction to inform the mid- tional area within the bank is typically
dleware of how technically to route the characterised by multiple enquiry systems,
payment. specific to a given scheme. This makes
operational management overly complex,
The use of a canonical data form is critical inefficient and unreliable.
to achieving commonality of the process- Storing payments events in a hub
ing of payments and realise the advantages ‘operational data store’ enables a single,
of architectural simplicity outlined earlier. centralised view of the state of all pay-
Other considerations of note are: ments within the operation. Employing a
canonical data model in the operational
• BACS Standard18 to move to SEPA data store means these services can be
compliance and, by implication, used trans-scheme. These factors in turn
ISO20022 data standards by 2014. allow unified, streamlined, services to be

Page 65



built to support customer enquiries and (i) The hub receives an instruction to
operational investigations, improving the create a payment from a channel
quality and timeliness of the investiga- system. For example, a customer via a
tions. self-service channel makes a request to
initiate a payment. The hub then starts
Account portability the processing to fulfil that request,
Account portability is the requirement for controlling the services necessary to
customers to be able to retain their authorise the payment (eg Funds
account numbers when switching banks. Control check), create the payment
Account portability requires that a stan- instrument and send to the appropri-
dard format is used for the account ate gateway.
number, this being eight digits in the UK. (ii) The hub enquires on the mandate
Currently, not all UK banks conform to database or receives notifications from
this standard. the mandate database that a payment is
In heritage systems, the account to be made. Again, the hub starts the
number itself is quite often used as the process controlling the services that
database key in the product systems. A ultimately result in a payment instruc-
better design approach in general is to not tion (eg for an outbound credit) being
use the business data as the database key. created and sent to the payments gate-
Thus, to aid portability, one must treat the way.
account number as a data attribute and use
a separate artificial key to identify the The key design consideration in both these
account uniquely. scenarios is that the hub is the component
For those UK banks that use a non- that first receives the trigger to initiate the
standard account number in the product creation of the payment instrument. The
systems, to conform to future account hub then orchestrates the activities neces-
portability requirements, a mapping from sary to fulfil the creation of the instrument,
standard account number to the heritage notifying the initiating channel if a failure
format must be provided. This mapping in a processing step occurs.
can be provided by the payments hub. The design alternative for scenario (i)
Similarly, even for standard account above is that the channel component
number formats, there may be benefit in interfaces directly with the product
identifying the customer key in advance of system, which performs the Funds Control
the payment hitting the products system check as an internal function and creates a
or other components. Again, the hub is formatted payment instrument.
capable of providing this capability. The design alternatives for (ii) are that:
Alternatively, this capability may be pro-
vided by an external component with the • A separate Mandate Management com-
hub the central point of control of the ponent interprets the daily payment
lookup (as per the facade pattern previ- schedule and creates all the payments
ously discussed). instructions; this scenario is typical to
many heritage systems.
Payments origination • Mandate Management is a sub-compo-
Payments origination refers to the capabil- nent of the product system and the
ity to initiate payment instructions from daily payments schedule is created by
the payment hub. Two scenarios are antic- the product system; this scenario appli-
ipated: cable to modern package solutions.

Page 66


Farrow

Figure 6
Product
Bank
vendor Architectural
tension between
payment hub
stakeholders

Systems
integrator

These design alternatives infer a hub differing perspectives of the delivery part-
design that is towards the low-frequency ners. Three delivery partners are assumed
end of the spectrum; while the former — the bank, the product vendor and a sys-
infers a hub that fits the mid-/high- tems integrator responsible for the deliv-
options-frequency end of the spectrum. ery of the overall solution. The bank’s
perspective is a desire to reduce cost and
AML/Fraud Check achieve the business objectives: for exam-
Given its visibility of inbound and out- ple, reduced time to market. The product
bound payments, the hub is potentially a vendor perspective is a desire to achieve
point of control of a number of regulatory sales of modules, services development and
and compliance driven services. Fraud, local region enhancements to the base
anti-money laundering and Financial product. The system integrator perspective
Action Task Force (FATF) checks on the is a desire to achieve deliverability of the
payments are such services, and these can solution at low risk.
all be initiated from the hub. These perspectives each drive the place-
Furthermore, given its State Machine ment of the hub on the spectrum in dif-
capability, the hub already has the ability to ferent directions, creating an architectural
provide the state management of a pay- tension in the solution. Agreeing the pre-
ment arising as a consequence of the cise capabilities and placement of the hub
fraud, AML or FATF checks. A payment is a non-trivial task.
can be held in the hub Payments A decision to move to a different oper-
Repository pending resolution of investi- ating point on the spectrum can result in
gation of a condition flagged by the fraud, product/supplier reselection. Further -
AML or FATF services. Once investiga- more, the governance of the solution may
tion is complete, a release of the payment have to be revisited if major architectural
can be triggered by the Fraud/AML decisions are changed. Finally, compliance
Service. and risk checks may also need to be reval-
idated.
Traversing the spectrum All these factors make a decision on
Figure 6 illustrates the tension arising positioning within the spectrum a difficult
within a payments hub delivery due to and time-consuming exercise.

Page 67



Figure 7 UK CASE STUDIES application, further limiting ability to
clearing bank deliver timely changes.
payments hub UK clearing bank
architecture The timing of the programme was soon
overview Context after the financial liquidity crisis (the
This case study relates to a UK clearing ‘credit crunch’). Consequently, there was a
bank undertaking a core product system heightened sense of concern relating to
replacement programme. The bulk of the the risk exposure of the bank. This was
bank’s products were supported through a further amplified because a large portion
heritage system with the typical associated of its payments business was with agency
constraints, simplistically: banks. In this respect, the bank was
making payments on behalf of many other
• unresponsiveness to market changes in banks, but only settling with them some
the marketing environment due to con- time after the daily settlement cycle with
strained life cycle and deployment win- the Bank of England.
dows; Within the lifetime of the core product
• ‘knowledge monopoly’ by an out- replacement programme, the bank also
sourced supplier managing the heritage underwent a merger with another finan-

Page 68


Farrow

Figure 8 UK
clearing bank hub
spectrum
placement

cial institution. This further emphasised country-specific and bank-specific levels.
the need to facilitate payments to multiple The core capability and the country-spe-
product systems in the short to medium cific capability were inclusive in the
term, irrespective of the target product licensed cost. This implied a commercial
system landscape. driver to use the ‘out of the box’ package
features available so as to minimise devel-
Design drivers opment costs associated with customisa-
A payments hub was conceived as a solution. For the core product servicing
tion to the payments processing require- capabilities provided by the package, there
ments. An overview of the system was no contention with the capability
architecture, highlighting the scale of the model defined. Some of the capabilities in
integration required and the key role of the model, however, were available in the
the hub, is shown in Figure 7. package, and the placement of that capa-
Key design drivers were to support the bility in the payments hub or in the prod-
phased rollout of the new package-based uct engine was a major source of
product engine as described above, specif- architectural tension in the solution.
ically:
Hub solution
• to support the limited payment schemes The resulting overall payments hub design
needed by the savings products initially, was weighted towards the right of the
namely credit transfers, and then transi- spectrum with the selected capabilities
tioning to a richer set of schemes to shown in Figure 8.
support current accounts, including From a functional perspective, the com-
cheque clearing and debit card schemes; mercial considerations dictated that the
• to support the actual migration, switch- payments hub should not duplicate the
ing user payments from the heritage capabilities already provided by the pack-
product system to the new one trig- age. This consideration tended to limit the
gered by a scheduled migration date; functional richness of the payments hub,
• that the ‘package principle’ was applied positioning the overall hub design to the
to ensure that the features of the new lower end of the spectrum. From a ‘design
core banking platform were leveraged. purity’ perspective, however, certain capa-
bilities were considered to be better placed
The package provided capability at in the payments hub, tending to increase
generic automated clearing house (ACH), the functional richness and positioning the

Page 69



Figure 9 Foreign
currency order hub
architecture
overview

overall hub design towards the high end of activity, an Integration Programme was
the spectrum. conceived. The Foreign Currency
The ‘package principle’ also inferred Programme was part of this overall
that the payments hub should support the Integration Programme.
interfaces offered by the package, present- Post integration, the merged banking
ing the payments in a format expected by group required a single service offering in
the package, the objective again being to the area of foreign currency ordering and
minimise costs associated with any inter- fulfilment, specifically:
face customisation. In this respect, the
number of data transformations that arise • the sale of foreign currency and trav-
as a consequence of the interface selection ellers’ cheques;
should be noted (Scheme to Canonical to • the purchase of foreign currency.
Package).
Given the concern over settlement risk, Foreign currency services were to be
a component to monitor exposure to each offered through the multiple channels,
of the payments schemes was a key func- harmonised as part of the Integration
tional requirement. The Liquidity Programme. Fulfilment of foreign cur-
Monitor capability was therefore included rency orders was provided by a third-
as an advanced feature of the hub. party business partner of the acquired
bank.
Foreign currency order hub An order hub, depicted in Figure 9, was
introduced to provide the integrated solu-
Context tion.
The acquisition of a major bank created
the need to integrate two businesses and Design drivers
their respective IT systems. To fulfil this Key design drivers were:

Page 70


Farrow

FX order Figure 10 Foreign
hub currency order hub
spectrum
placement

• Routing • File validation • payments • Scheme limits
• Transformation • Repair repository management
• Enrichment • State machine

• Impacts on channels systems were time CONCLUSION
consuming, and it was desirable to keep There are a number of business scenarios
these to a minimum. The interface for- in which a payments hub is shown to have
mats to and from the channels were relevance. Specifically, a payments hub has
therefore to be preserved. been shown to be useful in supporting:
• Foreign currency fulfilment was to be
outsourced to a third party. This • core banking modernisation initiatives,
inferred a ‘pseudo scheme’ with specific the key driver here being to support the
operating characteristics and a defined migration of existing customer accounts
interface for the orders. to a new core banking engine;
• The order capture and fulfilment sys- • business acquisitions or mergers, the key
tems were all file based. driver here being to support the multi-
ple products systems arising in the
The foreign currency orders are analogous merged it operation.
to payments instruments. Consequently,
the design considerations are identical to Given an organisational IT strategy of a
those described for a payments hub. small, unchanging number of consolidated
product systems, it could be argued that a
Hub solution payments hub has a temporary role, used
The resulting hub design was weighted only while account migrations are in
towards the left of the spectrum with the flight. In practice, in any large banking
selected capabilities shown in Figure 10. organisation, the dynamics of the business
Transformation of order formats was environment mean that the IT landscape is
essential to covert multiple order formats continually changing through acquisitions,
into a single format required by the fulfil- mergers and de-mergers, necessitating a
ment partner. Routing was not strictly a long-term role for the payments hub.
required capability, although there was a There are other business drivers that
fan-out capability for the FX rate distribu- support the long-term need for a pay-
tion following a simple publish/subscriber ments hub, these being regulatory, compli-
model. File Validation of the order files ance and the competitive nature of the
was undertaken, and there was a store and business environment. Given these busi-
forward capability and a very simple State ness drivers, a number of functional issues
Machine implementation. More advanced in the design of payment hubs have been
features included limits management on identified.
the order values to ensure that delivery In this respect, a capability model for
value restrictions were adhered to. payments processing has been developed

Page 71



and described. The apportionment of hub that an organisation requires.
these capabilities between gateways, pay- Major changes to the underlying archi-
ments hubs and product systems can take tecture for payments processing are diffi-
many different forms, dependent on the cult, infer prescribed, minimum timescales
underlying business drivers and the and present high business risk for the
specifics of the IT landscape within the bank. In this respect, the technology selec-
bank. In the case studies discussed, it tion for a payments hub is an early deci-
became apparent that this apportionment sion which underpins the IT architecture
was a fundamental design consideration. and is important to get right at the outset.
This led to the concept of the ‘Payments In conclusion, understanding the required
Hub Spectrum’ as a vehicle for the analy- operating position on the Payments Hub
sis of a solution. Spectrum allows an organisation to make
At the low-frequency end of the an explicit, informed choice about the
Payments Hub Spectrum, the hub has the foundation technology for the hub, avoid-
characteristics of a pure middleware solu- ing costly re-architecting and minimising
tion. As the spectrum is traversed, more delivery risk for a bank.
functionality is added to the payments hub
until, at the high end of the spectrum, the ACKNOWLEDGEMENTS
hub constitutes a fully functional payments
Thanks are due to John Cameron, Paul Gray
engine. and Keith Johnson in shaping early ideas and
To conform fully to the concept of a concepts for the payments hub. Thanks also to
spectrum, one may expect a quantifiable, Greg Brougham for reviewing the paper and
linear attribute of the payments hub to be providing much thoughtful feedback.
increasing/decreasing as the spectrum is
traversed. The attribute presented here is
REFERENCES
the functional richness of the hub.
In practice, the functionality of the hub (1) European Payments Council (2010)
‘White Paper: Mobile Payments’, 1st
is not a strictly linear attribute or even
edn, European Payments Council,
necessarily cumulative. Capabilities Brussels.
towards the high end of the spectrum may (2) Farrow, G. S. D. (2009) ‘SOA
be included, but this does not necessarily anti-patterns: When the SOA paradigm
infer the inclusion of some mid-spectrum breaks’, IBM developerWorks, June.
capabilities. Despite this, the model is con- (3) Porter, M. E. (2004) ‘Competitive
sidered valid in broad terms and a useful Advantage’, ISBN 0-7432-6087-2, Free
vehicle for considering the general style of Press, New York, pp. 33–60.

Page 72

The Payments Hub Spectrum

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (20)

Semelhante a The Payments Hub Spectrum

Semelhante a The Payments Hub Spectrum (20)

Último

Último (20)

The Payments Hub Spectrum