Patterns for Payment Systems Integration

Gary Farrow is Director of Triari Consulting,provider of systems integration and IT architec-ture services for the financial sector. A leadarchitect on many successful, high-value proj-ects, he has undertaken senior architect roles atmajor banks and financial services firms in theUK. Gary has broad expertise in large-scale sys-tems integration, enterprise service bus archi-tectures and Service Oriented Architecture(SOA), and deep domain specialism in paymentssystems. He has written many articles on SOAand payments processing, discussing wide-ranging topics such as anti-patterns, the role ofdata and the optimisation of delivery models.Gary is a member of the IT ArchitectureCertification Board for the Open Group. His pro-fessional qualifications include Fellow IET,Chartered Engineer and Open Group MasterCertified Architect. He holds BSc and PhDdegrees from Manchester University and is analumnus of Warwick Business School, UK.

ABSTRACT

Regulatory, industry and competitive driversdictate that payment initiatives within a bankare many and continuous. However, a commonsituation is that the supporting IT systemshave evolved in an ad hoc manner — thereare often limited separation of architectural con-cerns, many tightly-coupled legacy systems andduplication of processing capability. Systemsintegration complexity is a limiting factor indetermining how quickly IT changes can beachieved. These factors detract from a bank’sability to respond to changes in the business

environment. Selecting the appropriate architec-tural style for payments processing is thereforean extremely important activity. This paperpresents architectural patterns for payment sys-tems integration. These enable the selection ofoptimal architectural solutions for paymentsprocessing. Each pattern is described in terms ofa number of generic Architectural BuildingBlocks1 and their interactions. The general char-acteristics of each pattern are compared, and thesuitability of each pattern in supporting specificbusiness scenarios is presented. The paper alsointroduces the concept of the PaymentsIntegration Space, which defines the scale ofthe systems integration problem. This metric isused to illustrate the role of the patterns inreducing complexity. It is shown that two spe-cific patterns, Payments Hub and PaymentsService Bus, are candidates for the target endstate. Given significant differences in character-istics of the two patterns, it is concluded that abank must make an early and overt choiceabout selecting the most appropriate target endstate for payment systems integration.

Keywords: architectural patterns, trans-action processing, Payments Hub,Payments service bus, systems integra-tion, TOGAF

INTRODUCTIONDeficiencies in payments systems process-ing manifest themselves in business termsas:

Page 15

Journal of Payments Strategy & Systems Volume 6 Number 1

Journal of Payments Strategy &SystemsVol. 6, No. 1, 2012, pp. 15–36� Henry Stewart Publications,1750–1806

Patterns for payment systems integration

Gary S. D. FarrowReceived (in revised form): 31st January, 2012Triari Consulting, 30 Clothorn Road, Didsbury, Manchester, M20 6BP, UK. Tel: +44 (0)161 445 5958; Fax: +44 (0)161 445 5958; e-mail: [email protected]

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

• high business operational overheadsassociated with correcting system pro-cessing errors;

• additional time to effect payments, lead-ing to low customer and business part-ner satisfaction.

An effective payment processing capability,achieving timely completion of paymentsand having ‘straight through’ systems pro-cessing capability with low operationalintervention is therefore considered vital.Also, regulatory, industry, competitive andcost-reduction drivers dictate that pay-ments initiatives within a bank are manyand continuous. Systems must be continu-ally enhanced to support these initiativesand there is extensive integration effort toaccommodate acquisitions and divest-ments. Systems integration complexity isthus a limiting factor in achieving suchbusiness changes quickly.

Elegant payments systems processing,having reduced integration complexityand shared system components, can helpin enabling the business agility of a bank:

• providing faster speed to market ofproducts and services;

• in meeting legal and regulatory compli-ance;

• in responding to industry initiativesquickly.

It can also offer many benefits to a bank’scustomers, notably the ready availability ofthe latest payment processing features,improved reliability and consistency ofservice, and improved transparency of thepayment life cycle.

However, many barriers to effectivepayment processing exist. A typical sce-nario is that the underlying payments sys-tems have developed in an ad hoc manner.Many legacy systems continue to exist,bundling scheme-specific transactionalprocessing with account services.

Consequently there is limited separationof architectural concerns. Duplication ofpayments-related services, such as frauddetection and anti-money laundering, iscommon, and there is invariably no uni-fied approach to systems integration. Allthese factors detract from a bank’s abilityto respond to changes in the competitiveenvironment. Selecting the appropriatearchitectural approach to payment pro-cessing is therefore an important activity.

Architectural patterns provide a specificsolution to a known IT problem. Thus,patterns provide an abstract solution tem-plate applicable to specific scenarios. Inthis respect, the architectural patterns help:

• in understanding what existingapproaches are deployed, where theydeviate from an ideal solution, andhence their limitations;

• illustrate solution options when pay-ments processing is impact due to achange in the business environmentallowing the bank to make an informedchoice of architectural solution;

• to provide an ideal target end state tosupport long-term payments processingplanning and incremental improvementto the payments processing landscape.

This paper discusses a number of architec-tural patterns for payments systems inte-gration.

First, an architectural model for pay-ments processing is presented that forms aframework for the underlying analysis. Thepatterns are identified and described interms of the building blocks of this model,supplemented with an additional compo-nent representing a systems integrationconstruct.

Each pattern is presented in terms ofthe relationships between all the collabo-rating components. A summary of thecharacteristics of the specific integrationcomponent in the given pattern context isalso provided.

Patterns for payments systems integration

Page 16


Page 17

Farrow

Finally, the adoption of each of the pat-terns as the candidate target end state forpayments processing is explored. To thisextent, the degree to which each facilitatesthe desired system processing objectives isassessed, focusing on the extent to whichthe integration complexity is reduced.

PAYMENTS PROCESSINGARCHITECTURAL MODELAn architectural meta-model is now pre-sented that defines a number of abstractsolution components required for pay-ments processing. These coarse-grainedsolution components are termedArchitectural Building Blocks (ABBs).3

The patterns identified are defined interms of the relationship between theseABBs. In each pattern scenario, theresponsibilities of the ABBs remainbroadly similar, but the model allows fordifferences in functional capabilitydepending on how specific paymentsBusiness Services are apportioned. Thefunctional capabilities appropriate to pay-ments processing have been previouslydefined by the author4 and these also formpart of the architectural model.

The set of payments ABBs is nowdescribed.

Payment GatewayThis component represents the system thatinterfaces to a payments scheme. All com-munication to and from the scheme isdone via this component. A PaymentGateway will process both inbound andoutbound payments. Communication toand from the Gateways are typically madeusing industry data standards.

ChannelThis component represents a channelthrough which a customer interacts withthe bank. It may also correspond to thefront/back office system used by internal

bank staff to perform payments on behalfof a customer or for the bank itself. Achannel system will typically only initiateoutbound payments. Communication fromthe Channel components is usually byusing an internal data format unique to thebank, although a derivation of an industryformat is also often the basis of this.

Product SystemThis component represents a core bankingsystem, domiciling the customer accountsthat are the remitter and beneficiary ofpayments.

The remitter and beneficiary accountswould typically each be domiciled in dif-ferent bank product systems, representingthe sending bank and receiving bank. Inthe case of an ‘on us’ payment, both remit-ter and beneficiary accounts are domiciledwithin the same bank’s product systems.

Other circumstances may arise when aparticular bank is acting as an intermedi-ary for payments processing for anotherbank (such as Agency banking orCorrespondent banking arrangements). Inthese circumstances, both remitter andbeneficiary accounts are external to thegiven bank.

Payment EngineThis component performs the activitiesrequired to process a payment, these beingthe discrete set of functions in its valuechain within the organisation. ThePayment Engine must be invoked:

• upon receiving the payment instructionfrom the scheme via the PaymentGateway;

• upon initiation of a payment from aChannel or Product System;

The processing applied to each payment isspecific to each scheme. In this respect, inthis model, a particular Payment Engineprocesses payments for a given scheme only.


A Payment Engine is also referred to inpayments processing as a TransactionProcessing System.

Payment Business ServicesPayment Business Services represent sepa-rate components each providing a pay-ments functional capability. A number ofsuch capabilities exist and a model for pay-ments processing has been defined previ-ously and is shown in Figure 1.

Payment Business Services must beorchestrated to fulfil the required process-ing on each inbound or outbound pay-ment. There is not necessarily a singlecontrol point for this orchestration, whichmay be distributed across a number ofcomponents. For example:

• Channel components may call valida-tion services to ensure a well formedpayments message is constructed.

• A Payment Engine will orchestrate anumber of such services to post accountentries and to call financial crime serv-ices, such as fraud, sanctions and anti-

money laundering checks.• A separate integration component may

call required technical integration serv-ices such as routing and transformation.

Payment Processing SpectrumThese capabilities above have been struc-tured previously into an ordered list,termed the Payments Hub Spectrum.6

Simplistically, middleware capabilities arepositioned to the left of the Spectrumwith Payments Business Services ofincreasing functional richness positionedto the right of the Spectrum. Since a ‘Hub’is subsequently shown to constitute onevery specific payment processing pattern,this paper references this Spectrum moregenerally as the Payments ProcessingSpectrum, shown in Figure 2.

In the integration patterns defined,these capabilities are shown to be appor-tioned across the set of ABBs identified.The manner in which these capabilitiesare apportioned differs for each patternand is highlighted in each pattern descrip-tion.


Page 18

Figure 1Paymentsprocessingcapabilities (afterFarrow)5


Payments Integration Space

The generic Integration Space is defined asthe set of architectural components andtheir connections required to support theprocesses of a given business domain. TheIntegration Space is defined without mid-dleware components.

Figure 3 shows the Integration Spacespecifically for the payments businessdomain, expressed in terms of thePayments Processing Architectural Modeldescribed above, the ABBs equating to thearchitectural components. The shaded arearepresents an indeterminate number ofpoint-to-point interconnections betweenthe ABBs. External B2B connections arerequired to support interaction withbanks, commercial partners, agency banks,payment schemes and messaging systems.B2C connections are also required withthe bank’s customers.

A variety of interconnections arerequired within the bank’s organisationalboundary. It is these internal organisationalconnections within the PaymentsIntegration Space that are the subject ofanalysis and to which the patterns pre-sented are applicable.

Interconnections are shown between

all components. The complexity of theIntegration Space is defined by thenumber of interconnections between thepayments system application compo-nents.

Table 1 shows the cardinality of the eachof the inter-connections between the ABBcomponents identified for the Paymentsdomain (m denotes many entities).

The Complexity Table provides a con-venient view of the complexity of theintegration problem. Many-many connec-tions represent a hotspot of complex inte-gration. It is seen that mostinterconnections between the genericcomponents are many-many. Channelstypically connect to Gateways via aPayment Engine and not directly, and sothere is no Channel to Payment Gatewayconnection. Similarly a Channel does notconnect to other Channels, nor does aPayment Engine typically connect toother Payment Engines.

The Payment Gateway to PaymentEngine connection is shown as 1-1,reflecting the stated model that a PaymentEngine is dedicated to one specific schemeand will process payments only for thatscheme via its Gateway. In some circum-

Page 19

Farrow

Figure 2PaymentsProcessingSpectrum


stances, a common messaging infrastruc-ture is used across several schemes and alsoto communicate with business partners,such as Agencies and Correspondents. Theprime example of this is the SWIFT mes-saging infrastructure. In this scenario, asingle Gateway may connect to multiplePayment Engines and the relationship ofone Gateway to many Engines (1-m) isalso possible.

A further point to note is that theProduct System is the only componentthat connects with itself. This reflects ‘on-us’ payments made between customers ofthe same bank.

The Complexity Table must be popu-lated for a given bank to create a specific,quantified, table instance. This then pro-vides a unique view of the PaymentsIntegration Space for that bank andenables a ‘heat map’ to be deduced, high-lighting the areas of greatest integration

complexity. An example is provided laterin the analysis.

PATTERN DESCRIPTIONSSix architectural patterns for paymentsintegration are now presented:

(i) Payment Engine Routing Utility;(ii) Product System Routing Utility;(iii) Front End Payments Hub;(iv) Back End Payments Hub;(v) Payments Hub;(vi) Payments Service Bus.

Each pattern incorporates the ABBsdescribed in the architectural model, sup-plemented with an additional componentrepresenting a systems integration con-struct.

In each pattern, the relationships,including cardinality, between all the


Page 20

Figure 3PaymentsIntegration Space


components are illustrated. A summary ofthe characteristics of the integrationcomponent in the given pattern contextis also provided. These characteristics arequalified as a set of attributes, shown inTable 2.

For each pattern, scenarios where thepattern is considered useful are described.Finally, using the Payments ProcessingSpectrum, the apportionment of function-ality to the components in each pattern isillustrated. This provides a convenientvisual perspective to compare the patterns.

Payment Engine Routing Utility

OverviewThis pattern represents a solution for inte-grating a single Payment Gateway intomultiple payment engines or ProductSystems.

The Payment Gateway is connected toa single Payment Engine Routing Utility(Figure 4). This, in turn, is connected totwo or more Payment Engines/ProductSystems. The Payment Engines and

Product Systems themselves are assumedto be tightly coupled and are showntogether, effectively acting as one entity.Thus the pattern does not address theintegration problem between the PaymentEngine and Product System components.

In general there are three categories offunctional capability that may be per-formed by pattern component:

(i) Integration Services;(ii) Business Services;(iii) Process Services.

The sole function of the Payment EngineRouting Utility is to interface to theGateway and route payment instructionsto and from the Payment Engines. Thus, ofthe three categories, the Payment EngineRouting Utility provides only IntegrationServices. The combination of the PaymentEngine and the Product Systems providethe rest of the payments processing capa-bility.

The Payment Engine Routing Utilitydoes not manage any business state. It may,

Page 21

Farrow

Table 1: Payments Integration Space Complexity Table

Channel Payment Gateway Product System Payment Engine

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

Table 2: Pattern attribute descriptions

Attribute Description

Integration Capability Defines whether the component has integration capabilityBusiness Capability Defines whether the component incorporates functionality from one or

more of the business capabilitiesProcess Capability Defines the extent of the process orchestration capabilityState Management Defines the extent of the state management of the componentConnection Style Defines the connection style in terms of how and when the component is

invoked


however, manage technical state relating tointeractions with the Gateway.

Spectrum ApportionmentThe Payment Engine Routing Utilityconstruct provides pure middleware serv-ices and is shown in Figure 5 occupyingthe left-hand side of the Spectrum.

Capabilities from the Spectrum utilisedin this pattern include:

• Routing, to achieve the Payment Engineselection;

• Transformation, to transform fromscheme to respective formats requiredby each of the Payment Engines;

• Validation of inbound messages receivedfrom the scheme.

ScenariosThis pattern is useful when introducing anew Payment Engine. Typically the migra-

tion from legacy engine to new enginecannot be achieved in one ‘big bang’ and aphased approach is adopted, requiring oldand new payment engine instances to beconcurrently live.

As a specific example of this pattern, aglobal commercial bank intended to replaceits legacy Payment Engine for CHAPS pro-cessing with a new product solution, thisbeing Fundtech Global PAYplus. ARouting Utility was introduced to switchpayments to one or other of the PaymentEngines. This approach de-risked the solu-tion implementation, allowing for a gradualmigration of customers to the newPayment Engine.

Similarly it has use in supporting a bank-ing integration. In this situation, a paymentsscheme Gateway may be consolidateddown to one of the original banks’ Gatewaycomponents. Underlying internal systemsprocessing in the short term may beuntouched, requiring routing from theconsolidated Gateway to each of the origi-nal banks’ respective payment engines.

Summary

Product System Routing Utility

Overview

This pattern (Figure 6) represents a solu-tion to integrate a single Payment Engineto multiple Product Systems.

The Payment Gateway is connected to


Page 22

Figure 4 PaymentEngine RoutingUtility pattern

Payment Engine Routing Utility

Attribute Value

Integration Capability YesBusiness Capability NoProcess Capability NoState Management No business state, but

potential technical transaction state

Connection Style Single Pass


a single Payment Engine, dedicated to aspecific scheme. The pattern assumes thatcustomer accounts are domiciled acrossmultiple Product Systems. Commonalityof processing for all payments relating toone scheme is achieved, but there is anintegration problem to route payments tomultiple Product Systems that theRouting Utility resolves.

As per the Payment Engine RoutingUtility, the Product System RoutingUtility provides only Integration Services.The combination of the Payment Engineand the Product Systems provide the restof the payments processing capability.

The Product System Routing Utilitycomponent also does not manage anybusiness state. It may, however, managetechnical state relating to interaction withthe Product Systems; for example, techni-cal retries and the batching of requests foroffline Product Systems.

Spectrum ApportionmentAs per the Payment Engine Routing util-ity, capabilities employed in this pattern aremiddleware services, and hence the pat-tern apportions capabilities from the left-hand side of the Spectrum (Figure 7).

Capabilities from the Spectrum utilisedin this pattern include:

• Routing, to achieve the Product Systemselection.

• Transformation, to transform fromscheme to respective formats requiredby each of the Product Systems

• Validation of outbound messages andbulk payment files received from theProduct Systems

ScenariosThis pattern is useful in the scenario relat-ing to the introduction of a new paymentscheme. In such circumstances, a newPayment Gateway is assumed. The sce-nario then further assumes that a newPayment Engine is introduced, dedicatedto the new scheme. The Routing Utility

Page 23

Farrow

Figure 5 PaymentEngine RoutingUtility SpectrumApportionment

Figure 6 ProductSystem RoutingUtility Pattern


then provides the necessary integrationservices to interface the new PaymentEngine to the existing Product Systems.

As a specific example of the pattern,when the Faster payments Scheme (FPS)was introduced in the UK, a large retailbank deployed a dedicated solution stackcomprising ACI Gateway as the Gatewaycomponent and ACI Money TransferSystem as the Payment Engine. ARouting Utility was developed to routepayments to and from multiple ProductsSystems using IBM WebSphere MessageBroker.

The pattern is also considered relevantwhen a new Product System is introducedin the bank’s IT estate. This may arise:

• As a consequence of core bankingplatform migration. In such a scenario,account migration is not achieved inone ‘big bang’ and a phased approach isrequired, where old and new ProductSystems are concurrent. Thus, co-exis-tence of the multiple Product Systemsis required as an interim state and theRouting Utility is a transient con-struct.

• As a consequence of a banking integra-tion when new Product Systems areacquired. This pattern equates to a dif-ferent integration point for the inte-grated bank systems, this being theProduct Systems rather than thePayment Engine as per the PaymentEngine Routing Utility pattern.

Summary

Front End Payments Hub

Overview

This pattern (Figure 8) constitutes a gen-eralisation of the Payment EngineRouting Utility pattern. It is also similar tothe Front End Landing Zone, this being acategory of Payments Hub suggested byHayden et al.7 In this respect, the patternrepresents an architectural formalisation ofthis particular payments integration strat-egy using the constructs defined in thePayments Processing Architectural Model.

The Front End Landing Zone is shownprocessing only payment instructions inputfrom the Channels, and the integrationfrom Channels to Hub is shown as beingunidirectional. The Front End PaymentsHub connects to several PaymentGateways, each relating to a scheme in


Page 24

Figure 7 ProductSystem RoutingUtility SpectrumApportionment

Product System Routing Utility

Attribute Value

Integration Capability YesBusiness Capability NoProcess Capability NoState Management No business state, but

potential technical transaction state onlyrelating to Product Systeminteractions



which the bank participates. In this respect,the Front End Payments Hub processesboth inbound and outbound paymentsinstructions from the Payment Gatewayand 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 paymentinstructions, 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 connectsto one or more Payment Engines but doesnot connect to the Product Systems. Thus,as with the Payment Engine RoutingUtility pattern, this pattern does not addressthe integration problem between thePayment Engines and the Product Systems.

Spectrum ApportionmentThis pattern construct provides middle-ware services as per the two RoutingUtility patterns. It also provides the oppor-tunity to introduce several paymentBusiness Services (Figure 9). Consideringthe Capability Model, in addition to theRouting, Transformation and Validation,candidate Business Services include:

• Diary management, providing functional-ity for altering on files that are expectedto be received or sent to a scheme on agiven day according to the schemeoperating times;

• Almanac, this being the determinationof the Diary events for a given day;

• Anti-money laundering (AML) and fraudservices, for example, sanctions checkingon all inbound payments and eventfeeds to AML and fraud managementsystem components;

• Account validation, to validate the benefi-ciary account for an inbound payment;

• Repair, supporting the correction ofpayment instructions incorrectlyformed from the channels;

• Enrichment, supporting enrichment of

the payment instructions with bank-specific technical or business data;

• Payments Repository, providing a ware-house of all payments instructions foraudit purposes. In this pattern, the FrontEnd Payment Hubs has visibility of allinbound payments from the schemesand all outbound payments originatedfrom the channels. It is therefore a sen-sible point of control for updating orimplementing a centralised PaymentsRepository;

• Intelligent payments routing, enablingscheme selection based on general cri-teria, for outbound payments originatedfrom the Customer Channels.

Process services may therefore also berequired to orchestrate these BusinessServices.

ScenariosThis pattern addresses the payments chan-nel integration problem across the entirebank. Thus, It is most relevant when thechannel integration problem is more com-plex than the back-end integration prob-

Page 25

Farrow

Figure 8 FrontEnd Payments Hub


lem. Circumstances where this may ariseare when a bank is a member of manyschemes and has many delivery channelsbut only a limited number of ProductSystems. In such circumstances, this pat-tern is considered a viable solution.

Secondly, this pattern has been sug-gested8 as an interim state towards achiev-ing a more complete payments integrationsolution (ie one that addresses front- andback-end integration). In this case, theFront End Payments Hub supports a strat-egy for the phased introduction ofcommon payments-processing services,leading to the desired end-state solution.The form of such end-state solutions isdefined and discussed in two further candi-date patterns: Payments Hub and PaymentsService Bus.

Summary of characteristics

Back End Payments HubThis pattern (Figure 10) is a generalisationof the Product System Routing Utilitypattern. It also broadly equates to Back EndAggregation, this also being a further cate-gory of Payments Hub suggested byHayden et al.9 Again, the pattern representsan architectural formalisation of this pay-ments processing strategy using thedefined Architectural Model constructs.

In this pattern, the Back End PaymentsHub connects to one or more ProductSystems. It may also connect to someBusiness Services, each providing a servicecommon to all payments processing.

It is seen that the Back End Hub pat-tern addresses the integration problem ofintegrating the Payment Engines to theProduct Systems. The Back EndPayments Hub provides the services tointegrate the Product Systems and othercomponents providing Business Services.In this way it exposes Business Servicesthat may be used by several PaymentEngines to fulfil the payment process.Thus, in this pattern, the Payment Engineis the main provider of the process serv-ices, fulfilling a payments process usingBusiness Services exposed via the BackEnd Payments Hub.

Spectrum ApportionmentAs per the Front End Hub, it may providea number of Business Services (Figure 11)or delegate these to other componentsproviding shared Business Services.


Page 26

Figure 9 FrontEnd Hub SpectrumApportionment

Front End Payments Hub

Attribute Value

Integration Capability YesBusiness Capability Provides some shared

services or delegates theseto other components

Process Capability Some orchestration capability required

State Management Stateful or stateless,depending on the specificsof the Business Servicesemployed



Candidate Business Services for this pat-tern, include:

• Account Posting, to post to the back endProduct Systems;

• Mandate Management, providing cen-tralised management of mandates foroutbound standing orders, decouplingthis functionality from the ProductSystems;

• Intelligent Payments Routing, enablingscheme selection based on general cri-teria, for outbound payments. Paymentorigination for this pattern relates tomandates only;

• Payments Repository. In this pattern, theHub construct has visibility of out-bound payments originated by theProduct Systems, but not necessarily allinbound payments from the scheme orinitiated from the Customer Channels.It is therefore a point of control only forupdating a centralised PaymentsRepository for the outbound paymentsrelating to mandates.

As per the Front End Payments Hub,Process Services may therefore also berequired to orchestrate these BusinessServices, although as is seen, the scope ismore limited.

ScenariosThis pattern addresses the back-end pay-ments integration problem across the

entire bank. Thus, this pattern is most rel-evant when the back-end integrationproblem is more complex than the chan-nel integration problem. A circumstancewhere this may arise is when a bank is amember of a limited number of schemesand/or has limited delivery channels, buthas several Product Systems. In such cir-cumstances, this pattern is considered anappropriate solution.

Again, this pattern has been suggested asonly an interim state towards achieving amore holistic end-state payments integra-tion solution. The Back End PaymentsHub, in this case, supports a strategy for

Page 27

Farrow

Figure 10 BackEnd Payments HubPattern

Figure 11 BackEnd Hub SpectrumApportionment


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


Payments Hub

OverviewThe term ‘Payments Hub’ is a widely usedexpression for a generalised solution topayments processing. This pattern (Figure12) provides a more precise definition of aPayments Hub in terms of theArchitectural Model constructs.

In this pattern, the Hub is the centralintegration point of all the componentsinvolved in payments processing. None ofthe components interact without commu-nication through the Payments Hub. Allthe necessary integration capability residesin the Payments Hub. Connectionsbetween the components require only asingle pass through the Payments Hub.

In this respect:

• One or more Customer Channels areconnected to the Payments Hub.

• One or more Product Systems are con-nected to the Payments Hub.

• One or more Payment Gateways areconnected to the Payments Hub.

• The Payments Hub may either:—provide Payments Business Servicesitself (internal capabilities); or—connect to zero or more externallyprovided Payments Business Services.

All orchestration of Business Services isundertaken by the Payments Hub. In thispattern, the Payments Hub contains theaggregate set of Process Services capabili-ties required to support all scheme pro-cessing. The Payments Hub thereforesubsumes the functionality of the PaymentEngine (transactional processing) compo-nents, and this is not required in this pat-tern. Some commonality of processingsteps may be achieved across schemes but,more significantly, reusable shared servicesare employed to undertake the specifictasks in the processing chain.

The placement of the orchestrationcapability within the Hub infers businessstate management, as the Hub mustaccommodate and manage a variety ofbusiness exception conditions that typi-cally occur in processing a payment.

Spectrum ApportionmentIn terms of the categories of service pro-vided by the Hub, it provides all of:


Page 28

Back End Payments Hub

Attribute Value

Integration Capability YesBusiness Capability May provide or delegate

some servicesProcess Capability Some limited capability may

be requiredState Management No business state, but may

manage technical state relating to transactions withProduct Systems


Figure 12 Payments Hub Pattern


• Integration Services;• Business Services;• Process Services.

Thus, in this pattern, the Payments Hubconstruct may employ capabilities fromthe entire Spectrum. Some of the capabil-ities may be provided by the PaymentsHub itself, or some or all of the capabilitiesmay be delegated, but always called fromthe Hub. Unlike the Front or Back EndPayments Hub, this construct has visibilityof all payments from all schemes and chan-nels. This enables the opportunity foradditional Business Services to be pro-vided or orchestrated from this compo-nent (Figure 13), specifically:

• Liquidity Management, monitoring theoverall liquidity position of the bankwith respect to the schemes;

• Scheme Limits Management, providing theopportunity for alerting and pro-activemanagement should the scheme limitsbe approached or if individual paymentsexceed the limits;

• Payments Repository, now encompassingall payments;

• Transformation, providing a more generaltransformation service of payment mes-sages into a specific canonical data

format appropriate to the bank.Achieving this allows for harmonisationof payments processes, simplificationand reuse;10

• State Machine, this being necessary tosupport the stateful processing per-formed by the Payments Hub.

ScenariosThis pattern provides a generalised solu-tion to payments integration within abank. It is applicable when there is a com-plex integration problem with respect tothe channels and the back end ProductSystems — simplistically many Gatewaysand Customer Channels — and manyProduct Systems.

The pattern provides a single solutionto scheme-specific transactional process-ing. Thus, it is useful in achieving architec-tural simplification as it consolidates allPayment Engines into one component.

As an example of the use of this pattern,a UK retail bank embarked on a pro-gramme of core banking modernisation,introducing Infosys Finacle as the newProduct System. The bank was a fullmember of all UK payment schemes.Channel integration complexity was high,but there were a limited number ofProduct Systems. However, to support a

Page 29

Farrow

Figure 13Payments HubPattern SpectrumApportionment


strategy of gradual migration of paymentservices to the new banking platform, aPayments Hub solution was conceived andimplemented using technologies fromClear2Pay.


Payments Service Bus

DescriptionThe Payments Service Bus (PSB) is also awidely used term for a generalised solu-tion to payment processing within thebank (Figure 14). The differences betweenthis and the Payments Hub are how clearlyarticulated in terms of the ArchitecturalModel.

Unlike the Payments Hub, this patternis premised on the existence of a numberof separable Payment Engines, typicallyone per scheme. All integration to andfrom the Payment Engines is provided bythe Payments Service Bus. In this way, acommon utility is provided for all pay-ments integration within the bank. ThePayments Service Bus can be considered asa specialism of an Enterprise Service Bus,but specific to payments integration.

The PSB connects to all ConsumerChannels and Gateways. It also connectsto multiple Product Systems and to sharedBusiness Services. No payment instructionpasses between the payments system com-ponents without mediation by the PSB.

Business Service orchestration is pro-vided solely by the Payment Engines, eachof which may be tailored to provide thespecific processing demanded by a scheme,optionally complemented by the banksown value-add services.

Processing of an inbound paymentinstruction, from receipt at a Gateway toposting to an account in a ProductSystem, requires several passes through thePSB:

• collection from the Gateway with rout-ing and onward transmission to the cor-rect Payment Engine;

• calls to a number of the BusinessServices, orchestrated by the PaymentEngine, but mediated by the PSB;

• selection of the recipient ledger systemand associated account posting to thecorrect Product System.

The PSB itself need only provide stateless‘one shot’ services. It is the Payment


Page 30

Payments Hub

Attribute Value

Integration Capability YesBusiness Capability YesProcess Capability YesState Management Stateful with respect to

business state and alsotechnical state


Figure 14 Payments Service Bus Pattern


Engines that manage any payment businessstate if it is necessary to do so.

Spectrum ApportionmentIn this pattern, the Bus construct providesonly the integration services and henceoccupies the left-hand portion of theSpectrum. Multiple Payment Engines pro-vide scheme-specific process services andimplement (or orchestrate) some or all theBusiness Services, and hence are shownoccupying the middle and high end of theSpectrum. As per the Payments Hub pat-tern, the construct has visibility of all pay-ments and so Business Services across theentire Spectrum are applicable in this pat-tern (Figure 15).

ScenariosAs with the Payments Hub pattern, thePSB also provides a generalised solutionto payments integration across the bank,solving the problems of front- and back-end integration. This pattern does notrequire the replacement of legacyPayment Engines; rather it recognises andcomplements the scenario of multiplePayment Engines.

The pattern is therefore useful in bankswhere there exist multiple, diverse,deployed instances of Payment Engines.

Given the knowledge capital invested inthe existing Payment Engines, likely com-plexity of legacy implementations (imply-ing huge effort to replicate and replace)this pattern supports a strategy of theircontinued use. Thus, the PSB solutionallows for their retention and focuses onaddressing the integration problembetween the Payment Engines and theother payment solution components. Incomparison with the Payments Hub pat-tern it therefore avoids significant effort inPayment Engine replacement.

This solution pattern was selected by alarge UK retail bank as a solution to thepayment integration problem. The bankwas a full member of all UK and Europeanschemes with dedicated Payment Enginesand having several major Product Systems.The bank took a view, as highlightedabove, that consolidation of its diverserange of Payment Engines into a singlesolution across the bank was a massiveundertaking, not feasible in a short tomedium time frame. Rather a strategy ofleveraging existing Payment Engines, anda policy of gradual, targeted, replacementwas employed. The Payments Service Buspattern was identified to support this strat-egy. Technology selection and implemen-tation is ongoing within the bank.

Page 31

Farrow

Figure 15Payments ServiceBus SpectrumApportionment



TARGET END STATE SELECTION

Considerations

The target end state represents the ideallong-term vision for payments systemsprocessing.

Recall the dual objectives of effectiveand elegant system processing. Theseobjectives will be met to a large extent byreducing the integration complexity. Allthe patterns described do provide a reduc-tion in this complexity and therefore sup-port these objectives to some degree. Thisnow poses an interesting question: of thepatterns identified, is there a single patternthat represents the preferred end state forpayments processing, or are alternativetarget end states viable?

It is evident that to achieve integrationsimplification, and target end state mustaddress the holistic integration problemcovering both front-end and back-endintegration.

Hayden et al.11 present theConsolidated Transaction Hub as thesingle preferred end state that achievesthis. In terms of the patterns describedhere, this aligns most closely with thePayments Hub pattern. In their context,both the Front End Payments Hub andBack End Payments Hub patterns areuseful only as introduction strategies forachieving this end state.

However, the pattern analysis presentedhere reveals that there are in fact two key

patterns that address the holistic paymentsintegration problem, covering both front-and back-end integration. These are thePayments Hub and the Payments Service Bus.Therefore, both these represent viable can-didate end states.

To help assess the suitability of these twopatterns as the preferred target end stateand achieve a comparison, their effective-ness in reducing integration complexity isassessed using the Integration SpaceComplexity Table defined in Table 1.

End state suitability assessmentFor the purposes of comparison, a specificIntegration Space Complexity Table isillustrated using the following parameters,typifying a medium retail bank with fullUK scheme membership and a multi-channel delivery strategy. In this context, itis assumed the bank offers the followingchannels:

(i) branch;(ii) internet banking;(iii) telephone banking;(iv) postal services with associated back

office systems;(v) a business partner channel via a dedi-

cated system.

Six schemes are assumed, equating to coun-try-specific schemes. For the UK, these areBACS, Clearings, CHAPS, Faster Payments,cards, and also International payments. Theexample assumes that a shared PaymentGateway is used to support two schemes(eg CHAPS and International payments,both processing SWIFT messages). Thenumbers are therefore arbitrary but relate torealistic circumstances.

Schemes 6Consumer Channels: 5Payment Gateways: 5Product Systems: 3Payment Engines: 6


Page 32


Attribute Value

Integration Capability YesBusiness Capability DelegatedProcess Capability NoState Management StatelessConnection Style Many passes


Page 33

Farrow

For simplicity, it is assumed that allChannels:

• support payments types for all schemes;and

• a connection to all Product Systems isrequired for account updates.

In practice all payment types may not beoffered from all Channels and someaccount updates would be controlled bythe Payment Engine. Such factors wouldlower the integration complexity in real-ity. This derives a specific table below(Table 3).

Note that the Integration Space doesnot account for any integration to compo-nents providing Business Services. Theseare excluded on the basis that:

• There is duplication of functions spe-cific to each transaction processing sce-nario bundled into the applicationcomponents specific to the scenario.Hence, there are no connections toexternal services and hence no integra-tion problem per se.

• It is unlikely that many common serv-ices exist pre-end state, and hence thereare no many-to-many connections toresolve.

• If there are some shared services, thenconnection point is difficult to gener-alise in terms of the model presented.

The net effect of excluding these is recog-nition that the overall complexity isincreased in all cases, so excluding the

Business Services does not detract fromthe analysis given.

The original Payments IntegrationSpace relating to this example is showngraphically in Figure 16a.

For the Payments Integration Space, anoverall complexity coefficient is intro-duced, defined as the total sum of the inte-grations. In the example defined:

Example Integration Space Coefficient: 175

The effect on the reduction in theIntegration Space complexity is now illus-trated for the two candidate end-states pat-terns. By applying them to the exampleproblem space, the connectivity is re-evalu-ated to give the revised Integration Space.

Payments Hub Pattern Coefficient: 21

Payments Service Bus Pattern Coefficient: 33

The Integration Space for each of the pat-terns is shown visually in Figures 16b and16c.

SummaryBoth Payments Hub and Payments ServiceBus are seen to provide a significantreduction in Integration Space complex-ity. However, they represent quite differentsolutions to the payments integrationproblem. The decision on choice of pat-tern depends on several factors:

• the specific circumstances of the bank,accounting for the uniqueness of each

Table 3: Integration Space Complexity Table

Consumer Channel Payment Gateway Product System Payment Engine

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



Page 34

Figure 16a–cComplexityreduction using thePayments Hub andPSB patterns

16a Original

16b Payments Hub Pattern

16c Payments Service Bus Pattern


bank and the general approach to pay-ments processing within the business;

• the scale of the bank’s payments pro-cessing requirements;

• the complexity of the existing IT archi-tecture for payments processing, com-prising the heritage Payment Enginesand Product Systems.

A summary of the advantages and disad-vantages of each of the two candidate pat-terns is presented in Table 4.

CONCLUSIONPayments integration complexity is amajor barrier to enabling the businessagility of a bank. When the integrationproblem is addressed, desirable architec-tural goals are achieved, which canimprove business agility:

• separation of architectural concerns, withcomponents optimised for one purpose;

• elimination of the tight coupling of sys-tems;

• provision of the foundation for sharedpayment services to be introduced.

A number of patterns for payment systemsintegration have been presented and theirprocessing characteristics defined. The pat-terns are shown to relate to specific appor-tionments of the Payments ProcessingSpectrum, which itself provides a usefulvisual tool for comparing them.

IT scenarios to which the patterns arerelevant have also been highlighted anddiscussed.

Certain patterns are seen to address thefront-end (scheme and channel) integra-tion problem, while others address theback-end (Product System) integration

Page 35

Farrow

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

Advantages Disadvantages


Payments Hub

• Complements existing legacy PaymentEngines; (does not require replace-ment of them).

• Supports multiple technologies forPayment Engine implementations

• Enables ‘out of the box’ PaymentEngine functionality to be leveragedfrom vendors products

• Pure integration rather thanreplacement design and build effort

• Least complex integration space, albeitmarginally

• Suits legacy replacement• Single Architectural Building Block

for all payments scheme processing,simplifying IT estate and suppliermanagement

• Single technology implementation andsimplified systems management

• Is an enabling architecture for customprocessing supporting uniqueness ofpayments processing in each bank

• Residual integration space remainsmore complex than that of thePayments Hub, albeit marginal

• Difficult in practice to achieve pureintegration capability as some businessdecisioning (eg intelligent paymentsrouting) must take place outside of thePayment Engines

• Resulting IT estate is more complexwith multiple product vendors relatingto each Payment Engine

• More development effort to reachend-state than the Bus as it requiresreplacement and consolidation of eachlegacy Payment Engine.

• Single technology choice may not beoptimal for all scheme processing



Page 36

problem. The relevance of employing spe-cific payment Business Services in each ofthe pattern contexts has been demon-strated.

Of the six patterns identified, onlyPayments Hub and Payments Service Buspatterns offer a holistic solution to thispayments integration problem, addressingboth the front-end and back-end integra-tion problems. For this reason, thePayments Hub and Payments Service Buspatterns are presented as prime candidatesfor the target end state for payment sys-tems processing. The architectural differ-ence between a Payments Hub solutionand a Payments Service Bus solution hasbeen qualified using the respective pat-terns. Further, the impact of the patternson the overall integration complexity hasbeen quantified in terms of the reductionin Integration Space complexity.

There are considered to be significantimplications in choosing one or other ofthe end state patterns. In particular, thetechnology selection for the respectiveintegration constructs is influenced heavilyby the characteristics identified in the pat-terns. Depending on choice of end-statepattern, long-term commitment to retainor decommission specific legacy technolo-gies may be inferred, and alignment tooverall IT strategy must be assessed andvalidated. Consideration must also begiven to how development of a paymentsprocessing system is undertaken within thebank; how the development teams arestructured; and the long-term skillsrequired.

In conclusion, given the significantimplications of pattern selection, a bankmust take an early and overt decision as tothe desired target end state for paymentsprocessing. Once this decision has beenreached, business events on the planninghorizon can be assessed in terms of theirsuitability as triggers for payments process-

ing modernisation. Such planning activityis anything but trivial and must accountfor many factors, not least the demandingtime constraints imposed by regulatorydeadlines, which tend to dictate non-strategic solutions. An iterative and incre-mental transition strategy can helpaccommodate such factors and a roadmapshould be determined on this basis.

ACKNOWLEDGMENTS

Thanks are due to Greg Brougham for hisextensive review comments and suggestions forimprovements to the architecture model.

REFERENCES

(1) The Open Group ArchitectureFramework (2009) TOGAF 9, ISBN978-90-8753-230-7, available at:http://www.opengroup.org/togaf(accessed 2nd March, 2012).

(2) Farrow, G. (2011) ‘The Payments Hubspectrum; A model for the design ofPayments Hubs’, Journal of PaymentsStrategy & Systems, Vol. 5, No. 1, pp. 52–72.

(3) TOGAF 9, ref. 1 above.(4) Farrow, ref. 2 above.(5) Ibid.(6) Ibid.(7) Hayden, R. Akash, L, Ledford, S. and

Nunn, C. (2010) ‘Payments Hubs:Redefining the industry’s infrastructure’,McKinsey Quarterly, June, available at:http://www.mckinsey.com/clientservice/Financial_Services/Knowledge_Highlights/Recent_Reports/Payments.aspx (accessed 16th February,2012).

(8) Ibid.(9) Ibid.

(10) Farrow, G. (2011) ‘The Canonical DataZone: Issues in data selection for ServiceOriented Architectures’, The OpenGroup Conference, 9th–13th May,Westminster, London.

(11) Hayden et al., ref. 7 above.
