Patterns for Payment Systems Integration

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

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

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

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

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

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

7. Farrow:JSC page.qxd 30/04/2012 13:49 Page 21 Farrow Table 1: Payments Integration Space Complexity Table Channel Payment Gateway Product System Payment Engine Channel – – m-m m-m Payment Gateway – – m-m 1-1 Product System m-m m-m m-m m-m Payment Engine m-m 1-1 m-m – Table 2: Pattern attribute descriptions Attribute Description Integration Capability Defines whether the component has integration capability Business Capability Defines whether the component incorporates functionality from one or more of the business capabilities Process Capability Defines the extent of the process orchestration capability State Management Defines the extent of the state management of the component Connection Style Defines the connection style in terms of how and when the component is invoked components are illustrated. A summary of Product Systems themselves are assumed the characteristics of the integration to be tightly coupled and are shown component in the given pattern context together, effectively acting as one entity. is also provided. These characteristics are Thus the pattern does not address the qualified as a set of attributes, shown in integration problem between the Payment Table 2. Engine and Product System components. For each pattern, scenarios where the In general there are three categories of pattern is considered useful are described. functional capability that may be per- Finally, using the Payments Processing formed by pattern component: Spectrum, the apportionment of functionality to the components in each pattern is (i) Integration Services; illustrated. This provides a convenient (ii) Business Services; visual perspective to compare the patterns. (iii) Process Services. Payment Engine Routing Utility The sole function of the Payment Engine Routing Utility is to interface to the Overview Gateway and route payment instructions This pattern represents a solution for inte- to and from the Payment Engines. Thus, of grating a single Payment Gateway into the three categories, the Payment Engine multiple payment engines or Product Routing Utility provides only Integration Systems. Services. The combination of the Payment The Payment Gateway is connected to Engine and the Product Systems provide a single Payment Engine Routing Utility the rest of the payments processing capa- (Figure 4). This, in turn, is connected to bility. two or more Payment Engines/Product The Payment Engine Routing Utility Systems. The Payment Engines and does not manage any business state. It may, Page 21

8. Farrow:JSC page.qxd 30/04/2012 13:49 Page 22 Patterns for payments systems integration Figure 4 Payment tion from legacy engine to new engine Engine Routing cannot be achieved in one ‘big bang’ and a Utility pattern phased approach is adopted, requiring old and new payment engine instances to be concurrently live. As a specific example of this pattern, a global commercial bank intended to replace its legacy Payment Engine for CHAPS processing with a new product solution, this being Fundtech Global PAYplus. A Routing Utility was introduced to switch payments to one or other of the Payment Engines. This approach de-risked the solution implementation, allowing for a gradual migration of customers to the new Payment Engine. Similarly it has use in supporting a banking integration. In this situation, a payments scheme Gateway may be consolidated down to one of the original banks’ Gateway components. Underlying internal systems processing in the short term may be untouched, requiring routing from the consolidated Gateway to each of the original banks’ respective payment engines. however, manage technical state relating to Summary interactions with the Gateway. Spectrum Apportionment Payment Engine Routing Utility The Payment Engine Routing Utility construct provides pure middleware serv- Attribute Value ices and is shown in Figure 5 occupying Integration Capability Yes the left-hand side of the Spectrum. Business Capability No Capabilities from the Spectrum utilised Process Capability No in this pattern include: State Management No business state, but potential technical transaction state • Routing, to achieve the Payment Engine Connection Style Single Pass selection; • Transformation, to transform from scheme to respective formats required Product System Routing Utility by each of the Payment Engines; • Validation of inbound messages received Overview from the scheme. This pattern (Figure 6) represents a solu- Scenarios tion to integrate a single Payment Engine This pattern is useful when introducing a to multiple Product Systems. new Payment Engine. Typically the migra- The Payment Gateway is connected to Page 22

9. Farrow:JSC page.qxd 30/04/2012 13:49 Page 23 Farrow Figure 5 Payment Engine Routing Utility Spectrum Apportionment a single Payment Engine, dedicated to a • Validation of outbound messages and specific scheme. The pattern assumes that bulk payment files received from the customer accounts are domiciled across Product Systems multiple Product Systems. Commonality of processing for all payments relating to Scenarios one scheme is achieved, but there is an This pattern is useful in the scenario relat- integration problem to route payments to ing to the introduction of a new payment multiple Product Systems that the scheme. In such circumstances, a new Routing Utility resolves. Payment Gateway is assumed. The sce- As per the Payment Engine Routing nario then further assumes that a new Utility, the Product System Routing Payment Engine is introduced, dedicated Utility provides only Integration Services. to the new scheme. The Routing Utility The combination of the Payment Engine and the Product Systems provide the rest Figure 6 Product of the payments processing capability. System Routing The Product System Routing Utility Utility Pattern component also does not manage any business state. It may, however, manage technical state relating to interaction with the Product Systems; for example, technical retries and the batching of requests for offline Product Systems. Spectrum Apportionment As per the Payment Engine Routing utility, capabilities employed in this pattern are middleware services, and hence the pattern apportions capabilities from the left- hand side of the Spectrum (Figure 7). Capabilities from the Spectrum utilised in this pattern include: • Routing, to achieve the Product System selection. • Transformation, to transform from scheme to respective formats required by each of the Product Systems Page 23

10. Farrow:JSC page.qxd 30/04/2012 13:49 Page 24 Patterns for payments systems integration Figure 7 Product System Routing Utility Spectrum Apportionment then provides the necessary integration Summary services to interface the new Payment Engine to the existing Product Systems. Product System Routing Utility As a specific example of the pattern, when the Faster payments Scheme (FPS) Attribute Value was introduced in the UK, a large retail Integration Capability Yes bank deployed a dedicated solution stack Business Capability No comprising ACI Gateway as the Gateway Process Capability No component and ACI Money Transfer State Management No business state, but System as the Payment Engine. A potential technical Routing Utility was developed to route transaction state only relating to Product System payments to and from multiple Products interactions Systems using IBM WebSphere Message Connection Style Single Pass Broker. The pattern is also considered relevant when a new Product System is introduced in the bank’s IT estate. This may arise: Front End Payments Hub • As a consequence of core banking Overview platform migration. In such a scenario, This pattern (Figure 8) constitutes a gen- account migration is not achieved in eralisation of the Payment Engine one ‘big bang’ and a phased approach is Routing Utility pattern. It is also similar to required, where old and new Product the Front End Landing Zone, this being a Systems are concurrent. Thus, co-exis- category of Payments Hub suggested by tence of the multiple Product Systems Hayden et al.7 In this respect, the pattern is required as an interim state and the represents an architectural formalisation of Routing Utility is a transient con- this particular payments integration strat- struct. egy using the constructs defined in the • As a consequence of a banking integra- Payments Processing Architectural Model. tion when new Product Systems are The Front End Landing Zone is shown acquired. This pattern equates to a dif- processing only payment instructions input ferent integration point for the inte- from the Channels, and the integration grated bank systems, this being the from Channels to Hub is shown as being Product Systems rather than the unidirectional. The Front End Payments Payment Engine as per the Payment Hub connects to several Payment Engine Routing Utility pattern. Gateways, each relating to a scheme in Page 24

11. Farrow:JSC page.qxd 30/04/2012 13:49 Page 25 Farrow which the bank participates. In this respect, Figure 8 Front the Front End Payments Hub processes End Payments Hub both inbound and outbound payments instructions from the Payment Gateway and hence the integration is bi-directional. It also connects to one or more Channels, these being end-user delivery channels. They are typically a source of payment instructions, and hence a source of outbound payments (or on-us) payments only, rather than a target for inbound payments. The Front End Payments Hub connects to one or more Payment Engines but does not connect to the Product Systems. Thus, as with the Payment Engine Routing Utility pattern, this pattern does not address the integration problem between the Payment Engines and the Product Systems. Spectrum Apportionment This pattern construct provides middle- the payment instructions with bank- ware services as per the two Routing specific technical or business data; Utility patterns. It also provides the oppor- • Payments Repository, providing a ware- tunity to introduce several payment house of all payments instructions for Business Services (Figure 9). Considering audit purposes. In this pattern, the Front the Capability Model, in addition to the End Payment Hubs has visibility of all Routing, Transformation and Validation, inbound payments from the schemes candidate Business Services include: and all outbound payments originated from the channels. It is therefore a sen- • Diary management, providing functional- sible point of control for updating or ity for altering on files that are expected implementing a centralised Payments to be received or sent to a scheme on a Repository; given day according to the scheme • Intelligent payments routing, enabling operating times; scheme selection based on general cri- • Almanac, this being the determination teria, for outbound payments originated of the Diary events for a given day; from the Customer Channels. • Anti-money laundering (AML) and fraud services, for example, sanctions checking Process services may therefore also be on all inbound payments and event required to orchestrate these Business feeds to AML and fraud management Services. system components; • Account validation, to validate the benefi- Scenarios ciary account for an inbound payment; This pattern addresses the payments chan- • Repair, supporting the correction of nel integration problem across the entire payment instructions incorrectly bank. Thus, It is most relevant when the formed from the channels; channel integration problem is more com- • Enrichment, supporting enrichment of plex than the back-end integration prob- Page 25

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

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

14. Farrow:JSC page.qxd 30/04/2012 13:49 Page 28 Patterns for payments systems integration the phased introduction of common payments processing services, leading to the desired end-state solution. Summary of characteristics Back End Payments Hub Attribute Value Integration Capability Yes Business Capability May provide or delegate some services Process Capability Some limited capability may be required State Management No business state, but may Figure 12 Payments Hub Pattern manage technical state relating to transactions with Product Systems Connection Style Single Pass • The Payments Hub may either: — provide Payments Business Services itself (internal capabilities); or — connect to zero or more externally Payments Hub provided Payments Business Services. Overview All orchestration of Business Services is The term ‘Payments Hub’ is a widely used undertaken by the Payments Hub. In this expression for a generalised solution to pattern, the Payments Hub contains the payments processing. This pattern (Figure aggregate set of Process Services capabili- 12) provides a more precise definition of a ties required to support all scheme pro- Payments Hub in terms of the cessing. The Payments Hub therefore Architectural Model constructs. subsumes the functionality of the Payment In this pattern, the Hub is the central Engine (transactional processing) compo- integration point of all the components nents, and this is not required in this pat- involved in payments processing. None of tern. Some commonality of processing the components interact without commu- steps may be achieved across schemes but, nication through the Payments Hub. All more significantly, reusable shared services the necessary integration capability resides are employed to undertake the specific in the Payments Hub. Connections tasks in the processing chain. between the components require only a The placement of the orchestration single pass through the Payments Hub. capability within the Hub infers business In this respect: state management, as the Hub must accommodate and manage a variety of • One or more Customer Channels are business exception conditions that typi- connected to the Payments Hub. cally occur in processing a payment. • One or more Product Systems are connected to the Payments Hub. Spectrum Apportionment • One or more Payment Gateways are In terms of the categories of service pro- connected to the Payments Hub. vided by the Hub, it provides all of: Page 28

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

16. Farrow:JSC page.qxd 30/04/2012 13:49 Page 30 Patterns for payments systems integration strategy of gradual migration of payment services to the new banking platform, a Payments Hub solution was conceived and implemented using technologies from Clear2Pay. Summary of characteristics Payments Hub Attribute Value Integration Capability Yes Business Capability Yes Process Capability Yes State Management Stateful with respect to business state and also technical state Connection Style Single Pass Figure 14 Payments Service Bus Pattern Payments Service Bus Description The Payments Service Bus (PSB) is also a Business Service orchestration is pro- widely used term for a generalised solu- vided solely by the Payment Engines, each tion to payment processing within the of which may be tailored to provide the bank (Figure 14). The differences between specific processing demanded by a scheme, this and the Payments Hub are how clearly optionally complemented by the banks articulated in terms of the Architectural own value-add services. Model. Processing of an inbound payment Unlike the Payments Hub, this pattern instruction, from receipt at a Gateway to is premised on the existence of a number posting to an account in a Product of separable Payment Engines, typically System, requires several passes through the one per scheme. All integration to and PSB: from the Payment Engines is provided by the Payments Service Bus. In this way, a • collection from the Gateway with rout- common utility is provided for all pay- ing and onward transmission to the cor- ments integration within the bank. The rect Payment Engine; Payments Service Bus can be considered as • calls to a number of the Business a specialism of an Enterprise Service Bus, Services, orchestrated by the Payment but specific to payments integration. Engine, but mediated by the PSB; The PSB connects to all Consumer • selection of the recipient ledger system Channels and Gateways. It also connects and associated account posting to the to multiple Product Systems and to shared correct Product System. Business Services. No payment instruction passes between the payments system com- The PSB itself need only provide stateless ponents without mediation by the PSB. ‘one shot’ services. It is the Payment Page 30

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

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

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

20. Farrow:JSC page.qxd 30/04/2012 13:49 Page 34 Patterns for payments systems integration Figure 16a–c Complexity reduction using the Payments Hub and PSB patterns 16a Original 16b Payments Hub Pattern 16c Payments Service Bus Pattern Page 34

21. Farrow:JSC page.qxd 30/04/2012 13:49 Page 35 Farrow Table 4: Summary of advantages/disadvantages of Patterns as a Target End-State Advantages Disadvantages Payments Service Bus • Complements existing legacy Payment • Residual integration space remains Engines; (does not require replace- more complex than that of the ment of them). Payments Hub, albeit marginal • Supports multiple technologies for • Difficult in practice to achieve pure Payment Engine implementations integration capability as some business • Enables ‘out of the box’ Payment decisioning (eg intelligent payments Engine functionality to be leveraged routing) must take place outside of the from vendors products Payment Engines • Pure integration rather than • Resulting IT estate is more complex replacement design and build effort with multiple product vendors relating to each Payment Engine Payments Hub • Least complex integration space, albeit • More development effort to reach marginally end-state than the Bus as it requires • Suits legacy replacement replacement and consolidation of each • Single Architectural Building Block legacy Payment Engine. for all payments scheme processing, • Single technology choice may not be simplifying IT estate and supplier optimal for all scheme processing management • Single technology implementation and simplified systems management • Is an enabling architecture for custom processing supporting uniqueness of payments processing in each bank bank and the general approach to pay- • separation of architectural concerns, with ments processing within the business; components optimised for one purpose; • the scale of the bank’s payments pro- • elimination of the tight coupling of sys- cessing requirements; tems; • the complexity of the existing IT archi- • provision of the foundation for shared tecture for payments processing, com- payment services to be introduced. prising the heritage Payment Engines and Product Systems. A number of patterns for payment systems integration have been presented and their A summary of the advantages and disad- processing characteristics defined. The pat- vantages of each of the two candidate patterns are shown to relate to specific appor- terns is presented in Table 4. tionments of the Payments Processing Spectrum, which itself provides a useful visual tool for comparing them. CONCLUSION IT scenarios to which the patterns are Payments integration complexity is a relevant have also been highlighted and major barrier to enabling the business discussed. agility of a bank. When the integration Certain patterns are seen to address the problem is addressed, desirable architec- front-end (scheme and channel) integra- tural goals are achieved, which can tion problem, while others address the improve business agility: back-end (Product System) integration Page 35

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