Patterns for Payment Systems Integration

Farrow:JSC page.qxd 30/04/2012 13:49 Page 15

Journal of Payments Strategy & Systems Volume 6 Number 1

Patterns for payment systems integration

Gary S. D. Farrow
Received (in revised form): 31st January, 2012
Triari Consulting, 30 Clothorn Road, Didsbury, Manchester, M20 6BP, UK.
Tel: +44 (0)161 445 5958; Fax: +44 (0)161 445 5958; e-mail: gary.farrow@triari.co.uk

Gary Farrow is Director of Triari Consulting, environment. Selecting the appropriate architec-
provider of systems integration and IT architectural style for payments processing is therefore
ture services for the financial sector. A lead an extremely important activity. This paper
architect on many successful, high-value proj- presents architectural patterns for payment sys-
ects, he has undertaken senior architect roles at tems integration. These enable the selection of
major banks and financial services firms in the optimal architectural solutions for payments
UK. Gary has broad expertise in large-scale sys- processing. Each pattern is described in terms of
tems integration, enterprise service bus archi- a number of generic Architectural Building
tectures and Service Oriented Architecture Blocks1 and their interactions.The general char-
(SOA), and deep domain specialism in payments acteristics of each pattern are compared, and the
systems. He has written many articles on SOA suitability of each pattern in supporting specific
and payments processing, discussing wide- business scenarios is presented. The paper also
ranging topics such as anti-patterns, the role of introduces the concept of the Payments
data and the optimisation of delivery models. Integration Space, which defines the scale of
Gary is a member of the IT Architecture the systems integration problem. This metric is
Certification Board for the Open Group. His pro- used to illustrate the role of the patterns in
fessional qualifications include Fellow IET, reducing complexity. It is shown that two spe-
Chartered Engineer and Open Group Master cific patterns, Payments Hub and Payments
Certified Architect. He holds BSc and PhD Service Bus, are candidates for the target end
degrees from Manchester University and is an state. Given significant differences in character-
alumnus of Warwick Business School, UK. istics of the two patterns, it is concluded that a
bank must make an early and overt choice
ABSTRACT about selecting the most appropriate target end
Regulatory, industry and competitive drivers state for payment systems integration.
dictate that payment initiatives within a bank
are many and continuous. However, a common Keywords: architectural patterns, trans-
situation is that the supporting IT systems action processing, Payments Hub,
have evolved in an ad hoc manner — there Payments service bus, systems integra-
are often limited separation of architectural con- tion, TOGAF
cerns, many tightly-coupled legacy systems and
duplication of processing capability. Systems
integration complexity is a limiting factor in INTRODUCTION
determining how quickly IT changes can be Deficiencies in payments systems process- Journal of Payments Strategy &
Systems
achieved. These factors detract from a bank’s ing manifest themselves in business terms Vol. 6, No. 1, 2012, pp. 15–36
᭧ Henry Stewart Publications,
ability to respond to changes in the business as: 1750–1806

Page 15


Patterns for payments systems integration

• high business operational overheads Consequently there is limited separation
associated with correcting system pro- of architectural concerns. Duplication of
cessing errors; payments-related services, such as fraud
• additional time to effect payments, lead- detection and anti-money laundering, is
ing to low customer and business part- common, and there is invariably no uni-
ner satisfaction. fied approach to systems integration. All
these factors detract from a bank’s ability
An effective payment processing capability, to respond to changes in the competitive
achieving timely completion of payments environment. Selecting the appropriate
and having ‘straight through’ systems pro- architectural approach to payment pro-
cessing capability with low operational cessing is therefore an important activity.
intervention is therefore considered vital. Architectural patterns provide a specific
Also, regulatory, industry, competitive and solution to a known IT problem. Thus,
cost-reduction drivers dictate that pay- patterns provide an abstract solution tem-
ments initiatives within a bank are many plate applicable to specific scenarios. In
and continuous. Systems must be continu- this respect, the architectural patterns help:
ally enhanced to support these initiatives
and there is extensive integration effort to • in understanding what existing
accommodate acquisitions and divest- approaches are deployed, where they
ments. Systems integration complexity is deviate from an ideal solution, and
thus a limiting factor in achieving such hence their limitations;
business changes quickly. • illustrate solution options when pay-
Elegant payments systems processing, ments processing is impact due to a
having reduced integration complexity change in the business environment
and shared system components, can help allowing the bank to make an informed
in enabling the business agility of a bank: choice of architectural solution;
• to provide an ideal target end state to
• providing faster speed to market of support long-term payments processing
products and services; planning and incremental improvement
• in meeting legal and regulatory compli- to the payments processing landscape.
ance; This paper discusses a number of architec-
• in responding to industry initiatives tural patterns for payments systems inte-
quickly. gration.
First, an architectural model for pay-
It can also offer many benefits to a bank’s ments processing is presented that forms a
customers, notably the ready availability of framework for the underlying analysis. The
the latest payment processing features, patterns are identified and described in
improved reliability and consistency of terms of the building blocks of this model,
service, and improved transparency of the supplemented with an additional compo-
payment life cycle. nent representing a systems integration
However, many barriers to effective construct.
payment processing exist. A typical sce- Each pattern is presented in terms of
nario is that the underlying payments sys- the relationships between all the collabo-
tems have developed in an ad hoc manner. rating components. A summary of the
Many legacy systems continue to exist, characteristics of the specific integration
bundling scheme-specific transactional component in the given pattern context is
processing with account services. also provided.

Page 16


Farrow

Finally, the adoption of each of the pat- bank staff to perform payments on behalf
terns as the candidate target end state for of a customer or for the bank itself. A
payments processing is explored. To this channel system will typically only initiate
extent, the degree to which each facilitates outbound payments. Communication from
the desired system processing objectives is the Channel components is usually by
assessed, focusing on the extent to which using an internal data format unique to the
the integration complexity is reduced. bank, although a derivation of an industry
format is also often the basis of this.

PAYMENTS PROCESSING Product System
ARCHITECTURAL MODEL This component represents a core banking
An architectural meta-model is now pre- system, domiciling the customer accounts
sented that defines a number of abstract that are the remitter and beneficiary of
solution components required for pay- payments.
ments processing. These coarse-grained The remitter and beneficiary accounts
solution components are termed would typically each be domiciled in dif-
Architectural Building Blocks (ABBs).3 ferent bank product systems, representing
The patterns identified are defined in the sending bank and receiving bank. In
terms of the relationship between these the case of an ‘on us’ payment, both remit-
ABBs. In each pattern scenario, the ter and beneficiary accounts are domiciled
responsibilities of the ABBs remain within the same bank’s product systems.
broadly similar, but the model allows for Other circumstances may arise when a
differences in functional capability particular bank is acting as an intermedi-
depending on how specific payments ary for payments processing for another
Business Services are apportioned. The bank (such as Agency banking or
functional capabilities appropriate to pay- Correspondent banking arrangements). In
ments processing have been previously these circumstances, both remitter and
defined by the author4 and these also form beneficiary accounts are external to the
part of the architectural model. given bank.
The set of payments ABBs is now
described. Payment Engine
This component performs the activities
Payment Gateway required to process a payment, these being
This component represents the system that the discrete set of functions in its value
interfaces to a payments scheme. All com- chain within the organisation. The
munication to and from the scheme is Payment Engine must be invoked:
done via this component. A Payment
Gateway will process both inbound and • upon receiving the payment instruction
outbound payments. Communication to from the scheme via the Payment
and from the Gateways are typically made Gateway;
using industry data standards. • upon initiation of a payment from a
Channel or Product System;
Channel
This component represents a channel The processing applied to each payment is
through which a customer interacts with specific to each scheme. In this respect, in
the bank. It may also correspond to the this model, a particular Payment Engine
front/back office system used by internal processes payments for a given scheme only.

Page 17



Figure 1
Payments
processing
capabilities (after
Farrow)5

A Payment Engine is also referred to in money laundering checks.
payments processing as a Transaction • A separate integration component may
Processing System. call required technical integration serv-
ices such as routing and transformation.
Payment Business Services
Payment Business Services represent sepa- Payment Processing Spectrum
rate components each providing a pay- These capabilities above have been struc-
ments functional capability. A number of tured previously into an ordered list,
such capabilities exist and a model for pay- termed the Payments Hub Spectrum.6
ments processing has been defined previ- Simplistically, middleware capabilities are
ously and is shown in Figure 1. positioned to the left of the Spectrum
Payment Business Services must be with Payments Business Services of
orchestrated to fulfil the required process- increasing functional richness positioned
ing on each inbound or outbound pay- to the right of the Spectrum. Since a ‘Hub’
ment. There is not necessarily a single is subsequently shown to constitute one
control point for this orchestration, which very specific payment processing pattern,
may be distributed across a number of this paper references this Spectrum more
components. For example: generally as the Payments Processing
Spectrum, shown in Figure 2.
• Channel components may call valida- In the integration patterns defined,
tion services to ensure a well formed these capabilities are shown to be appor-
payments message is constructed. tioned across the set of ABBs identified.
• A Payment Engine will orchestrate a The manner in which these capabilities
number of such services to post account are apportioned differs for each pattern
entries and to call financial crime serv- and is highlighted in each pattern descrip-
ices, such as fraud, sanctions and anti- tion.

Page 18


Farrow

Figure 2
Payments
Processing
Spectrum

Payments Integration Space all components. The complexity of the
The generic Integration Space is defined as Integration Space is defined by the
the set of architectural components and number of interconnections between the
their connections required to support the payments system application compo-
processes of a given business domain. The nents.
Integration Space is defined without mid- Table 1 shows the cardinality of the each
dleware components. of the inter-connections between the ABB
Figure 3 shows the Integration Space components identified for the Payments
specifically for the payments business domain (m denotes many entities).
domain, expressed in terms of the The Complexity Table provides a con-
Payments Processing Architectural Model venient view of the complexity of the
described above, the ABBs equating to the integration problem. Many-many connec-
architectural components. The shaded area tions represent a hotspot of complex inte-
represents an indeterminate number of gration. It is seen that most
point-to-point interconnections between interconnections between the generic
the ABBs. External B2B connections are components are many-many. Channels
required to support interaction with typically connect to Gateways via a
banks, commercial partners, agency banks, Payment Engine and not directly, and so
payment schemes and messaging systems. there is no Channel to Payment Gateway
B2C connections are also required with connection. Similarly a Channel does not
the bank’s customers. connect to other Channels, nor does a
A variety of interconnections are Payment Engine typically connect to
required within the bank’s organisational other Payment Engines.
boundary. It is these internal organisational The Payment Gateway to Payment
connections within the Payments Engine connection is shown as 1-1,
Integration Space that are the subject of reflecting the stated model that a Payment
analysis and to which the patterns pre- Engine is dedicated to one specific scheme
sented are applicable. and will process payments only for that
Interconnections are shown between scheme via its Gateway. In some circum-

Page 19



Figure 3
Payments
Integration Space

stances, a common messaging infrastruc- complexity. An example is provided later
ture is used across several schemes and also in the analysis.
to communicate with business partners,
such as Agencies and Correspondents. The
prime example of this is the SWIFT mes- PATTERN DESCRIPTIONS
saging infrastructure. In this scenario, a Six architectural patterns for payments
single Gateway may connect to multiple integration are now presented:
Payment Engines and the relationship of
one Gateway to many Engines (1-m) is (i) Payment Engine Routing Utility;
also possible. (ii) Product System Routing Utility;
A further point to note is that the (iii) Front End Payments Hub;
Product System is the only component (iv) Back End Payments Hub;
that connects with itself. This reflects ‘on- (v) Payments Hub;
us’ payments made between customers of (vi) Payments Service Bus.
the same bank.
The Complexity Table must be popu- Each pattern incorporates the ABBs
lated for a given bank to create a specific, described in the architectural model, sup-
quantified, table instance. This then pro- plemented with an additional component
vides a unique view of the Payments representing a systems integration con-
Integration Space for that bank and struct.
enables a ‘heat map’ to be deduced, high- In each pattern, the relationships,
lighting the areas of greatest integration including cardinality, between all the

Page 20


Farrow

Table 1: Payments Integration Space Complexity Table

Channel Payment Gateway Product System Payment Engine

Channel – – m-m m-m
Payment Gateway – – m-m 1-1
Product System m-m m-m m-m m-m
Payment Engine m-m 1-1 m-m –

Table 2: Pattern attribute descriptions

Attribute Description

Integration Capability Defines whether the component has integration capability
Business Capability Defines whether the component incorporates functionality from one or
more of the business capabilities
Process Capability Defines the extent of the process orchestration capability
State Management Defines the extent of the state management of the component
Connection Style Defines the connection style in terms of how and when the component is
invoked

components are illustrated. A summary of Product Systems themselves are assumed
the characteristics of the integration to be tightly coupled and are shown
component in the given pattern context together, effectively acting as one entity.
is also provided. These characteristics are Thus the pattern does not address the
qualified as a set of attributes, shown in integration problem between the Payment
Table 2. Engine and Product System components.
For each pattern, scenarios where the In general there are three categories of
pattern is considered useful are described. functional capability that may be per-
Finally, using the Payments Processing formed by pattern component:
Spectrum, the apportionment of function-
ality to the components in each pattern is (i) Integration Services;
illustrated. This provides a convenient (ii) Business Services;
visual perspective to compare the patterns. (iii) Process Services.

Payment Engine Routing Utility The sole function of the Payment Engine
Routing Utility is to interface to the
Overview Gateway and route payment instructions
This pattern represents a solution for inte- to and from the Payment Engines. Thus, of
grating a single Payment Gateway into the three categories, the Payment Engine
multiple payment engines or Product Routing Utility provides only Integration
Systems. Services. The combination of the Payment
The Payment Gateway is connected to Engine and the Product Systems provide
a single Payment Engine Routing Utility the rest of the payments processing capa-
(Figure 4). This, in turn, is connected to bility.
two or more Payment Engines/Product The Payment Engine Routing Utility
Systems. The Payment Engines and does not manage any business state. It may,

Page 21



Figure 4 Payment tion from legacy engine to new engine
Engine Routing cannot be achieved in one ‘big bang’ and a
Utility pattern phased approach is adopted, requiring old
and new payment engine instances to be
concurrently live.
As a specific example of this pattern, a
global commercial bank intended to replace
its legacy Payment Engine for CHAPS pro-
cessing with a new product solution, this
being Fundtech Global PAYplus. A
Routing Utility was introduced to switch
payments to one or other of the Payment
Engines. This approach de-risked the solu-
tion implementation, allowing for a gradual
migration of customers to the new
Payment Engine.
Similarly it has use in supporting a bank-
ing integration. In this situation, a payments
scheme Gateway may be consolidated
down to one of the original banks’ Gateway
components. Underlying internal systems
processing in the short term may be
untouched, requiring routing from the
consolidated Gateway to each of the origi-
nal banks’ respective payment engines.
however, manage technical state relating to
Summary
interactions with the Gateway.

Spectrum Apportionment Payment Engine Routing Utility
The Payment Engine Routing Utility
construct provides pure middleware serv- Attribute Value
ices and is shown in Figure 5 occupying Integration Capability Yes
the left-hand side of the Spectrum. Business Capability No
Capabilities from the Spectrum utilised Process Capability No
in this pattern include: State Management No business state, but
potential technical
transaction state
• Routing, to achieve the Payment Engine Connection Style Single Pass
selection;
• Transformation, to transform from
scheme to respective formats required
Product System Routing Utility
by each of the Payment Engines;
• Validation of inbound messages received
Overview
from the scheme.
This pattern (Figure 6) represents a solu-
Scenarios tion to integrate a single Payment Engine
This pattern is useful when introducing a to multiple Product Systems.
new Payment Engine. Typically the migra- The Payment Gateway is connected to

Page 22


Farrow

Figure 5 Payment
Engine Routing
Utility Spectrum
Apportionment

a single Payment Engine, dedicated to a • Validation of outbound messages and
specific scheme. The pattern assumes that bulk payment files received from the
customer accounts are domiciled across Product Systems
multiple Product Systems. Commonality
of processing for all payments relating to Scenarios
one scheme is achieved, but there is an This pattern is useful in the scenario relat-
integration problem to route payments to ing to the introduction of a new payment
multiple Product Systems that the scheme. In such circumstances, a new
Routing Utility resolves. Payment Gateway is assumed. The sce-
As per the Payment Engine Routing nario then further assumes that a new
Utility, the Product System Routing Payment Engine is introduced, dedicated
Utility provides only Integration Services. to the new scheme. The Routing Utility
The combination of the Payment Engine
and the Product Systems provide the rest
Figure 6 Product
of the payments processing capability.
System Routing
The Product System Routing Utility
Utility Pattern
component also does not manage any
business state. It may, however, manage
technical state relating to interaction with
the Product Systems; for example, techni-
cal retries and the batching of requests for
offline Product Systems.

Spectrum Apportionment
As per the Payment Engine Routing util-
ity, capabilities employed in this pattern are
middleware services, and hence the pat-
tern apportions capabilities from the left-
hand side of the Spectrum (Figure 7).
Capabilities from the Spectrum utilised
in this pattern include:

• Routing, to achieve the Product System
selection.
• Transformation, to transform from
scheme to respective formats required
by each of the Product Systems

Page 23



Figure 7 Product
System Routing
Utility Spectrum
Apportionment

then provides the necessary integration Summary
services to interface the new Payment
Engine to the existing Product Systems. Product System Routing Utility
As a specific example of the pattern,
when the Faster payments Scheme (FPS) Attribute Value
was introduced in the UK, a large retail
Integration Capability Yes
bank deployed a dedicated solution stack Business Capability No
comprising ACI Gateway as the Gateway Process Capability No
component and ACI Money Transfer State Management No business state, but
System as the Payment Engine. A potential technical
Routing Utility was developed to route transaction state only
relating to Product System
payments to and from multiple Products interactions
Systems using IBM WebSphere Message Connection Style Single Pass
Broker.
The pattern is also considered relevant
when a new Product System is introduced
in the bank’s IT estate. This may arise: Front End Payments Hub

• As a consequence of core banking Overview
platform migration. In such a scenario, This pattern (Figure 8) constitutes a gen-
account migration is not achieved in eralisation of the Payment Engine
one ‘big bang’ and a phased approach is Routing Utility pattern. It is also similar to
required, where old and new Product the Front End Landing Zone, this being a
Systems are concurrent. Thus, co-exis- category of Payments Hub suggested by
tence of the multiple Product Systems Hayden et al.7 In this respect, the pattern
is required as an interim state and the represents an architectural formalisation of
Routing Utility is a transient con- this particular payments integration strat-
struct. egy using the constructs defined in the
• As a consequence of a banking integra- Payments Processing Architectural Model.
tion when new Product Systems are The Front End Landing Zone is shown
acquired. This pattern equates to a dif- processing only payment instructions input
ferent integration point for the inte- from the Channels, and the integration
grated bank systems, this being the from Channels to Hub is shown as being
Product Systems rather than the unidirectional. The Front End Payments
Payment Engine as per the Payment Hub connects to several Payment
Engine Routing Utility pattern. Gateways, each relating to a scheme in

Page 24


Farrow

which the bank participates. In this respect, Figure 8 Front
the Front End Payments Hub processes End Payments Hub
both inbound and outbound payments
instructions from the Payment Gateway
and hence the integration is bi-directional.
It also connects to one or more Channels,
these being end-user delivery channels.
They are typically a source of payment
instructions, and hence a source of out-
bound payments (or on-us) payments only,
rather than a target for inbound payments.
The Front End Payments Hub connects
to one or more Payment Engines but does
not connect to the Product Systems. Thus,
as with the Payment Engine Routing
Utility pattern, this pattern does not address
the integration problem between the
Payment Engines and the Product Systems.

Spectrum Apportionment
This pattern construct provides middle- the payment instructions with bank-
ware services as per the two Routing specific technical or business data;
Utility patterns. It also provides the oppor- • Payments Repository, providing a ware-
tunity to introduce several payment house of all payments instructions for
Business Services (Figure 9). Considering audit purposes. In this pattern, the Front
the Capability Model, in addition to the End Payment Hubs has visibility of all
Routing, Transformation and Validation, inbound payments from the schemes
candidate Business Services include: and all outbound payments originated
from the channels. It is therefore a sen-
• Diary management, providing functional- sible point of control for updating or
ity for altering on files that are expected implementing a centralised Payments
to be received or sent to a scheme on a Repository;
given day according to the scheme • Intelligent payments routing, enabling
operating times; scheme selection based on general cri-
• Almanac, this being the determination teria, for outbound payments originated
of the Diary events for a given day; from the Customer Channels.
• Anti-money laundering (AML) and fraud
services, for example, sanctions checking Process services may therefore also be
on all inbound payments and event required to orchestrate these Business
feeds to AML and fraud management Services.
system components;
• Account validation, to validate the benefi- Scenarios
ciary account for an inbound payment; This pattern addresses the payments chan-
• Repair, supporting the correction of nel integration problem across the entire
payment instructions incorrectly bank. Thus, It is most relevant when the
formed from the channels; channel integration problem is more com-
• Enrichment, supporting enrichment of plex than the back-end integration prob-

Page 25



Figure 9 Front
End Hub Spectrum
Apportionment

lem. Circumstances where this may arise Back End Payments Hub
are when a bank is a member of many This pattern (Figure 10) is a generalisation
schemes and has many delivery channels of the Product System Routing Utility
but only a limited number of Product pattern. It also broadly equates to Back End
Systems. In such circumstances, this pat- Aggregation, this also being a further cate-
tern is considered a viable solution. gory of Payments Hub suggested by
Secondly, this pattern has been sug- Hayden et al.9 Again, the pattern represents
gested8 as an interim state towards achiev- an architectural formalisation of this pay-
ing a more complete payments integration ments processing strategy using the
solution (ie one that addresses front- and defined Architectural Model constructs.
back-end integration). In this case, the In this pattern, the Back End Payments
Front End Payments Hub supports a strat- Hub connects to one or more Product
egy for the phased introduction of Systems. It may also connect to some
common payments-processing services, Business Services, each providing a service
leading to the desired end-state solution. common to all payments processing.
The form of such end-state solutions is It is seen that the Back End Hub pat-
defined and discussed in two further candi- tern addresses the integration problem of
date patterns: Payments Hub and Payments integrating the Payment Engines to the
Service Bus. Product Systems. The Back End
Payments Hub provides the services to
Summary of characteristics integrate the Product Systems and other
components providing Business Services.
In this way it exposes Business Services
Front End Payments Hub
that may be used by several Payment
Engines to fulfil the payment process.
Attribute Value
Thus, in this pattern, the Payment Engine
Integration Capability Yes is the main provider of the process serv-
Business Capability Provides some shared ices, fulfilling a payments process using
services or delegates these Business Services exposed via the Back
to other components
Process Capability Some orchestration
End Payments Hub.
capability required
State Management Stateful or stateless, Spectrum Apportionment
depending on the specifics As per the Front End Hub, it may provide
of the Business Services a number of Business Services (Figure 11)
employed
or delegate these to other components
Connection Style Single Pass
providing shared Business Services.

Page 26


Farrow

Candidate Business Services for this pat- Figure 10 Back
tern, include: End Payments Hub
Pattern
• Account Posting, to post to the back end
Product Systems;
• Mandate Management, providing cen-
tralised management of mandates for
outbound standing orders, decoupling
this functionality from the Product
Systems;
• Intelligent Payments Routing, enabling
scheme selection based on general cri-
teria, for outbound payments. Payment
origination for this pattern relates to
mandates only;
• Payments Repository. In this pattern, the
Hub construct has visibility of out-
bound payments originated by the
Product Systems, but not necessarily all
inbound payments from the scheme or
initiated from the Customer Channels. entire bank. Thus, this pattern is most rel-
It is therefore a point of control only for evant when the back-end integration
updating a centralised Payments problem is more complex than the chan-
Repository for the outbound payments nel integration problem. A circumstance
relating to mandates. where this may arise is when a bank is a
member of a limited number of schemes
As per the Front End Payments Hub, and/or has limited delivery channels, but
Process Services may therefore also be has several Product Systems. In such cir-
required to orchestrate these Business cumstances, this pattern is considered an
Services, although as is seen, the scope is appropriate solution.
more limited. Again, this pattern has been suggested as
only an interim state towards achieving a
Scenarios more holistic end-state payments integra-
This pattern addresses the back-end pay- tion solution. The Back End Payments
ments integration problem across the Hub, in this case, supports a strategy for

Figure 11 Back
End Hub Spectrum
Apportionment

Page 27



the phased introduction of common pay-
ments processing services, leading to the
desired end-state solution.

Summary of characteristics

Back End Payments Hub

Attribute Value

Business Capability May provide or delegate
some services
Process Capability Some limited capability may
be required
State Management No business state, but may Figure 12 Payments Hub Pattern
manage technical state
relating to transactions with
Product Systems
Connection Style Single Pass • The Payments Hub may either:
— provide Payments Business Services
itself (internal capabilities); or
— connect to zero or more externally
Payments Hub provided Payments Business Services.

Overview All orchestration of Business Services is
The term ‘Payments Hub’ is a widely used undertaken by the Payments Hub. In this
expression for a generalised solution to pattern, the Payments Hub contains the
payments processing. This pattern (Figure aggregate set of Process Services capabili-
12) provides a more precise definition of a ties required to support all scheme pro-
Payments Hub in terms of the cessing. The Payments Hub therefore
Architectural Model constructs. subsumes the functionality of the Payment
In this pattern, the Hub is the central Engine (transactional processing) compo-
integration point of all the components nents, and this is not required in this pat-
involved in payments processing. None of tern. Some commonality of processing
the components interact without commu- steps may be achieved across schemes but,
nication through the Payments Hub. All more significantly, reusable shared services
the necessary integration capability resides are employed to undertake the specific
in the Payments Hub. Connections tasks in the processing chain.
between the components require only a The placement of the orchestration
single pass through the Payments Hub. capability within the Hub infers business
In this respect: state management, as the Hub must
accommodate and manage a variety of
• One or more Customer Channels are business exception conditions that typi-
connected to the Payments Hub. cally occur in processing a payment.
• One or more Product Systems are con-
nected to the Payments Hub. Spectrum Apportionment
• One or more Payment Gateways are In terms of the categories of service pro-
connected to the Payments Hub. vided by the Hub, it provides all of:

Page 28


Farrow

Figure 13
Payments Hub
Pattern Spectrum
Apportionment

• Integration Services; format appropriate to the bank.
• Business Services; Achieving this allows for harmonisation
• Process Services. of payments processes, simplification
and reuse;10
Thus, in this pattern, the Payments Hub • State Machine, this being necessary to
construct may employ capabilities from support the stateful processing per-
the entire Spectrum. Some of the capabil- formed by the Payments Hub.
ities may be provided by the Payments
Hub itself, or some or all of the capabilities Scenarios
may be delegated, but always called from This pattern provides a generalised solu-
the Hub. Unlike the Front or Back End tion to payments integration within a
Payments Hub, this construct has visibility bank. It is applicable when there is a com-
of all payments from all schemes and chan- plex integration problem with respect to
nels. This enables the opportunity for the channels and the back end Product
additional Business Services to be pro- Systems — simplistically many Gateways
vided or orchestrated from this compo- and Customer Channels — and many
nent (Figure 13), specifically: Product Systems.
The pattern provides a single solution
• Liquidity Management, monitoring the to scheme-specific transactional process-
overall liquidity position of the bank ing. Thus, it is useful in achieving architec-
with respect to the schemes; tural simplification as it consolidates all
• Scheme Limits Management, providing the Payment Engines into one component.
opportunity for alerting and pro-active As an example of the use of this pattern,
management should the scheme limits a UK retail bank embarked on a pro-
be approached or if individual payments gramme of core banking modernisation,
exceed the limits; introducing Infosys Finacle as the new
• Payments Repository, now encompassing Product System. The bank was a full
all payments; member of all UK payment schemes.
• Transformation, providing a more general Channel integration complexity was high,
transformation service of payment mes- but there were a limited number of
sages into a specific canonical data Product Systems. However, to support a

Page 29



strategy of gradual migration of payment
services to the new banking platform, a
Payments Hub solution was conceived and
implemented using technologies from
Clear2Pay.

Summary of characteristics

Payments Hub

Attribute Value

Business Capability Yes
Process Capability Yes
State Management Stateful with respect to
business state and also
technical state
Connection Style Single Pass

Figure 14 Payments Service Bus Pattern
Payments Service Bus

Description
The Payments Service Bus (PSB) is also a Business Service orchestration is pro-
widely used term for a generalised solu- vided solely by the Payment Engines, each
tion to payment processing within the of which may be tailored to provide the
bank (Figure 14). The differences between specific processing demanded by a scheme,
this and the Payments Hub are how clearly optionally complemented by the banks
articulated in terms of the Architectural own value-add services.
Model. Processing of an inbound payment
Unlike the Payments Hub, this pattern instruction, from receipt at a Gateway to
is premised on the existence of a number posting to an account in a Product
of separable Payment Engines, typically System, requires several passes through the
one per scheme. All integration to and PSB:
from the Payment Engines is provided by
the Payments Service Bus. In this way, a • collection from the Gateway with rout-
common utility is provided for all pay- ing and onward transmission to the cor-
ments integration within the bank. The rect Payment Engine;
Payments Service Bus can be considered as • calls to a number of the Business
a specialism of an Enterprise Service Bus, Services, orchestrated by the Payment
but specific to payments integration. Engine, but mediated by the PSB;
The PSB connects to all Consumer • selection of the recipient ledger system
Channels and Gateways. It also connects and associated account posting to the
to multiple Product Systems and to shared correct Product System.
Business Services. No payment instruction
passes between the payments system com- The PSB itself need only provide stateless
ponents without mediation by the PSB. ‘one shot’ services. It is the Payment

Page 30


Farrow

Figure 15
Payments Service
Bus Spectrum
Apportionment

Engines that manage any payment business Given the knowledge capital invested in
state if it is necessary to do so. the existing Payment Engines, likely com-
plexity of legacy implementations (imply-
Spectrum Apportionment ing huge effort to replicate and replace)
In this pattern, the Bus construct provides this pattern supports a strategy of their
only the integration services and hence continued use. Thus, the PSB solution
occupies the left-hand portion of the allows for their retention and focuses on
Spectrum. Multiple Payment Engines pro- addressing the integration problem
vide scheme-specific process services and between the Payment Engines and the
implement (or orchestrate) some or all the other payment solution components. In
Business Services, and hence are shown comparison with the Payments Hub pat-
occupying the middle and high end of the tern it therefore avoids significant effort in
Spectrum. As per the Payments Hub pat- Payment Engine replacement.
tern, the construct has visibility of all pay- This solution pattern was selected by a
ments and so Business Services across the large UK retail bank as a solution to the
entire Spectrum are applicable in this pat- payment integration problem. The bank
tern (Figure 15). was a full member of all UK and European
schemes with dedicated Payment Engines
Scenarios and having several major Product Systems.
As with the Payments Hub pattern, the The bank took a view, as highlighted
PSB also provides a generalised solution above, that consolidation of its diverse
to payments integration across the bank, range of Payment Engines into a single
solving the problems of front- and back- solution across the bank was a massive
end integration. This pattern does not undertaking, not feasible in a short to
require the replacement of legacy medium time frame. Rather a strategy of
Payment Engines; rather it recognises and leveraging existing Payment Engines, and
complements the scenario of multiple a policy of gradual, targeted, replacement
Payment Engines. was employed. The Payments Service Bus
The pattern is therefore useful in banks pattern was identified to support this strat-
where there exist multiple, diverse, egy. Technology selection and implemen-
deployed instances of Payment Engines. tation is ongoing within the bank.

Page 31



Summary of characteristics patterns that address the holistic payments
integration problem, covering both front-
Payments Service Bus and back-end integration. These are the
Payments Hub and the Payments Service Bus.
Attribute Value Therefore, both these represent viable can-
didate end states.
To help assess the suitability of these two
Business Capability Delegated
Process Capability No patterns as the preferred target end state
State Management Stateless and achieve a comparison, their effective-
Connection Style Many passes ness in reducing integration complexity is
assessed using the Integration Space
Complexity Table defined in Table 1.
TARGET END STATE SELECTION
End state suitability assessment
Considerations For the purposes of comparison, a specific
The target end state represents the ideal Integration Space Complexity Table is
long-term vision for payments systems illustrated using the following parameters,
processing. typifying a medium retail bank with full
Recall the dual objectives of effective UK scheme membership and a multi-
and elegant system processing. These channel delivery strategy. In this context, it
objectives will be met to a large extent by is assumed the bank offers the following
reducing the integration complexity. All channels:
the patterns described do provide a reduc-
tion in this complexity and therefore sup- (i) branch;
port these objectives to some degree. This (ii) internet banking;
now poses an interesting question: of the (iii) telephone banking;
patterns identified, is there a single pattern (iv) postal services with associated back
that represents the preferred end state for office systems;
payments processing, or are alternative (v) a business partner channel via a dedi-
target end states viable? cated system.
It is evident that to achieve integration
simplification, and target end state must Six schemes are assumed, equating to coun-
address the holistic integration problem try-specific schemes. For the UK, these are
covering both front-end and back-end BACS, Clearings, CHAPS, Faster Payments,
integration. cards, and also International payments. The
Hayden et al.11 present the example assumes that a shared Payment
Consolidated Transaction Hub as the Gateway is used to support two schemes
single preferred end state that achieves (eg CHAPS and International payments,
this. In terms of the patterns described both processing SWIFT messages). The
here, this aligns most closely with the numbers are therefore arbitrary but relate to
Payments Hub pattern. In their context, realistic circumstances.
both the Front End Payments Hub and
Back End Payments Hub patterns are Schemes 6
useful only as introduction strategies for Consumer Channels: 5
achieving this end state. Payment Gateways: 5
However, the pattern analysis presented Product Systems: 3
here reveals that there are in fact two key Payment Engines: 6

Page 32


Farrow

For simplicity, it is assumed that all Business Services does not detract from
Channels: the analysis given.
The original Payments Integration
• support payments types for all schemes; Space relating to this example is shown
and graphically in Figure 16a.
• a connection to all Product Systems is For the Payments Integration Space, an
required for account updates. overall complexity coefficient is intro-
duced, defined as the total sum of the inte-
In practice all payment types may not be grations. In the example defined:
offered from all Channels and some
account updates would be controlled by Example Integration Space Coefficient: 175
the Payment Engine. Such factors would
lower the integration complexity in real- The effect on the reduction in the
ity. This derives a specific table below Integration Space complexity is now illus-
(Table 3). trated for the two candidate end-states pat-
Note that the Integration Space does terns. By applying them to the example
not account for any integration to compo- problem space, the connectivity is re-evalu-
nents providing Business Services. These ated to give the revised Integration Space.
are excluded on the basis that:
Payments Hub Pattern Coefficient: 21
• There is duplication of functions spe-
cific to each transaction processing sce- Payments Service Bus Pattern Coefficient: 33
nario bundled into the application
components specific to the scenario. The Integration Space for each of the pat-
Hence, there are no connections to terns is shown visually in Figures 16b and
external services and hence no integra- 16c.
tion problem per se.
• It is unlikely that many common serv- Summary
ices exist pre-end state, and hence there Both Payments Hub and Payments Service
are no many-to-many connections to Bus are seen to provide a significant
resolve. reduction in Integration Space complex-
• If there are some shared services, then ity. However, they represent quite different
connection point is difficult to gener- solutions to the payments integration
alise in terms of the model presented. problem. The decision on choice of pat-
tern depends on several factors:
The net effect of excluding these is recog-
nition that the overall complexity is • the specific circumstances of the bank,
increased in all cases, so excluding the accounting for the uniqueness of each

Table 3: Integration Space Complexity Table

Consumer Channel Payment Gateway Product System Payment Engine

Consumer Channel – – 15 30
Payment Gateway – – 15 5
Product System 15 15 9 18
Payment Engine 30 5 18 –

Page 33



Figure 16a–c
Complexity
reduction using the
Payments Hub and
PSB patterns

16a Original

16b Payments Hub Pattern

16c Payments Service Bus Pattern

Page 34


Farrow

Table 4: Summary of advantages/disadvantages of Patterns as a Target End-State

Advantages Disadvantages

Payments Service Bus • Complements existing legacy Payment • Residual integration space remains
Engines; (does not require replace- more complex than that of the
ment of them). Payments Hub, albeit marginal
• Supports multiple technologies for • Difficult in practice to achieve pure
Payment Engine implementations integration capability as some business
• Enables ‘out of the box’ Payment decisioning (eg intelligent payments
Engine functionality to be leveraged routing) must take place outside of the
from vendors products Payment Engines
• Pure integration rather than • Resulting IT estate is more complex
replacement design and build effort with multiple product vendors relating
to each Payment Engine
Payments Hub • Least complex integration space, albeit • More development effort to reach
marginally end-state than the Bus as it requires
• Suits legacy replacement replacement and consolidation of each
• Single Architectural Building Block legacy Payment Engine.
for all payments scheme processing, • Single technology choice may not be
simplifying IT estate and supplier optimal for all scheme processing
management
• Single technology implementation and
simplified systems management
• Is an enabling architecture for custom
processing supporting uniqueness of
payments processing in each bank

bank and the general approach to pay- • separation of architectural concerns, with
ments processing within the business; components optimised for one purpose;
• the scale of the bank’s payments pro- • elimination of the tight coupling of sys-
cessing requirements; tems;
• the complexity of the existing IT archi- • provision of the foundation for shared
tecture for payments processing, com- payment services to be introduced.
prising the heritage Payment Engines
and Product Systems. A number of patterns for payment systems
integration have been presented and their
A summary of the advantages and disad- processing characteristics defined. The pat-
vantages of each of the two candidate patterns are shown to relate to specific appor-
terns is presented in Table 4. tionments of the Payments Processing
Spectrum, which itself provides a useful
visual tool for comparing them.
CONCLUSION IT scenarios to which the patterns are
Payments integration complexity is a relevant have also been highlighted and
major barrier to enabling the business discussed.
agility of a bank. When the integration Certain patterns are seen to address the
problem is addressed, desirable architec- front-end (scheme and channel) integra-
tural goals are achieved, which can tion problem, while others address the
improve business agility: back-end (Product System) integration

Page 35



problem. The relevance of employing spe- ing modernisation. Such planning activity
cific payment Business Services in each of is anything but trivial and must account
the pattern contexts has been demon- for many factors, not least the demanding
strated. time constraints imposed by regulatory
Of the six patterns identified, only deadlines, which tend to dictate non-
Payments Hub and Payments Service Bus strategic solutions. An iterative and incre-
patterns offer a holistic solution to this mental transition strategy can help
payments integration problem, addressing accommodate such factors and a roadmap
both the front-end and back-end integra- should be determined on this basis.
tion problems. For this reason, the
Payments Hub and Payments Service Bus
ACKNOWLEDGMENTS
patterns are presented as prime candidates
for the target end state for payment sys- Thanks are due to Greg Brougham for his
extensive review comments and suggestions for
tems processing. The architectural differ-
improvements to the architecture model.
ence between a Payments Hub solution
and a Payments Service Bus solution has
been qualified using the respective pat- REFERENCES
terns. Further, the impact of the patterns (1) The Open Group Architecture
on the overall integration complexity has Framework (2009) TOGAF 9, ISBN
been quantified in terms of the reduction 978-90-8753-230-7, available at:
in Integration Space complexity. http://www.opengroup.org/togaf
There are considered to be significant (accessed 2nd March, 2012).
implications in choosing one or other of (2) Farrow, G. (2011) ‘The Payments Hub
the end state patterns. In particular, the spectrum; A model for the design of
technology selection for the respective Payments Hubs’, Journal of Payments
integration constructs is influenced heavily Strategy & Systems, Vol. 5, No. 1,
by the characteristics identified in the pat- pp. 52–72.
(3) TOGAF 9, ref. 1 above.
terns. Depending on choice of end-state
(4) Farrow, ref. 2 above.
pattern, long-term commitment to retain (5) Ibid.
or decommission specific legacy technolo- (6) Ibid.
gies may be inferred, and alignment to (7) Hayden, R. Akash, L, Ledford, S. and
overall IT strategy must be assessed and Nunn, C. (2010) ‘Payments Hubs:
validated. Consideration must also be Redefining the industry’s infrastructure’,
given to how development of a payments McKinsey Quarterly, June, available at:
processing system is undertaken within the http://www.mckinsey.com/clientservice
bank; how the development teams are /Financial_Services/Knowledge_
structured; and the long-term skills Highlights/Recent_Reports/
required. Payments.aspx (accessed 16th February,
In conclusion, given the significant 2012).
(8) Ibid.
implications of pattern selection, a bank
(9) Ibid.
must take an early and overt decision as to (10) Farrow, G. (2011) ‘The Canonical Data
the desired target end state for payments Zone: Issues in data selection for Service
processing. Once this decision has been Oriented Architectures’, The Open
reached, business events on the planning Group Conference, 9th–13th May,
horizon can be assessed in terms of their Westminster, London.
suitability as triggers for payments process- (11) Hayden et al., ref. 7 above.

Page 36

Patterns for Payment Systems Integration

More Related Content

What's hot

Viewers also liked

Similar to Patterns for Payment Systems Integration

Recently uploaded

Patterns for Payment Systems Integration