the payments hub spectrum: a model for the design of ... payment hub spectrum.pdfpage 57 farrow...

Gary Farrow is Director of Triari Consulting,provider of systems integration and IT architec-ture services for the financial sector. A leadarchitect on many projects, he has undertakensenior architect roles at major banks. He hasbroad expertise in large-scale systems integra-tion, enterprise service bus architectures andservice-oriented architecture (SOA) and deepdomain specialism in payments systems. He haswritten many articles on SOA and payments pro-cessing. Gary is a member of the IT ArchitectureCertification Board for the Open Group and is anAssociate Lecturer at the Open University.Professional qualifications include Member IET,Chartered Engineer and Open Group MasterCertified Architect. He holds BSc and PhDdegrees from Manchester University and aCertificate in Business Administration fromWarwick Business School, UK.

ABSTRACT

Recent events in the financial sector have givena high profile to financial services governance. Inthe area of payments, there is a need to providetransparency and traceability of monetary move-ments. Other changes in the market environ-ment include the strengthening of regulationsand the introduction of new euro zone pay-ments frameworks. The credit crunch furtherhighlighted the need to monitor systemic riskexposure associated with settlement — espe-cially for the major clearing banks that processpayments for their agency banks. This paperdescribes a specialised IT component — the

payments hub — and the design considerationsin meeting the current payments industry busi-ness drivers. A conceptual model of a paymentshub is introduced and its business benefitsdescribed. The functional capabilities of a pay-ments hub are presented, categorised into threeareas: process services; business services; andintegration services. The technical justificationfor a hub is presented, highlighting its role inreducing integration complexity and in support-ing modernisation initiatives within a bank.The ‘Payment Hub Spectrum’ is introduced,describing an ordered range of functional serv-ices. Depending on the specific business needs ofa bank and its underlying IT systems land-scape, these are shown to dictate a functionallylight or a functionally rich payments hub. Thebusiness and technical factors affecting the posi-tion on this spectrum are highlighted. In conclu-sion, the Payments Hub Spectrum is shown tobe a useful model for solution analysis, inform-ing the architectural decisions on technologychoice and on the apportionment of paymentsprocessing capability between the key collaborat-ing components.

Keywords: payment services hub, pay-ment hub design, payments integration,liquidity management, payments capa-bility model

PAYMENTS HUB OVERVIEWFigure 1 shows a context diagram of a

Journal of Payments Strategy & Systems Volume 5 Number 1

Page 52

Journal of Payments Strategy &SystemsVol. 5 No. 1, 2011, pp. 52–72� Henry Stewart Publications,1750–1806

The Payments Hub Spectrum: A model forthe design of payments hubs

Gary S. D. FarrowReceived (in revised form): 18th February, 2011Triari Consulting, UK. Tel: +44 (0)7554 423009; Fax: +44 (0)161 445 6508; e-mail: [email protected]

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

payments hub at a conceptual level. Sub-systems that interact with a payments hubare:

• Product systems: these systems domicilethe banking ledgers that are the sourceand destination for payments.

• Channel systems: these systems supportthe customer channels through whichpayment services are offered. These typ-ically include: branch; Internet; andtelephony. In the future, it is expectedthat new channels such as mobile pay-ments, will be introduced.1

• Payment gateways: these constitute thegateways to the various paymentschemes.

Electronic payment instruments are

received from and sent to the schemes andbusiness partners in a variety of industryformats.

CapabilitiesConsider a service-oriented architecture(SOA) perspective applied to paymentsprocessing. Using a simple layered refer-ence model for SOA,2 a payments hub canbe considered to provide three major cat-egories of service capability:

(i) process services;(ii) business services;(iii) integration services.

The combination of these different servicetypes infers that a payments hub is a com-plex, ‘compound’ component spanning

Page 53

Farrow

Productsystems

Payment hub

Otherschemes

Agencybanks

Business partners

Figure 1Payments high-levelsystem overview


three architectural layers. Since the hubsupports these three different servicetypes, a single, product mapping is difficultto achieve. Rather, a combination of soft-ware packages and middleware products istypically required.

A payments hub contains a variety ofdetailed functional capabilities, each cate-gorised into one of these three types.Furthermore, it is shown that specificcapabilities may be apportioned across theother high-level architectural components,ie product systems and gateways. Theexact capabilities required and their appor-tionment are always uniquely dependenton the specific business and IT scenarioswithin the bank.

Process servicesPayment process services relate to the con-trol of processing for the completion ofinbound and outbound payments requests.A payments hub fulfils the role of the‘process services’ layer in SOA. It will typ-ically offer coarse-grained payments serv-ice, these being themselves composed ofseveral, finer-grained services provided bya SOA ‘business services’ layer. In this way,the systems processing necessary to realisethe value chain3 of a payment can beachieved.

Given its role in coordinating fine-grained business services, the hub is alsothe sub-system best placed to provide aview of the state of a payment as it pro-gresses through its value chain. The granu-larity of the services orchestrated in turndetermines the number of state transitionsdefined.

Business servicesA payments hub, potentially, gives visibil-ity of all payments into and out of a bank.On this basis, it is considered the systemcomponent that is best placed to providesome specialised business services. Theseinclude

• liquidity monitoring;• liquidity information provision;• scheme cap monitoring.

A payments hub can thus track debit andcredit payment value, and accumulate andmaintain a net settlement position againsteach of the schemes. Related to this, thepayments hub may also provide informa-tion services for enquiring on and report-ing the liquidity position.

There are several business benefits asso-ciated with undertaking such activities,and these are described below.

Integration servicesPayments processing requires significantintegration capability to connect thescheme gateways and the product systems.In this respect, a key role of the paymentshub is to receive all inbound and out-bound payments and perform:

• routing to and from the requisite prod-uct systems and gateways;

• transformation of the payments mes-sages into an appropriate format forprocessing by the schemes, product sys-tems and the bank’s business partners.

This infers a requirement to support allbank payments volumes. Similarly, owingto the critical nature of payments process-ing, non-functional characteristics of apayments hub are high reliability androbustness to systems failure.

Justification for payments hubsThis section provides the business andtechnical justification for the paymentshub architectural component. The justifi-cation is irrespective of any specific vendortechnology selection.

Support for core banking modernisationA common banking scenario is thereplacement of heritage product systems

The Payments Hub Spectrum

Page 54


with a new core banking engine. Thephasing out of the heritage product sys-tems and the phasing in of the new corebanking product system over a definedtimeline are illustrated in Table 1, for anexample modernisation programme.

A further common scenario is a mergerwith or acquisition of another financialservices organisation. This infers theinheritance of additional product systems(in the example shown, an additionalmortgage product system). Realisation ofa given bank’s business strategy may neces-sitate future mergers/acquisitions. Hence,providing an architectural capability tosupport efficiently the integration of moreproduct systems in the future is consideredgood practice.

From Table 1, it can be seen, even atthe end of the modernisation pro-gramme, that there is still a requirementto support multiple product systems. This

infers a long-term role for a paymentshub, rather than a transient role support-ing the duration of the modernisationprogramme only.

Payments integration complexityA payments hub solves the classic integra-tion problem of reducing the number ofpoint to point integrations required. Thecomplexity of the integration between theschemes (S) and the product systems (P) is awell-known S×P problem. Simplistically,introducing a payments hub, throughwhich all scheme and product system con-nections are made, reduces this to an S+Pproblem.

In practice, the scheme integrationcomplexity is lower, as not all schemesconnect to all product systems. Thisreduction, however, is partly offset, as theintegration complexity associated withcertain schemes is very high (eg UK Faster

Page 55

Farrow

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

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

Heritage Retail

Heritage Corporate

Heritage Insurance

Heritage Mortgages

Treasury

Heritage Credit Cards

New Retail

New Corporate

Acquired Mortgages

New Credit Cards


Payments) and duplication of integrationeffort is not desirable. Any large bank willtypically maintain multiple product sys-tems, and so there is a strong justificationfor a hub purely on the strength of itsintegration role alone.

Data management simplicityAnother benefit of the payments hub isthat it can reduce the complexities associ-ated with master data management of cer-tain reference data. Examples of referencedata include:

• Industry Sort Code Directory (ISCD).Thisconsists of a database of meta-dataabout all the bank/building societybranches and bank offices that partici-pate in one or more of the UK clearingsystems. These data are necessary to val-idate destinations for payments and todetermine the characteristics of the des-tination, such as the ability to support agiven scheme.

• Internal routing tables. These data equateto bank-specific information as towhich IT systems accounts are domi-ciled. This allows inbound payments tobe routed to the correct product systemand posting applied accordingly.

In the conceptual model presented, the

payments hub is the central point for rout-ing of payments. It may also have a similar,centralised role in validating inbound andoutbound payment messages. These capa-bilities require the reference data describedabove.

In this respect, adopting a payments hubarchitectural style allows for the referencedata required by these capabilities to bedeployed once only (or at least a signifi-cantly reduced number of times), greatlysimplifying the master data managementproblem.

Architectural simplicityArchitectural simplicity can potentially beachieved through commonality of pay-ments processing across payments schemes(Figure 2). Key to this is the manipulationof the payment in a common data format.In this respect, processing proceeds by firsttransforming the payment into a commondata representation. Once in this ‘canoni-cal form’, a common service can then beperformed on a payment, irrespective of itsscheme origin. While, overall processingsteps for a payment from a specific schememay be unique, this approach allows reuseof common processing steps acrossschemes.

Upon completion of this generic pro-cessing, the payment may then be trans-


6

Figure 2Commonality ofprocessing in aSOA processservices layer


Farrow

Table 2: Payments modernisation benefits and enabling capability of the paymentshub

Customer benefit Description How

Latest payment processing features

Consistency of service

Improved transparency

Customers can benefit fromimproved speed to market of futurepayments initiatives.

Customers (including bank backoffice) can benefit from a singleconsistent payments servicesupporting all schemes.The customer is shielded fromcomplexities of scheme simplifyingthe customer experience.

The completion of large financialtransactions by customers is veryimportant and can often lead tostressful situations. For example, acustomer may be making a majorpurchase and wish to know thattransfer of credit has completed.The provision of informationrelating to the status of theirpayment information can reassurecustomers that a payment has beenconcluded. This is of great benefit inreducing uncertainty and stress.

Changes to the heritage productsystems are made difficult by thelack of documented code and areconstrained by rigid release cycles.These factors lengthen the deliverycycle.By decoupling the product systemsfrom payments functionality, anychanges required for new paymentsinitiatives or for regulatorycompliance are less extensive.The use of specialised middleware inthe implementation of a paymentshub allows new message types andschemes to be introduced rapidly.

The payments hub leveragescommonality in paymentsprocessing. This enables consistencyin the way that payments data iscaptured in the channel, providing aunified and simpler customerexperience.Common payment processes andservices will be incorporated intopayments processing increasingconsistency of service. Eg:• data validation services;• payment submission service;• scheme independent Fraud

checking;• anti-money-laundering checks.

The payments hub has visibility ofpayments and monitors of the stateof a given payment.The payments hub can exposeservices to specific channels (CRM,e-banking) to support enquiries onthe state of a specific paymentrequest.The importance of particularsensitivities (such as quarantine ofpotentially fraudulent transactions) isrecognised. Such enquiries willtherefore be sensitive to the specificreasons for any delay to paymentsprocessing.


formed into a specific format suitable tothe target sub-system. A design objectiveof ‘develop once reuse many times’ isachieved, which can greatly simplify pay-ments processing.

Customer benefits

The benefits of a payments modernisationapproach provided by a hub are capturedin Table 2. The role of the payments hubin enabling the benefits is also described.


Page 58

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

Customer benefit Description How

Reliability of service

Internal customersMonitoring of liquidity position and risk exposure

Scheme cap monitoring

Reduced operational errors

Customers will benefit from a robustand reliable payments processingservice.Given growth in digital channels,payments services must operate on a24-hour basis, supporting paymentrequests outside nominal bankinghours.

Treasury can benefit from timelyand accurate information on thebank’s settlement position againsteach scheme.This allows the bank to monitorexposure against a particular schemeand pro-actively manage deferrednet settlement risk.

Payment operations benefit frombeing alerted to situations where thesettlement position is nearingscheme cap limits. In this way theyare able to closedown payments fora particular scheme in a controlledway. Payments are diverted toanother scheme, continuingcustomer service.This also prevents a bank fromexceeding the scheme cap limitswith associated disbenefits.

The bank’s internal paymentsoperation will benefit from reducederrors and higher straight-throughprocessing, improving efficiencywithin the operation.

The payments hub IT architectureshould:• operate continuously• not permit any loss of payments

instructions• not permit duplication of

payment messages across allpayments schemes

• provide validation of paymentinstructions to reduce thelikelihood of payments errors.

The payments hub is the singlecomponent that has visibility of allpayments into and out of the bank.It is therefore best placed todetermine the bank’s financialposition against a particular paymentscheme.

The payments hub may performscheme cap monitoring and is ableto provide information servicesrelating to the scheme positionrelative to the cap.

The payments hub promotescommonality and automation ofpayments processing. This simplifiespayments processing, in turnreducing operational errors,improving efficiency and overallservice quality.


Two categories of customer areobserved:

(i) Bank external customers: These are theretail and wholesale customers of thebank.

(ii) Internal customers: These are actorsinternal to the bank, for example, thepayments operations team and treas-ury.

THE PAYMENTS HUB SPECTRUM

Capability modelThe functionality required to undertakepayments processing is illustrated in acapability model. The model illustrates thepayment domain functions in a technol-ogy and vendor-neutral way.Subsequently, it is shown that there aremany options for apportioning capabilitiesbetween the key payments sub-systems(Figure 3).

The model distinguishes between therealised capabilities and capability facades— calls to external components. The latterare considered equally important, as theyrelate to a design decision as to the point ofcontrol where the underlying capability iscalled. For example, a complex underlyingcapability may be realised by an externalcomponent, but its services may be calledfrom either the payment hub or the prod-uct system. It is the placement of the call tothe capability that is significant in thedesign, and therefore the model reflectssuch service call placement considerations.

An overview of the capabilities in themodel is now provided.

Account Posting (facade)This capability represents the ability toupdate a product system account.Ultimately, the service must be providedby the product system itself. A key designissue is whether the posting service iscalled by the payment hub as an internal

Page 59

Farrow

Figure 3Payments capabilitymodel

Scheme LimitsManagement


service of the product system or indirectlythrough another component facade.

Account ValidationAccount Validation refers to the capabilityto validate the existence of accounts.Successful validation of the account mayprovide the type and status of the account.Failure to validate the account will typi-cally lead to the rejection of an inboundcredit and a return of the payment to thescheme.

AlmanacThe Almanac represents the collection ofmeta-data relevant to support the interac-tion of the bank with its payments schemeproviders.

The meta-data include, for example:

• scheme daily operating times;• scheme non-operating days;• public holidays.

Diary ManagementThe Diary Management capability isdependent on the Almanac. Given themeta-data defined in the Almanac, theDiary Management capability uses thesedata to determine specific diarised eventson a given day. For example, the scheduleof inbound and outbound payment filesexpected within the operational workingday. The schedule can be used in turn togenerate alerting mechanisms should, forexample, a file not arrive from the schemeor be ready to send to the scheme at thediarised time.

Fraud Service (facade)The Fraud Service is generally complex,fulfilling regulatory requirements relatingto fraud detection. This capability repre-sents the ability to call the Fraud Service.As with the Account Posting capabilityfacade, this represents a service call place-ment issue.

AML Service (facade)

The Anti-Money Laundering (AML)Service is also complex, fulfilling regula-tory requirements relating to anti-moneylaundering. This capability represents theability to call the AML Service. This is alsoa service call placement issue.

EnrichmentThis capability refers to the enhancementof the payment instruction with additionaldata to enable value-added services to beperformed by the bank. An example ofthis relates to collection accounts. TheEnrichment provides for the original col-lection account number to be propagatedwith the payment instruction to the targetproduct system. If there is subsequently anissue with the posting of the payment, theoriginal collection account number is stillavailable in the payment instruction foruse by the payment business operation inproblem analysis.

File ValidationThis capability refers to format validation,against an industry specification, ofinbound and outbound bulk paymentfiles, eg Bankers’ Automated ClearingServices (BACS) Standard 18 file valida-tion.

Funds Control (facade)Funds Control refers to the capability toassess the funds available to fulfil the pay-ment, resulting in a pay/no-pay decision.Funds Control checking must take intoaccount intra-day payment commitmentsand associated fund reservations on a cus-tomer’s account. In the case of a retail cus-tomer, this is generally a relatively simpleassessment. In the case of a corporate cus-tomer, this may become more complex,with Funds Control assessment taking intoaccount a net funds position determinedfrom several accounts and perhaps anagreed collateralised credit line.


Page 60


Intelligent Payments Routing

Intelligent Payments Routing refers to thecapability to select the most appropriatemethod of payment based on general, cus-tomer-defined characteristics of a pay-ment. Typical characteristics include costand speed.

Such selection may also take into consideration other factors such asscheme limits on settlement exposureagainst the scheme. If the scheme limitsare being approached, the IntelligentRouting capability may discount thatscheme from the selection process. Thisapproach is preferable to exceeding thescheme limits, which would result in theclosure of the scheme to payment sub-missions.

Liquidity MonitorThe Liquidity Monitor refers to the capa-bility to accumulate the bank’s settlementposition against the scheme. In the simplecase, this may be achieved through a sum-mation of inbound and outbound pay-ment value. More complex liquiditymonitoring may involve matching ofnotices (eg Society for WorldwideInterbank Financial Telecommunications(SWIFT) 210 matching).

Message ValidationThis capability refers to the format valida-tion of inbound and outbound paymentinstructions for message based paymentschemes, eg SWIFT messaging forClearing House Automated PaymentSystems (CHAPS) payments.

Mandate ManagementMandates refer to both standing ordermandates for outbound credits and directdebits mandates for outbound direct debitinstructions or inbound direct debit vali-dation. The Mandate Management capa-bility refers to the creation, maintenanceand execution of such mandates.

Payments Repository

The Payments Repository is provided toenable a store and forward paradigm. Anexample is the ability to store future-datedpayments until the scheduled paymentdate. An outbound payment is held untilthe future date is reached, when it subse-quently is released to a scheme. Paymentsshould be held in the preferred canonicaldata form until their validity date and thenconverted into the selected scheme-spe-cific format on creation of the paymentsinstrument.

RepairThe Repair capability refers to an abilityto repair payment instructions and henceimprove ‘straight-through processing’ rates.A repair may relate to simple formattingrepairs, eg the removal of white space inthe account number. It may also refer tomore advanced repairs, eg the lookup of adisused sort code/account number and itsmapping to a successor.

RoutingThis capability refers to simple paymentsrouting, which consists of two main activ-ities:

(i) destination determination;(ii) logical routing of the payment based

on the derived destination.

The Routing capability requires ISCDdata and also IBAN reference data(depending on schemes supported).

Scheme Limits ManagementLimits refer to the maximum allowablesize of the bank’s exposure to the scheme.Above the scheme limit, payments submit-ted to the scheme will be rejected.Exceeding the scheme limit may result ina loss of service for a customer — theywill no longer be able to use that schemeto fulfil their payments. It is desirable to

Page 61

Farrow


achieve a more graceful degradation ofservice as the scheme limit is approached.In this respect, the Limits Monitoringcapability enables this by totalling thebank’s exposure to the scheme. When thelimit is approached, within a certain toler-ance, this can trigger an alert to the bank’spayment operation.

State MachineThe State Machine is a technical capabilitywhich enables the status of a payment tobe specified as it progresses through itsvalue chain3 until certainty of fate is accom-plished. A State Machine is a well under-stood capability, but in this case it mustspecifically reflect the specialised eventsand states that occur in payments process-ing within the organisation.

TransformationTransformation refers to the capability totransform payment instructions from onedata representation to another. This capa-bility is essential for transforming scheme-specific formats into the organisations’preferred canonical data form.

The Payments Hub Spectrum definedThe Payments Hub Spectrum constitutes

the range of potential capabilities with thecapabilities ordered, loosely, by increasingfunctional richness. This is illustrated inFigure 4, showing the placement of thecapabilities from the model within thespectrum.

A hub design at each of the extremes ofthe spectrum will have significantly differ-ent characteristics. The factors affectingthe positioning of the hub design on thisspectrum are now discussed.

DESIGN ISSUESThis section discusses some key issues forconsideration in the design of a paymentshub. The issues identified are discussed interms of how they influence the position-ing of the hub on the defined spectrum.

Service granularityService granularity relates to the coarse-ness of the services orchestrated by thepayments hub in processing a payment.The following design characteristics areobserved:

• Service granularity becomes finergrained at the right-hand side of thehub spectrum shown in Figure 4. This


Page 62

Figure 4Payments HubSpectrum


side is termed the ‘high-frequency’ endof the spectrum, as a relatively highnumber of fine-grained service calls areexpected.

• Conversely, service granularity becomescoarser at the left-hand end of the spec-trum. This side is termed the ‘low-fre-quency’ end of the spectrum on thebasis of a lower number of coarse-grained service calls.

Consider a simple illustration. If the targetproduct system is rich in capability, thereare few services for the hub to coordinate.The interactions of the hub are few andare typified by a single coarse-grainedservice call to the product system — effec-tively a handoff of the payment for pro-cessing by the product system. The hubpositioning is therefore at the left-handside of the spectrum.

If the hub contains the capability tofulfil or orchestrate certain steps in thevalue chain, the product system is effec-tively tasked to perform much finer-grained services. For example, an inbounddebit requires that a Funds Control checkis performed. If the result of the checkindicates funds are available, the debit maythen be posted to the account. This sup-ports the premise of finer-grained servicestowards the right of the spectrum.

Certainty of fateCertainty of fate refers to knowledge ofthe outcome of a payment, ultimatelyidentifying the account to which the pay-ment was posted (or other outcome). Theextent to which certainty of fate is knownby the hub is determined by the servicegranularity.

Consider the principle that the pay-ments hub is the single system with fullvisibility of the payment processing states.This is perhaps a desirable goal, but maynot be achievable, and a factor affectingthis is the service granularity. If a hub

model towards the left of the spectrum isadopted, a coarse-grained service model isinferred. Visibility to the hub of the inter-nal payments processing steps by the prod-uct system is not likely, and knowledge ofcertainty of fate therefore lies with theproduct system.

In a model towards the right-hand endof the spectrum, finer-grained services areprevalent, and full visibility of the process-ing steps is more likely. Knowledge of cer-tainty of fate within the payments hub istherefore more achievable in this hubmodel.

Technology selectionFigure 5 shows the mapping of portions ofthe hub spectrum to the suggested optimaltechnology selections. For each spectrumportion, the characteristic features of thetechnology are highlighted and the advan-tages and disadvantages of its selection.Some example technologies are givenwithin each defined portion, but this isillustrative and not exhaustive.

Low-end segmentThe low end of the spectrum is consideredwell suited to pure middleware technologyimplementations. Functional processingby the hub is simple or lightweight, asbusiness services are provided by the prod-uct systems (or other components). Inthese circumstances, there is little or nobusiness functionality to build, or it is con-sidered practical to build the functionalityof the simpler business services in the basemiddleware technology, perhaps supple-mented by a procedural programming lan-guage.

Mid segmentIn the middle segment, functionality isricher. A pure middleware solution in thisportion of the spectrum may require sig-nificant enhancements to base functionalcapability. Given the richer functionality

Page 63

Farrow


specified in this portion of the spectrum, itis considered less cost effective to providethis via custom build. It is more effectiveto start from a position of some base func-tionality. A payments framework technol-ogy solution therefore becomes more costefficient in this portion of the spectrum.For example, the framework technologymay already be provided with an ‘out ofthe box’ State Machine capability and withpre-built transformations for somescheme-specific formats.

High-end segmentIn the high end of the spectrum, func-tional capability is richer still and broaderin scope, containing all process, businessand integration capabilities. The scale ofthe customisation, even for a frameworksolution, may make this particular technol-ogy selection less cost effective than forthe mid portion of the spectrum. A fullpayments engine package solution mayoffer:

• a richer set of pre-configured transfor-mations;

• ‘out of the box’ advanced components,such as a Liquidity Monitor;

• pre-build processing flows for specificpayment instruments.

For these reasons, a full package solutionmay become more cost effective at thisend of the spectrum.

Canonical data zoneIndustry-standard formats are important,as they are required by a scheme to sup-port routing of payments between banks.A selection of relevant industry standardsused within payments processing is shownin Table 3.

A significant issue in the design of pay-ments processing systems is considered tobe the selection of the data standards forthe representation of the payments instru-ments, as they progress through processingstages in the various system components.


Page 64

Figure 5Technologymapping of the hubthrough thespectrum

Middleware Framework Engine

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

Grey box component

Advantages Low technology cost Standard based, Low implementation cost if Relative low cost Modular implementation

‘out of the box’

Disadvantages Building enhanced functions Customisation can still be Customisation cycle slowis costly extensive Black box component

High product cost

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


An obvious design approach would beto select one or more of the industry stan-dards as the internal canonical data stan-dard. Bank-specific business processes andthe practicalities of the actual systems real-isation, however, typically dictate thatadditional meta-data are required. Forexample:

• Head Office Collection Accounts(HOCA) processing — mapping ofcollection accounts to actual currentaccounts. It is necessary to retain theoriginal HOCA sort code such thatexceptions relating to subsequent pro-cessing can be handled manually.Payment operations personnel mayneed the original account data as acontext to process the exception man-ually.

• Addition of technical meta-data isoften required: for example, pertainingto the destination system, sequencenumbering or prioritisation of the pay-ments instruction to inform the mid-dleware of how technically to route thepayment.

The use of a canonical data form is criticalto achieving commonality of the process-ing of payments and realise the advantagesof architectural simplicity outlined earlier.

Other considerations of note are:

• BACS Standard18 to move to SEPAcompliance and, by implication,ISO20022 data standards by 2014.

• Additional meta-data are generallyrequired to enhance the original mes-sage received from a gateway.

In summary, there are technical and busi-ness reasons why a de jure payments stan-dard is not appropriate as the choice ofcanonical data for use within a bank’s pay-ments systems. In practice, an extendedversion of a de jure standard is consideredappropriate, this being unique to eachbank.

Service placement issues

Account servicingThe centralisation of payments capabilitieswithin the hub and the associated use of acanonical data model create opportunitiesto improve broader customer accountservicing and internal operational activi-ties.

One potential area of benefit isEnquiries and Investigations. This opera-tional area within the bank is typicallycharacterised by multiple enquiry systems,specific to a given scheme. This makesoperational management overly complex,inefficient and unreliable.

Storing payments events in a hub‘operational data store’ enables a single,centralised view of the state of all pay-ments within the operation. Employing acanonical data model in the operationaldata store means these services can beused trans-scheme. These factors in turnallow unified, streamlined, services to be

Page 65

Farrow

Table 3: Sample data standards in payments processing

Data standard Description Type Classification

SWIFT Standard for SWIFT Fin payments processing Closed De factoUNIFI (ISO20022) Standard for non-realtime payments Open De JureISO8583 Standard for near-realtime payment instructions Open De JureAPACS Standard 18 Standard for BACS processing Closed De facto


built to support customer enquiries andoperational investigations, improving thequality and timeliness of the investiga-tions.

Account portabilityAccount portability is the requirement forcustomers to be able to retain theiraccount numbers when switching banks.Account portability requires that a stan-dard format is used for the accountnumber, this being eight digits in the UK.Currently, not all UK banks conform tothis standard.

In heritage systems, the accountnumber itself is quite often used as thedatabase key in the product systems. Abetter design approach in general is to notuse the business data as the database key.Thus, to aid portability, one must treat theaccount number as a data attribute and usea separate artificial key to identify theaccount uniquely.

For those UK banks that use a non-standard account number in the productsystems, to conform to future accountportability requirements, a mapping fromstandard account number to the heritageformat must be provided. This mappingcan be provided by the payments hub.

Similarly, even for standard accountnumber formats, there may be benefit inidentifying the customer key in advance ofthe payment hitting the products systemor other components. Again, the hub iscapable of providing this capability.Alternatively, this capability may be pro-vided by an external component with thehub the central point of control of thelookup (as per the facade pattern previ-ously discussed).

Payments originationPayments origination refers to the capabil-ity to initiate payment instructions fromthe payment hub. Two scenarios are antic-ipated:

(i) The hub receives an instruction tocreate a payment from a channelsystem. For example, a customer via aself-service channel makes a request toinitiate a payment. The hub then startsthe processing to fulfil that request,controlling the services necessary toauthorise the payment (eg FundsControl check), create the paymentinstrument and send to the appropri-ate gateway.

(ii) The hub enquires on the mandatedatabase or receives notifications fromthe mandate database that a payment isto be made. Again, the hub starts theprocess controlling the services thatultimately result in a payment instruc-tion (eg for an outbound credit) beingcreated and sent to the payments gate-way.

The key design consideration in both thesescenarios is that the hub is the componentthat first receives the trigger to initiate thecreation of the payment instrument. Thehub then orchestrates the activities neces-sary to fulfil the creation of the instrument,notifying the initiating channel if a failurein a processing step occurs.

The design alternative for scenario (i)above is that the channel componentinterfaces directly with the productsystem, which performs the Funds Controlcheck as an internal function and creates aformatted payment instrument.

The design alternatives for (ii) are that:

• A separate Mandate Management com-ponent interprets the daily paymentschedule and creates all the paymentsinstructions; this scenario is typical tomany heritage systems.

• Mandate Management is a sub-compo-nent of the product system and thedaily payments schedule is created bythe product system; this scenario appli-cable to modern package solutions.


Page 66


These design alternatives infer a hubdesign that is towards the low-frequencyend of the spectrum; while the formerinfers a hub that fits the mid-/high-options-frequency end of the spectrum.

AML/Fraud CheckGiven its visibility of inbound and out-bound payments, the hub is potentially apoint of control of a number of regulatoryand compliance driven services. Fraud,anti-money laundering and FinancialAction Task Force (FATF) checks on thepayments are such services, and these canall be initiated from the hub.

Furthermore, given its State Machinecapability, the hub already has the ability toprovide the state management of a pay-ment arising as a consequence of thefraud, AML or FATF checks. A paymentcan be held in the hub PaymentsRepository pending resolution of investi-gation of a condition flagged by the fraud,AML or FATF services. Once investiga-tion is complete, a release of the paymentcan be triggered by the Fraud/AMLService.

Traversing the spectrumFigure 6 illustrates the tension arisingwithin a payments hub delivery due to

differing perspectives of the delivery part-ners. Three delivery partners are assumed— the bank, the product vendor and a sys-tems integrator responsible for the deliv-ery of the overall solution. The bank’sperspective is a desire to reduce cost andachieve the business objectives: for exam-ple, reduced time to market. The productvendor perspective is a desire to achievesales of modules, services development andlocal region enhancements to the baseproduct. The system integrator perspectiveis a desire to achieve deliverability of thesolution at low risk.

These perspectives each drive the place-ment of the hub on the spectrum in dif-ferent directions, creating an architecturaltension in the solution. Agreeing the pre-cise capabilities and placement of the hubis a non-trivial task.

A decision to move to a different oper-ating point on the spectrum can result inproduct/supplier reselection. Further -more, the governance of the solution mayhave to be revisited if major architecturaldecisions are changed. Finally, complianceand risk checks may also need to be reval-idated.

All these factors make a decision onpositioning within the spectrum a difficultand time-consuming exercise.

Page 67

Farrow

Systemsintegrator

Bank Productvendor

Figure 6Architecturaltension betweenpayment hubstakeholders


CASE STUDIES

UK clearing bank

ContextThis case study relates to a UK clearingbank undertaking a core product systemreplacement programme. The bulk of thebank’s products were supported through aheritage system with the typical associatedconstraints, simplistically:

• unresponsiveness to market changes inthe marketing environment due to con-strained life cycle and deployment win-dows;

• ‘knowledge monopoly’ by an out-sourced supplier managing the heritage

application, further limiting ability todeliver timely changes.

The timing of the programme was soonafter the financial liquidity crisis (the‘credit crunch’). Consequently, there was aheightened sense of concern relating tothe risk exposure of the bank. This wasfurther amplified because a large portionof its payments business was with agencybanks. In this respect, the bank wasmaking payments on behalf of many otherbanks, but only settling with them sometime after the daily settlement cycle withthe Bank of England.

Within the lifetime of the core productreplacement programme, the bank alsounderwent a merger with another finan-


Page 68

Figure 7 UKclearing bankpayments hubarchitectureoverview


cial institution. This further emphasisedthe need to facilitate payments to multipleproduct systems in the short to mediumterm, irrespective of the target productsystem landscape.

Design driversA payments hub was conceived as a solu-tion to the payments processing require-ments. An overview of the systemarchitecture, highlighting the scale of theintegration required and the key role ofthe hub, is shown in Figure 7.

Key design drivers were to support thephased rollout of the new package-basedproduct engine as described above, specif-ically:

• to support the limited payment schemesneeded by the savings products initially,namely credit transfers, and then transi-tioning to a richer set of schemes tosupport current accounts, includingcheque clearing and debit card schemes;

• to support the actual migration, switch-ing user payments from the heritageproduct system to the new one trig-gered by a scheduled migration date;

• that the ‘package principle’ was appliedto ensure that the features of the newcore banking platform were leveraged.

The package provided capability atgeneric automated clearing house (ACH),

country-specific and bank-specific levels.The core capability and the country-spe-cific capability were inclusive in thelicensed cost. This implied a commercialdriver to use the ‘out of the box’ packagefeatures available so as to minimise devel-opment costs associated with customisa-tion. For the core product servicingcapabilities provided by the package, therewas no contention with the capabilitymodel defined. Some of the capabilities inthe model, however, were available in thepackage, and the placement of that capa-bility in the payments hub or in the prod-uct engine was a major source ofarchitectural tension in the solution.

Hub solutionThe resulting overall payments hub designwas weighted towards the right of thespectrum with the selected capabilitiesshown in Figure 8.

From a functional perspective, the com-mercial considerations dictated that thepayments hub should not duplicate thecapabilities already provided by the pack-age. This consideration tended to limit thefunctional richness of the payments hub,positioning the overall hub design to thelower end of the spectrum. From a ‘designpurity’ perspective, however, certain capa-bilities were considered to be better placedin the payments hub, tending to increasethe functional richness and positioning the

Page 69

Farrow

Figure 8 UKclearing bank hubspectrumplacement


overall hub design towards the high end ofthe spectrum.

The ‘package principle’ also inferredthat the payments hub should support theinterfaces offered by the package, present-ing the payments in a format expected bythe package, the objective again being tominimise costs associated with any inter-face customisation. In this respect, thenumber of data transformations that ariseas a consequence of the interface selectionshould be noted (Scheme to Canonical toPackage).

Given the concern over settlement risk,a component to monitor exposure to eachof the payments schemes was a key func-tional requirement. The LiquidityMonitor capability was therefore includedas an advanced feature of the hub.

Foreign currency order hub

ContextThe acquisition of a major bank createdthe need to integrate two businesses andtheir respective IT systems. To fulfil this

activity, an Integration Programme wasconceived. The Foreign CurrencyProgramme was part of this overallIntegration Programme.

Post integration, the merged bankinggroup required a single service offering inthe area of foreign currency ordering andfulfilment, specifically:

• the sale of foreign currency and trav-ellers’ cheques;

• the purchase of foreign currency.

Foreign currency services were to beoffered through the multiple channels,harmonised as part of the IntegrationProgramme. Fulfilment of foreign cur-rency orders was provided by a third-party business partner of the acquiredbank.

An order hub, depicted in Figure 9, wasintroduced to provide the integrated solu-tion.

Design driversKey design drivers were:


Page 70

Figure 9 Foreigncurrency order hubarchitectureoverview


• Impacts on channels systems were timeconsuming, and it was desirable to keepthese to a minimum. The interface for-mats to and from the channels weretherefore to be preserved.

• Foreign currency fulfilment was to beoutsourced to a third party. Thisinferred a ‘pseudo scheme’ with specificoperating characteristics and a definedinterface for the orders.

• The order capture and fulfilment sys-tems were all file based.

The foreign currency orders are analogousto payments instruments. Consequently,the design considerations are identical tothose described for a payments hub.

Hub solutionThe resulting hub design was weightedtowards the left of the spectrum with theselected capabilities shown in Figure 10.

Transformation of order formats wasessential to covert multiple order formatsinto a single format required by the fulfil-ment partner. Routing was not strictly arequired capability, although there was afan-out capability for the FX rate distribu-tion following a simple publish/subscribermodel. File Validation of the order fileswas undertaken, and there was a store andforward capability and a very simple StateMachine implementation. More advancedfeatures included limits management onthe order values to ensure that deliveryvalue restrictions were adhered to.

CONCLUSIONThere are a number of business scenariosin which a payments hub is shown to haverelevance. Specifically, a payments hub hasbeen shown to be useful in supporting:

• core banking modernisation initiatives,the key driver here being to support themigration of existing customer accountsto a new core banking engine;

• business acquisitions or mergers, the keydriver here being to support the multi-ple products systems arising in themerged it operation.

Given an organisational IT strategy of asmall, unchanging number of consolidatedproduct systems, it could be argued that apayments hub has a temporary role, usedonly while account migrations are inflight. In practice, in any large bankingorganisation, the dynamics of the businessenvironment mean that the IT landscape iscontinually changing through acquisitions,mergers and de-mergers, necessitating along-term role for the payments hub.

There are other business drivers thatsupport the long-term need for a pay-ments hub, these being regulatory, compli-ance and the competitive nature of thebusiness environment. Given these busi-ness drivers, a number of functional issuesin the design of payment hubs have beenidentified.

In this respect, a capability model forpayments processing has been developed

Page 71

Farrow

Figure 10 Foreigncurrency order hubspectrumplacement

FX orderhub

• Routing• Transformation

• File validation• Repair• Enrichment

• paymentsrepository

• State machine

• Scheme limitsmanagement


and described. The apportionment ofthese capabilities between gateways, pay-ments hubs and product systems can takemany different forms, dependent on theunderlying business drivers and thespecifics of the IT landscape within thebank. In the case studies discussed, itbecame apparent that this apportionmentwas a fundamental design consideration.This led to the concept of the ‘PaymentsHub Spectrum’ as a vehicle for the analy-sis of a solution.

At the low-frequency end of thePayments Hub Spectrum, the hub has thecharacteristics of a pure middleware solu-tion. As the spectrum is traversed, morefunctionality is added to the payments hubuntil, at the high end of the spectrum, thehub constitutes a fully functional paymentsengine.

To conform fully to the concept of aspectrum, one may expect a quantifiable,linear attribute of the payments hub to beincreasing/decreasing as the spectrum istraversed. The attribute presented here isthe functional richness of the hub.

In practice, the functionality of the hubis not a strictly linear attribute or evennecessarily cumulative. Capabilitiestowards the high end of the spectrum maybe included, but this does not necessarilyinfer the inclusion of some mid-spectrumcapabilities. Despite this, the model is con-sidered valid in broad terms and a usefulvehicle for considering the general style of

hub that an organisation requires.Major changes to the underlying archi-

tecture for payments processing are diffi-cult, infer prescribed, minimum timescalesand present high business risk for thebank. In this respect, the technology selec-tion for a payments hub is an early deci-sion which underpins the IT architectureand is important to get right at the outset.In conclusion, understanding the requiredoperating position on the Payments HubSpectrum allows an organisation to makean explicit, informed choice about thefoundation technology for the hub, avoid-ing costly re-architecting and minimisingdelivery risk for a bank.

ACKNOWLEDGEMENTS

Thanks are due to John Cameron, Paul Grayand Keith Johnson in shaping early ideas andconcepts for the payments hub. Thanks also toGreg Brougham for reviewing the paper andproviding much thoughtful feedback.

REFERENCES

(1) European Payments Council (2010)‘White Paper: Mobile Payments’, 1stedn, European Payments Council,Brussels.

(2) Farrow, G. S. D. (2009) ‘SOAanti-patterns: When the SOA paradigmbreaks’, IBM developerWorks, June.

(3) Porter, M. E. (2004) ‘CompetitiveAdvantage’, ISBN 0-7432-6087-2, FreePress, New York, pp. 33–60.


Page 72


the payments hub spectrum: a model for the design of ... payment hub spectrum.pdfpage 57 farrow...

Documents