The Payments Hub Spectrum

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

2. Farrow:JSC page.qxd 05/04/2011 17:19 Page 53 Farrow Figure 1 Payments high-level Business partners system overview Agency Other banks schemes Payment hub Product systems payments hub at a conceptual level. Sub- received from and sent to the schemes and systems that interact with a payments hub business partners in a variety of industry are: formats. • Product systems: these systems domicile Capabilities the banking ledgers that are the source Consider a service-oriented architecture and destination for payments. (SOA) perspective applied to payments • Channel systems: these systems support processing. Using a simple layered refer- the customer channels through which ence model for SOA,2 a payments hub can payment services are offered. These typ- be considered to provide three major cat- ically include: branch; Internet; and egories of service capability: telephony. In the future, it is expected that new channels such as mobile pay- (i) process services; ments, will be introduced.1 (ii) business services; • Payment gateways: these constitute the (iii) integration services. gateways to the various payment schemes. The combination of these different service types infers that a payments hub is a com- Electronic payment instruments are plex, ‘compound’ component spanning Page 53

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

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

5. Farrow:JSC page.qxd 05/04/2011 17:19 Page 56 The Payments Hub Spectrum Figure 2 Commonality of processing in a SOA process services layer Payments) and duplication of integration payments hub is the central point for rout- effort is not desirable. Any large bank will ing of payments. It may also have a similar, typically maintain multiple product sys- centralised role in validating inbound and tems, and so there is a strong justification outbound payment messages. These capa- for a hub purely on the strength of its bilities require the reference data described integration role alone. above. In this respect, adopting a payments hub Data management simplicity architectural style allows for the reference Another benefit of the payments hub is data required by these capabilities to be that it can reduce the complexities associ- deployed once only (or at least a signifi- ated with master data management of cer- cantly reduced number of times), greatly tain reference data. Examples of reference simplifying the master data management data include: problem. • Industry Sort Code Directory (ISCD). This Architectural simplicity consists of a database of meta-data Architectural simplicity can potentially be about all the bank/building society achieved through commonality of pay- branches and bank offices that partici- ments processing across payments schemes pate in one or more of the UK clearing (Figure 2). Key to this is the manipulation systems. These data are necessary to val- of the payment in a common data format. idate destinations for payments and to In this respect, processing proceeds by first determine the characteristics of the des- transforming the payment into a common tination, such as the ability to support a data representation. Once in this ‘canoni- given scheme. cal form’, a common service can then be • Internal routing tables. These data equate performed on a payment, irrespective of its to bank-specific information as to scheme origin. While, overall processing which IT systems accounts are domi- steps for a payment from a specific scheme ciled. This allows inbound payments to may be unique, this approach allows reuse be routed to the correct product system of common processing steps across and posting applied accordingly. schemes. Upon completion of this generic pro- In the conceptual model presented, the cessing, the payment may then be trans- Page 56

6. Farrow:JSC page.qxd 05/04/2011 17:19 Page 57 Farrow Table 2: Payments modernisation benefits and enabling capability of the payments hub Customer benefit Description How Latest payment Customers can benefit from Changes to the heritage product processing features improved speed to market of future systems are made difficult by the payments initiatives. lack of documented code and are constrained by rigid release cycles. These factors lengthen the delivery cycle. By decoupling the product systems from payments functionality, any changes required for new payments initiatives or for regulatory compliance are less extensive. The use of specialised middleware in the implementation of a payments hub allows new message types and schemes to be introduced rapidly. Consistency of service Customers (including bank back The payments hub leverages office) can benefit from a single commonality in payments consistent payments service processing. This enables consistency supporting all schemes. in the way that payments data is The customer is shielded from captured in the channel, providing a complexities of scheme simplifying unified and simpler customer the customer experience. experience. Common payment processes and services will be incorporated into payments processing increasing consistency of service. Eg: • data validation services; • payment submission service; • scheme independent Fraud checking; • anti-money-laundering checks. Improved transparency The completion of large financial The payments hub has visibility of transactions by customers is very payments and monitors of the state important and can often lead to of a given payment. stressful situations. For example, a The payments hub can expose customer may be making a major services to specific channels (CRM, purchase and wish to know that e-banking) to support enquiries on transfer of credit has completed. the state of a specific payment The provision of information request. relating to the status of their The importance of particular payment information can reassure sensitivities (such as quarantine of customers that a payment has been potentially fraudulent transactions) is concluded. This is of great benefit in recognised. Such enquiries will reducing uncertainty and stress. therefore be sensitive to the specific reasons for any delay to payments processing. Page 57

7. Farrow:JSC page.qxd 05/04/2011 17:19 Page 58 The Payments Hub Spectrum Table 2: Payments modernisation benefits and enabling capability of the payments hub (continued) Customer benefit Description How Reliability of service Customers will benefit from a robust The payments hub IT architecture and reliable payments processing should: service. • operate continuously Given growth in digital channels, • not permit any loss of payments payments services must operate on a instructions 24-hour basis, supporting payment • not permit duplication of requests outside nominal banking payment messages across all hours. payments schemes • provide validation of payment instructions to reduce the likelihood of payments errors. Internal customers Monitoring of liquidity Treasury can benefit from timely The payments hub is the single position and risk exposure and accurate information on the component that has visibility of all bank’s settlement position against payments into and out of the bank. each scheme. It is therefore best placed to This allows the bank to monitor determine the bank’s financial exposure against a particular scheme position against a particular payment and pro-actively manage deferred scheme. net settlement risk. Scheme cap monitoring Payment operations benefit from The payments hub may perform being alerted to situations where the scheme cap monitoring and is able settlement position is nearing to provide information services scheme cap limits. In this way they relating to the scheme position are able to closedown payments for relative to the cap. a particular scheme in a controlled way. Payments are diverted to another scheme, continuing customer service. This also prevents a bank from exceeding the scheme cap limits with associated disbenefits. Reduced operational errors The bank’s internal payments The payments hub promotes operation will benefit from reduced commonality and automation of errors and higher straight-through payments processing. This simplifies processing, improving efficiency payments processing, in turn within the operation. reducing operational errors, improving efficiency and overall service quality. formed into a specific format suitable to Customer benefits the target sub-system. A design objective The benefits of a payments modernisation of ‘develop once reuse many times’ is approach provided by a hub are captured achieved, which can greatly simplify pay- in Table 2. The role of the payments hub ments processing. in enabling the benefits is also described. Page 58

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

9. Farrow:JSC page.qxd 05/04/2011 17:19 Page 60 The Payments Hub Spectrum service of the product system or indirectly AML Service (facade) through another component facade. The Anti-Money Laundering (AML) Service is also complex, fulfilling regula- Account Validation tory requirements relating to anti-money Account Validation refers to the capability laundering. This capability represents the to validate the existence of accounts. ability to call the AML Service. This is also Successful validation of the account may a service call placement issue. provide the type and status of the account. Failure to validate the account will typi- Enrichment cally lead to the rejection of an inbound This capability refers to the enhancement credit and a return of the payment to the of the payment instruction with additional scheme. data to enable value-added services to be performed by the bank. An example of Almanac this relates to collection accounts. The The Almanac represents the collection of Enrichment provides for the original col- meta-data relevant to support the interac- lection account number to be propagated tion of the bank with its payments scheme with the payment instruction to the target providers. product system. If there is subsequently an The meta-data include, for example: issue with the posting of the payment, the original collection account number is still • scheme daily operating times; available in the payment instruction for • scheme non-operating days; use by the payment business operation in • public holidays. problem analysis. Diary Management File Validation The Diary Management capability is This capability refers to format validation, dependent on the Almanac. Given the against an industry specification, of meta-data defined in the Almanac, the inbound and outbound bulk payment Diary Management capability uses these files, eg Bankers’ Automated Clearing data to determine specific diarised events Services (BACS) Standard 18 file valida- on a given day. For example, the schedule tion. of inbound and outbound payment files expected within the operational working Funds Control (facade) day. The schedule can be used in turn to Funds Control refers to the capability to generate alerting mechanisms should, for assess the funds available to fulfil the pay- example, a file not arrive from the scheme ment, resulting in a pay/no-pay decision. or be ready to send to the scheme at the Funds Control checking must take into diarised time. account intra-day payment commitments and associated fund reservations on a cus- Fraud Service (facade) tomer’s account. In the case of a retail cus- The Fraud Service is generally complex, tomer, this is generally a relatively simple fulfilling regulatory requirements relating assessment. In the case of a corporate cus- to fraud detection. This capability repre- tomer, this may become more complex, sents the ability to call the Fraud Service. with Funds Control assessment taking into As with the Account Posting capability account a net funds position determined facade, this represents a service call place- from several accounts and perhaps an ment issue. agreed collateralised credit line. Page 60

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

11. Farrow:JSC page.qxd 05/04/2011 17:19 Page 62 The Payments Hub Spectrum Figure 4 Payments Hub Spectrum achieve a more graceful degradation of the range of potential capabilities with the service as the scheme limit is approached. capabilities ordered, loosely, by increasing In this respect, the Limits Monitoring functional richness. This is illustrated in capability enables this by totalling the Figure 4, showing the placement of the bank’s exposure to the scheme. When the capabilities from the model within the limit is approached, within a certain toler- spectrum. ance, this can trigger an alert to the bank’s A hub design at each of the extremes of payment operation. the spectrum will have significantly different characteristics. The factors affecting State Machine the positioning of the hub design on this The State Machine is a technical capability spectrum are now discussed. which enables the status of a payment to be specified as it progresses through its value chain3 until certainty of fate is accom- DESIGN ISSUES plished. A State Machine is a well under- This section discusses some key issues for stood capability, but in this case it must consideration in the design of a payments specifically reflect the specialised events hub. The issues identified are discussed in and states that occur in payments process- terms of how they influence the positioning within the organisation. ing of the hub on the defined spectrum. Transformation Service granularity Transformation refers to the capability to Service granularity relates to the coarse- transform payment instructions from one ness of the services orchestrated by the data representation to another. This capa- payments hub in processing a payment. bility is essential for transforming scheme- The following design characteristics are specific formats into the organisations’ observed: preferred canonical data form. • Service granularity becomes finer The Payments Hub Spectrum defined grained at the right-hand side of the The Payments Hub Spectrum constitutes hub spectrum shown in Figure 4. This Page 62

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

13. Farrow:JSC page.qxd 05/04/2011 17:19 Page 64 The Payments Hub Spectrum Figure 5 Technology mapping of the hub through the spectrum Middleware Framework Engine Features Pure middleware product Pre-build sub-flows, Pre-built scheme level supporting messaging/ Payments Repository, processing transformation Scheme transformations, Black box component, Stateless Stateless/full Stateless/full Grey box component Advantages Low technology cost Standard based, Low implementation cost if Relative low cost Modular implementation ‘out of the box’ Disadvantages Building enhanced functions Customisation can still be Customisation cycle slow is costly extensive Black box component High product cost Examples IBM MQ/Message Broker, IBM Enterprise Payments Oracle (BEA Weblogic) Platform, Clear2Pay, Dovetail Fundtech GPP specified in this portion of the spectrum, it • a richer set of pre-configured transfor- is considered less cost effective to provide mations; this via custom build. It is more effective • ‘out of the box’ advanced components, to start from a position of some base func- such as a Liquidity Monitor; tionality. A payments framework technol- • pre-build processing flows for specific ogy solution therefore becomes more cost payment instruments. efficient in this portion of the spectrum. For example, the framework technology For these reasons, a full package solution may already be provided with an ‘out of may become more cost effective at this the box’ State Machine capability and with end of the spectrum. pre-built transformations for some scheme-specific formats. Canonical data zone Industry-standard formats are important, High-end segment as they are required by a scheme to sup- In the high end of the spectrum, func- port routing of payments between banks. tional capability is richer still and broader A selection of relevant industry standards in scope, containing all process, business used within payments processing is shown and integration capabilities. The scale of in Table 3. the customisation, even for a framework A significant issue in the design of pay- solution, may make this particular technol- ments processing systems is considered to ogy selection less cost effective than for be the selection of the data standards for the mid portion of the spectrum. A full the representation of the payments instru- payments engine package solution may ments, as they progress through processing offer: stages in the various system components. Page 64

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

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

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

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

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

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

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

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