Strategies for Payment Systems Planning

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

ABSTRACT

The need for a structured approach to paymentsystems planning is driven by (i) the complex-ity of the Payments Integration Space, whichdefines the scale of the payment systems plan-ning problem, and (ii) the PaymentsIntegration Paradox, this being the idea that,while the objectives of the planning activity issimplicity in the IT estate, the phases inachieving the simplification are themselveshighly complex. In this context, this paperintroduces strategies for payment systems plan-ning. Three macro strategies are described,which highlight long-term approaches toachieving a chosen IT target architecture.

Complementary micro strategies are also intro-duced, which highlight valuable localisedapproaches within a specific phase of the overallmacro strategy execution. Several target archi-tectures that achieve a simplified payment sys-tems landscape have been identified previously.This paper explores the extent to which thesearchitectures are fulfilled in the execution of thestrategies, illustrated using a comprehensivefunctional model of payments processing. Giventhe dynamic nature of the payments businessenvironment, any systems improvement initia-tive must be able to accommodate impacts dueto ‘shocks’ within the environment. Anoverview of the variety of business events thatcan occur is provided, and a qualitative assess-ment of the robustness to each event of the can-didate target architectures and associatedstrategies is made. The paper concludes by pre-senting case studies highlighting practical expe-riences in executing the different strategieswithin two major payment systems modernisa-tion initiatives.

Keywords: payments strategy, paymentsystems planning, payments hub, serv-ice bus, simplification, systems integra-tion

INTRODUCTION

BackgroundThe payments business environment issuch that payments initiatives within abank are many and continuous:

Journal of Payments Strategy & Systems Volume 7 Number 1

Page 18

Journal of Payments Strategy &SystemsVol. 7, No. 1, 2013, pp. 18–42! Henry Stewart Publications,1750–1806

Strategies for payment systems planning

Gary S. D. FarrowReceived: 18th July, 2012Triari Consulting, 30 Clothorn Road, Didsbury, Manchester, M20 6BP.Tel: +44 (0)161 445 5958; e-mail: [email protected]

Gary Farrow

Farrow:JSC page.qxd 22/03/2013 14:02 Page 18

• Competitive drivers demand that newinitiatives are brought to market quicklyto achieve ‘first mover’ advantage.

• Mandatory regulation and bankingindustry initiatives often set challengingtimescales within which new and oftencomplex systems processing must beimplemented.

The supporting systems landscape forpayments processing within a bank is typ-ically highly complex. In the context ofpayment systems improvements, suchcomplexity is a barrier for a bank inmeeting the demands of the businessenvironment. A complex payment sys-tems landscape means:

• the time to market of changes isadversely affected; and

• costs to implement changes are veryhigh.

A number of target architecture end stateshave previously been identified1 that resultin a vastly simplified IT estate. By achiev-ing one of these target states, a bank isthen much better positioned to respond toevents in the business environment.

A problem arises in how best to under-take the migration of the IT estate fromthe current state to the chosen target endstate via a ‘roadmap’.

This paper explores alternativeapproaches to payment systems planning.The proposed strategies highlight anincremental planning approach foradvancing the payment systems landscapefrom the current ‘As Is’ architecture to thechosen target ‘To Be’ architecture.

The starting point for the assessment ofthe strategies is assumed to be:

• a complex payment systems landscape;and

• a relevant target architecture has beenidentified.

The payments systems planning problem

Figure 1 shows the Integration Space2 forpayments processing defined in terms ofthe set of high-level architectural compo-nents and their inter-connections. Thesecoarse-grained solution components aretermed Architectural Building Blocks(ABBs),3 and an overview of each is pro-vided below.

Payment GatewayThis represents the component that inter-faces to a payments scheme. All communi-cation to and from a scheme is typicallydone via a dedicated Gateway. It also rep-resents components that interact withbusiness partners, for example for the pur-poses of processing payments on theirbehalf. Gateways support business to busi-ness (B2B) interactions.

Customer ChannelThis component represents a channelsystem through which a customer interactswith a bank. It may also equate to afront/back office system used by internalbank staff to perform payments on behalfof a customer or for the bank itself.Channel systems typically initiate a pay-ment instruction, but they are not recipi-ents of them. Channel systems supportbank to customer interactions.

Product SystemThis component represents a core bankingsystem, that domiciles the customeraccounts that are the source and benefici-ary of payments. Product systems subsumea variety of payments-processing services.In a simplified IT architecture, an objec-tive is to replace those embedded serviceswith discrete, shared, business services,described below.

Payment EngineThis component performs the activities

Page 19

Farrow


required to process a payment, this beingthe set discrete processing steps in its valuechain4 within the organisation. ThePayment Engine is invoked:

• upon receiving an inbound paymentinstruction from the scheme via a pay-ments gateway; and

• upon initiation of an outbound pay-ment by a channel or product system.

Payment Business ServicesPayment Business Services represent ITcomponents that provide discrete func-tional services specific to payments pro-cessing. A number of such services are

required and a capability model for pay-ments processing has been defined previ-ously,5 reproduced here for convenience.

The set of Payment Business Services isillustrated in Figure 2, and an overview ofeach provided in Table 1.

The service descriptions include anassessment of the relevance of a service to‘front-end’ and ‘back-end’ processing.Gateways and Customer Channels areconsidered front-end components as theyinteract directly with customers and busi-ness partners, whereas Payment Enginesand Product Systems are considered back-end components.

The classification accounts for whether:


Page 20

Figure 1PaymentsIntegration Space


• the service provider/consumer is afront-/back-end system;

• the service is triggered by events in thefront-end or back-end components; and

• the service is more relevant for front-end or back-end processing.

This classification is relevant for the subse-quent discussion of the proposed strategiesand is summarised in Figure 3.

Objectives of payment systems planningPayments systems planning aims to achievethe following IT architecture improve-ments:

• reduced integration space complexity;• shared functional business services;• shared integration services; and• consolidation, where possible, of the

Page 21

Farrow

Figure 2 PaymentBusiness Services

Figure 3 Summaryof serviceclassification



Page 22

Table 1: Service capabilities overview

Service Overview Classification

Account Posting Account Posting provides a common service for account updates relating to payment debits and Backcredits. Its purpose is to abstract complexity across multiple product and accounting systems.

In the ideal target architecture, the Payment Engine should invoke this service. In some cases, existing legacy channel systems may be configured to invoke account posting directly on payment initiation. In general, however, it is not a service that should be called from the channel systems directly. In a systems improvement initiative, Payment Engines should be re-engineered to call the Account Posting service.

Account Posting is a service provided by the Product Systems and is therefore classified as a back-end service.

Account Validation Account Validation refers to the validation of the beneficiary accounts specified in a Frontpayments instruction.

This service is required upon creation of outbound payment instructions by customers within the channel systems. In these circumstances, the service is used to validate beneficiary accounts. It also may be invoked to validate beneficiary accounts defined within inbound payments instructions prior to performing account posting. This validation can take place when the payment is received from a Gateway.

In a systems improvement initiative, channel systems should be re-engineered to call the Account Validation service.

This service is relevant to front-end processing and is therefore classified as a front-end service.

Almanac The Almanac represents reference data relating to scheme operating times and dates. When used Frontin conjunction with the Diary Management service, it provides alerts relating to scheduled bulk payments.

This service is relevant to the scheme Gateways as it is the point at which an inbound bulk file will be received or at which an outbound bulk file will be marshalled for transfer to the scheme. It is therefore classified as a front-end service.

Anti-Money The Anti-Money Laundering (AML) service is also a complex service, fulfilling regulatory SharedLaundering requirements relating to anti-money laundering.

The AML service is typically required to monitor inbound and outbound payments. In this respect, it can be considered a front-end service. In circumstances where the remitter and beneficiary accounts are domiciled in the same bank (‘on us’ payments), these also require monitoring for AML purposes. The AML service must also be invoked in this context and therefore is also relevant in a back-end processing context.

This service is classified as a shared service.

Diary Management The Diary Management service is closely coupled to the Almanac Service. Given the metadata Frontdefined in the Almanac, the Diary Management capability uses these data to determine the specific diarised events on a given day.

It is therefore considered a front-end service as per the Almanac.

Enrichment Enrichment relates to the enhancement of information in the payment instruction. Enrichment Frontmay be required for both inbound and outbound payments. For outbound payments the enrichment typically takes place when bank or scheme specific data must be appended to the payment (eg correspondent bank details). It may also take place for inbound payments, required to be appended with additional information in order to be processed within the bank eg collection accounts mapping to a real account.

Since the service relates to payments received at the Gateways or initiated by the Channels, it is classified as a front-end service.


Page 23

Farrow

Table 1: Service capabilities overview (continued)


File Validation File Validation provides the capability to perform validation of bulk payment files. Files are Frontvalidated in terms of structural integrity and business content.

Bulk files are received from the payments schemes via the Customer Gateways. Outbound validation of outbound bulk files created by the banks’ systems is not usually necessary, since the systems should be designed and tested to produce correctly formatted files. In this respect, this service is classified as front-end.

Fraud Service As per the AML service, the Fraud Service is generally complex, fulfilling regulatory Sharedrequirements relating to fraud detection.

The Fraud Service must be invoked upon receiving inbound payments from an external remitter and so is relevant for front-end processing. Similarly, for ‘on us’ payments, the Fraud service must also be invoked and is therefore relevant as a back-end service also.

Funds Control The Funds Control service is used to check if there is sufficient credit in a remitter’s account to Backfund a payment.

This service is a function of the customers’ account balance, domiciled on a Product System, and is therefore classified as a back-end service.

Intelligent Payments Intelligent Payments Routing (or Method of Payment [MoP]) is the capability to select the SharedRouting most suitable payments scheme for affecting a payment, given a broad set of characteristics

provided by a customer.

This is relevant in the context of:• ad hoc payments initiated from the Customer Channels; and• a value dated payment being initiated from the Payments Repository upon reaching their value date.

These are considered front-end components, and this service therefore has front-end processing relevance.

Periodic outbound payments being initiated by a back-end Mandate Management service may also require a decision as to which scheme to use. Thus, this service is relevant in both front-end and back-end contexts and is thus classified as shared.

Liquidity Monitor The Liquidity Monitor service captures information relating to the scheme settlement position. SharedTo do this, the service requires visibility of all inbound and outbound payments. Introducing this service between a Hub and the Gateways is guaranteed to achieve visibility of all payments and so a front-end integration point is optimal for the service.

The service is therefore classified as a front-end service.

Mandate Mandate Management refers to the creation and management of payment mandates, these BackManagement being periodic payments instructions. Data for this service are:

• received at the Gateways from the scheme for automated debit mandates; and• channel systems that create and manage standing orders and direct debits.

The mandate service is a source of payment instructions created on a daily basis according to a defined schedule. The mandate capability is often provided in the existing legacy Product Systems. The service is therefore modelled here as a back-end service, as the impact of providing a discrete service is typically to the back-end Product Systems.

Message Validation Message Validation refers to the checking of the structural integrity of a payment instruction and Frontits business content. This service is relevant in the context of Customer Channels that initiate ad hoc outbound payments and for Gateways that receive inbound payment instructions.

This is classified as a front-end service.

Payments Repository The Payments Repository service refers to the storage of ad hoc future dated payments initiated Frontfrom the channels. When their value date is reached, a payment instruction is then created and payment initiation completed.



Page 24

Table 1: Service capabilities overview (continued)


This service relates to deferred payments from the channels and is therefore classified as a front-end service.

Repair The Repair service is invoked for inbound payments. It may also be used to repair outbound Frontpayments initiated by customers.

It is therefore classified as a front-end service.

Routing Routing refers to the selection and transmission of a payment to a specific system destination. Shared

This service is required to:• route inbound payments to the appropriate Payment Engine;• route payments to the appropriate Product System; and• route outbound payment initiated by the Customer Channels.

The above circumstances highlight the need for both front-end and back-end routing and so this service is classified as a shared service.

Sanctions Checking Sanctions Checking relates to a specific form of financial crime service to block payments to or Sharedfrom certain individuals or organisations named on watch lists.

Sanctions Checking is performed as payments are received or leave the bank. This service is classified as a front-end service.

Scheme Limit Scheme Limit Management refers to managing the bank’s risk exposure to the payments scheme. SharedManagement Limits can apply to individual payments and to the total net value. Above a scheme limit,

payments submitted to the scheme may be rejected. The management service provides alerting and withholding capabilities such that the bank’s exposure to the scheme can be proactively managed.

A service validating payments against the scheme limits is useful in the context of a customer initiating an outbound payment. In this respect it has front-end relevance.

The service also has relevance in the case of mandate processing, typically implemented in back-end systems. Since the back-end system is effectively initiating the payment, scheme limits may need to be applied at source. In this context, this service is then relevant to back-end processing. It is therefore classified as a shared service.

State Machine The State Machine is a technical capability that enables the status of a payment to be stored as it Sharedprogresses through a succession of processing activities. The state machine service is required when ‘straight through’ processing of payment is interrupted. This can happen for several reasons:• the payment is withheld for further investigation by AML checking; • the payment instruction fails validation and requires manual intervention to repair it; and• the payment fails a fraud check, for example due to it being from a stolen ‘hot’ debit or credit card.

Therefore, the introduction of ‘real-time’ financial crime services (specifically AML or fraud) and payment validation and repair services require the introduction of the State Machine service as these services may pause systems processing. Since the aforementioned services are classified as either front-end or shared, the State Machine service is also classified as a shared service.

Transformation Transformation refers to the capability to transform the payments instruction from an industry Sharedstandard format to a bank internal format (or vice versa). It is required upon receiving an inbound payment instruction from a Gateway. It may also be needed to transform internally formatted outbound payments:• ad hoc payments created by customers in the Channel components; and• bulk file payments created by the Product Systems.

Similarly, transformation is required for transforming outbound payments originating from a legacy system and for inbound payments destined for a legacy Product System.

It is evident that this service is used in both front and back-end contexts and is therefore classified as shared.


technologies used to implement the keypayments ABBs.

The possible target end states are sum-marised below.

Target end statesFigure 4 illustrates the different targetarchitecture end states that have been sug-gested, defined in terms of the high-levelsystem components identified.

An overview of each architecture isprovided below.

Front-End Payments HubThis architecture addresses the ‘front-end’integration problem. It introduces a newintegration construct — a Front-End Hub— that connects the channel componentsto the existing Payment Engines. Theback-end integration problem is notaddressed with this pattern. Business serv-

Page 25

Farrow

Figure 4 Targetarchitecturepatterns

(a) Front-End Payments Hub (b) Back-End Payments Hub

(c) Enterprise Payments Hub (d) Payments Service Bus


ices are provided by the Hub or compo-nents external to the Hub.

Back-End Payments HubThis architecture addresses the ‘back-end’integration problem. It introduces a newintegration construct — a Back-End Hub— that connects the Payment Engine tothe Product Systems. The front-end inte-gration problem is not addressed with thispattern. Business services are provided bythe Hub itself or components external tothe Hub.

Payments Service BusIn this architecture, a new integration con-struct is introduced that integrates bothfront-end and back-end components. Theconcept of discrete Payment Engines isretained. In this architecture, the PaymentEngine provides the payments processorchestration capability and the ServiceBus provides the integration capabilityaround the Engine. The approach allowsfor leveraging the bank’s existing PaymentEngines or for introducing replacementEngines if required.

Enterprise Payments HubIn this architecture, as per the PaymentsService Bus pattern, a new integration con-struct is introduced that integrates bothfront-end and back-end components.Unlike the Bus pattern, however, thePayment Engine capability is subsumedinto the Hub. The Enterprise PaymentsHub thus provides both the paymentsprocess capability and the integration capa-bility around the Engine. The patterntherefore prescribes the replacement of theexisting legacy engines with a consolidatedcapability provided by the new Hub.

Interim Transition StatesThe Front and Back-End Hub patternsmay be considered as end-state solutionsor as interim states to achieving one of

either the Enterprise Payments Hub orPayments Service Bus end-state solutions.The set of transition states is shown inFigure 5.

It is seen that the role of a migrationstrategy is to accomplish transition fromthe start state to one of the chosen endstates. This is the essence of the paymentsplanning problem.

The Payments System PlanningParadoxFigure 5 highlights the possible targetarchitectures with associated transitionstates. The integration space is significantlysimplified once the migration to thechosen end state is completed. In achiev-ing the end state, the payments IT land-scape is migrated from a position of highintegration complexity to that of a lowone. To achieve such a reduction in com-plexity, however, involves:

• the introduction of a new integrationconstruct;

• the disconnection of established inter-faces between the identified ABBs;

• reconnecting the ABBs via the new Busor Hub component; and

• potentially replacing selected or all ofthe Payment Engines.

These are considered highly complex sys-tems integration activities. This complexityis compounded by the fact that many ofthe interfaces are often likely to be undoc-umented. The migration activity is there-fore a significant undertaking. Therein liesthe paradox — to achieve simplification,one has to undertake a programme ofhuge complexity, fundamentally re-engineering the bank’s payments-process-ing systems.

Given the nature of the criticality ofpayment systems processing, undertakingsuch a migration to a new architecturemust be achieved in a phased manner, de-


Page 26


risking delivery and ensuring the bank’spayments-processing capability is notcompromised. A problem arises in deter-mining the most suitable strategy formigrating to a chosen target architecture.

A structured approach to the planningproblem is considered to be essential,ensuring that systems improvements areaffected in a way that:

• de-risks the IT deliveries associatedwith each stage of the roadmap;

• maximises the chance of success of thepayment systems improvements initia-tives;

• minimises complexity associated witheach stage of the roadmap;

• minimises activity required to achievethe target; and

• ultimately ensures that the businessbenefits of modernised payment systemsare realised.

Several payment systems planning strate-gies are now identified and assessed.

STRATEGY DESCRIPTIONS

Macro strategiesA macro strategy defines an overallapproach to migrating from the currentsystems landscape to the chosen targetarchitecture. In each of these strategies, it isalways assumed that a new payments inte-gration construct is to be introduced, thisbeing one of the forms of Payments Hub.The strategies also identify the potential

Page 27

Farrow

Figure 5Candidate targetend states

Front-EndHub

Front-EndHub

Back-EndHub

Back-EndHub

EnterprisePayments

Hub

EnterprisePaymentsHub/Bus

EnterprisePaymentsHub/Bus

Migration Strategy

Migration Strategy

Migration Strategy

Migration Strategy

Migration Strategy

Migration Strategy

Migration Strategy


for introducing shared components eachproviding a Business Service.

The strategies are:

(i) Channel by Channel Migration;(ii) Back-End Modernisation; and (iii) Scheme-by-Scheme Migration.

A key objective of the payment systemsimprovement is to introduce the sharedbusiness services defined by the capabilitymodel. This section explores the extent towhich new business services can be intro-duced during the execution of the chosenstrategy. In this respect, the analysis pre-sented builds on the Payments Hub intro-duction strategies identified by Hayden etal.6 and provides greater detail in terms ofthe functional scope that each targetarchitecture and migration strategy canachieve.

The target end-state patterns identifiedaddress the front-end integration prob-lem, the back-end integration problem ora combination of both. The classificationidentified in ‘Payment Business Services’is therefore used as a key determinant ofthe relevance of a service to a particularstrategy.

Channel by Channel Migration StrategyOverview. In this strategy, the chosendimension of migration planning is thechannel systems. In this respect, CustomerChannels and Gateways are migrated suchthat they connect with a new PaymentsHub. Point to point connections fromChannels/Gateways to Payment Enginesare replaced with a common integrationcapability provided by the Hub. The migra-tion is undertaken on a channel componentby component basis. As the channels areconnected to the new Hub, this providesthe opportunity for some of the sharedbusiness services to be introduced, replacingthe existing legacy services and reducingduplication of functionality.

If the chosen target architecture forpayment systems processing is a Front-EndPayments Hub, this strategy clearly directlyachieves this particular end-state pattern. Ifthe candidate end state is one of the otherpotential end states, however, specificallyEnterprise Payments Hub or PaymentsService Bus, this strategy can also be usedas a stage in achieving these desired endstates. In these circumstances, once theFront-End Hub is fully deployed, theremaining task is then one of integratingback-end systems and components. Forthis purpose, either the Back-EndModernisation or Scheme-by-Schemestrategies can be employed.

Scope. The Channel by ChannelMigration strategy clearly has the potentialto fulfil all the front-end services and theshared services, but does not realise any ofthe back-end services. The scope of theresulting Front-End Hub on execution ofthe Channel by Channel Migration strat-egy is shown in Figure 6.

Back-End ModernisationOverview. In this strategy, the dimension ofmigration planning is the back-end busi-ness services. In this respect:

• New services are introduced that arerelevant to the back-end systems pro-cessing.

• Payment Engines and Product Systemsare migrated such that they connect viaa new payments hub.

• Point-to-point connections betweenPayment Engines and Product Systemsare implemented using a shared integra-tion capability provided by the pay-ments hub.

The strategy is focused on provisioningthe back-end services, simplifying theback-end systems integration. The intro-duction of the Account Posting and FundsControl services are key to this strategy.


Page 28


These services fulfil the abstraction of theunderlying Product Systems from a pay-ments-processing perspective. Imple -menting these services is considered amajor activity, given the underlying com-plexity of legacy Product Systems.

This strategy provides two sub-options,depending on the chosen end-state archi-tecture:

(i) The existing Payment Engines areretained and integrated with a newPayments Service Bus. This offers theopportunity to leverage existing legacyPayment Engines rather than committo wholesale replacement of them, andreduces migration activity signifi-cantly. This approach allows for the re-engineering or replacement of someof the Payment Engines, decided on acase-by-case basis.

(ii) The Payment Engines are subsumed

into a Payments Hub, achieving con-solidation of all Payment Engines intoa single solution.

As the Engines are connected to the newBus or Hub, this again provides the oppor-tunity for some or all of the identifiedshared Payment Business Services to beintroduced, replacing the existing legacyservices and reducing duplication of func-tionality.

If the chosen target architecture forpayment systems processing is a Back-EndPayments Hub, this strategy directlyachieves this. Again, if the candidate targetarchitecture is one of the other Hubforms, this strategy can also be used as astage in achieving these desired end states.In these circumstances, once the Back-End Hub has been fully deployed, theremaining task is one of integrating front-end systems and components. For this pur-

Page 29

Farrow

Figure 6Front-EndPayments Hubfunctional scope

Front-End Services

Back-End Services

Front-EndPayments Hub

Com

mon

Fro

nt a

ndB

ack-

End

Ser

vice

s


pose, either the Channel by ChannelMigration or Scheme-by-Scheme strate-gies can be employed.

Scope. The Back-End Modernisation strat-egy clearly has the potential to implementall the back-end services and the sharedservices, but not realise any of the front-end services. The scope of services that canbe provided by the Back-End Hub onexecution of the Back-End Modernisationstrategy is illustrated in Figure 7.

Scheme-by-Scheme MigrationOverview. In this strategy, the dimension ofmigration planning is the paymentschemes themselves. Architecturalimprovements relate to changes to boththe front and back-end components thatsupport a specific scheme. These compo-

nents are migrated simultaneously suchthat they connect with a new Hub or Busproviding the necessary integration capa-bility. In this respect:

• Point to point connections fromPayment Engines to Product Systemsare provided by the new Hub.

• Point to point connection fromChannel and Gateways to the PaymentEngines are provided by the new Hub.

• Connections are migrated on a perscheme basis.

• Services are introduced incrementallysuch that their functionality supportsonly what is necessary for a givenscheme.

The strategy provides the opportunity toprovision business services from all the


Page 30

Figure 7Back-End PaymentsHub functionalscope

Front-End Services

Back-End Services

Back-EndPayments Hub

Com

mon

Fro

nt a

ndB

ack-

End

Ser

vice

s


defined categories — Front, Back andShared. Furthermore, it allows for incre-mentally increasing the breadth and depthof functionality provided by each of theidentified business services as the migra-tion for a given scheme is undertaken,eventually resulting in fully specified serv-ices.

The sub-options identified above in‘Back-End Modernisation’ are also appli-cable to this strategy.

An illustration of the functional scopeof the Hub in the end state is shown inFigure 8.

Micro strategiesGiven the business-critical nature of pay-ments processing, the risk associated withpayment systems changes is very high. To

mitigate this risk, certain micro strategiescan be employed during a particularphase of execution of the overall macrostrategy. Three such strategies are identi-fied here:

(i) Parallel Run;(ii) Dual Run; and(iii) Cornerstone.

Parallel RunThe Parallel Run micro strategy refers tothe simultaneous operation of legacy com-ponents and their replacement compo-nents, introduced as part of the overallpayment systems transformation. Thereplacement components may be any oneof those identified from the PaymentBusiness Services model.

Page 31

Farrow

Figure 8EnterprisePayments Hub andPayments ServiceBus functionalscope

Front-End Services

Back-End Services

Com

mon

Fro

nt a

ndB

ack-

End

Ser

vice

sEnterprise PaymentsHub or Services Bus


This strategy aims to prove the opera-tion of the new components in the livesystem, but with a restricted set of cus-tomers or transactions. Doing this limitsthe bank’s risk exposure to any problemsencountered with the new system compo-nents. This is an established approachwithin the industry when major changesare affected in a bank’s payment systems.

This strategy involves routing somepayment transactions to legacy systems andsome to the new components. A numberof ways of selecting which transactions areto be routed to legacy and new systemsprocessing are possible. These are discussedin ‘Segmentation approaches’ below.

Dual RunThe Dual Run micro strategy, as perParallel Run above, also refers to thesimultaneous operation of legacy compo-nents and their replacement components.The difference is that, in Dual Run, bothsolutions process the same transactions fora period of time.

In the short term, the legacy solution(being the proven solution) remains theproduction solution. Processing outcomesof the new component(s) are comparedwith those of the legacy components.Once there is absolute confidence that theprocessing behaviour of the new compo-nents is correct, the new components areswitched to become the production solu-tion.

This approach constitutes a more risk-averse approach than the Parallel Runmicro strategy.

CornerstoneThe Cornerstone micro strategy relates toan approach to de-risk the introduction ofa Payments Hub. The approach is todeploy the Hub as the means of integra-tion between the existing legacy compo-nents, but in a functionally minimal form.Recalling the three categories of service

that a Payments Hub can provide,7 initiallyno or limited business capability or processcapability is deployed, only integrationcapability.

The key advantage of this strategy isthat it deploys the key component of thepayments simplification initiative — theHub or Bus — early into the IT estate,connecting all the major payment sub-sys-tems. It reduces risk by allowing the per-formance of the Hub to be monitored andtuned to meet the expected non-func-tional volumes in advance of increasing itsfunctional scope. Achieving this is a majorstep in simplifying the payment systemscomplexity, as components are now allconnected using the shared capability pro-vided by the Hub.

Initially, there is no functional replace-ment of legacy services. In principle, it isthen relatively straightforward to enhancefunctionality incrementally in the Hub,adding new components that provide thebusiness services with accompanyingorchestration (process) services if required.Once introduced, a new service is thenavailable in all payments-processing con-texts. This can be done with relativelysmall impacts on the legacy systems, asthese are already integrated with the Hub.

Segmentation approachesSegmentation approaches refer to bothbusiness and system techniques for sepa-rating payment transactions. In imple-menting the segmentation approach, avariety of routing rules are possible.Segmentation can be performed on a vari-ety of attributes of the payment, tabulatedin Table 2.

STRATEGY EVALUATIONThe payments planning problem has beenframed thus far as a pure IT problem —that of transitioning to a target architec-ture across the estate. In practice, however,


Page 32


any such modernisations must take placein the context of a changing business envi-ronment. A good strategy must thereforebe able to accommodate internal andexternal shocks during its execution. Inthis section, the chosen target architecturesand associated migration strategies areevaluated by assessing their ability toaccommodate such shocks manifested asbusiness events.

Figure 9 illustrates the variety of typesof business events specific to the paymentsbusiness environment. A brief descriptionof common events is provided, and theimpact on the payment sub-systems isdescribed. This illustrates whether theevent dictates predominantly a front-endissue, a back-end issue or both. This inturn determines how readily the strategycan accommodate the event and serves as ameasure of its robustness.

Business events

Banking MergerA Banking Merger trigger relates to theacquisition or merger of a bank withanother financial institution. In this sce-nario, customers and products of the

acquired bank are transferred to theacquiring bank. From a payments-process-ing perspective, payments instructionsfrom the schemes must now be routed tothe acquiring bank.

Post-business merger, various states ofIT integration can exist.

• Phase 1 — Consolidation of PaymentGateways. This is generally the firstphase of IT integration. The paymentsscheme routes payments to a singleentity (this being the acquired bank)rather than separately to both the orig-inal banks. This requires consolidationof Gateway processing. Upon consoli-dation, a simple interim solution is thento process payments using each respec-tive bank’s payments-processing capa-bility. This requires a routing ofpayments to separate Payment Engines.

• Phase 2 — Consolidation of PaymentEngines. A second phase of integration isto consolidate the payments processing.Payments processing for a given schemeis subsumed onto one or other of theacquiring or acquired bank’s PaymentEngines with the original ProductSystems being retained. This activity

Page 33

Farrow

Table 2: Payment segmentation dimensions

Segmentation dimension Implementation

Product Payments for certain types of products, identified by a combination of sortcode and account number.

Account number Identified as a defined sub-set of account numbers. This may be a simplesplit by account number range.

Customer There is no direct reference to a customer in a payments transaction. Therelationship to a customer is fulfilled by the account number and is typicallyheld in the Product System. Customer groupings can therefore berepresented by determining the account numbers for the set of productsthey hold.

Brand May refer to different product brands and be used to route transactions.Sort codes A simple split based on a range or table lookup of sort codes. Split by value/high care/low care A split based on payment value above/below a threshold.Currency For international payments, the currency code may be used to route

payments.


creates a back-end integration problemto route to the system domiciling thecustomer account.

• Phase 3 — Consolidation of ProductSystems. In the third phase of integra-tion, payments processing and customeraccounts are all consolidated onto singlesystems. Assuming the completion ofPhase 2, this is then a straightforwardactivity to adapt the routing rules as theaccount migration takes place.

Selection of the preferred consolidatedsystems can be on a ‘winner takes all’ or a‘best of breed’ basis.

Summary

Type Impact

Front End Ability to route to the original banks’Payment Engines upon Gatewayconsolidation.

Back End Ability to route to original banks’Product Systems in short to mediumterm until Product Systems areconsolidated.

Banking DivestmentA Banking Divestment trigger relates to abusiness decision or mandated regulatoryrequirement to divest part of the bank.

Specific segments of the bank’s productsand customer base are transferred to thedivested bank.

Should the divested business beacquired, the impact on payments process-ing from the acquiring bank’s perspectiveis covered in ‘Banking Merger’ above.From the perspective of the divestingbank, there are two key options for pay-ments processing to consider:

(i) the divested bank becomes a fullscheme member and performs its ownassociated payments processing; and

(ii) the divesting bank may act as anAgency Bank for the divested bank,processing payments on its behalf.

The Product System to domicile thedivested customer’s accounts may be pro-vided:

• by cloning the divesting bank’s systems;• by migrating to the acquiring bank’s

system; and• by commissioning new Product

Systems.

Assuming an Agency model and contin-ued use of the divesting bank’s ProductSystem to domicile the customeraccounts, from the divesting bank’s per-


Page 34

Figure 9 Types ofbusiness and ITevents


spective, the IT impact of the divestmentrequires a logical separation of paymentsprocessing and the customers’ accounts.Assuming the divested bank provides itsown Product System in the long term,maintaining the Agency model willrequire a new Gateway between the twobanks.

If the long-term objective is for thedivested bank to become a full schememember (or if the acquiring bank alreadyis), payments are routed directly by thescheme to the Payments Gateways of thedivested bank. In these circumstances, ITimpacts relate to the divested or acquiringbank as per ‘Banking Merger’ above.

Summary

Type Impact

Front End Introduction of new B2B Gateway inthe event of the adoption of anAgency model.

New Automated Clearing HouseA New Automated Clearing House(ACH) trigger relates to the bank becom-ing a member of a scheme. This may be anew scheme or an existing scheme inwhich the bank does not currently partic-ipate as a direct member. A New ACH is amajor event, but a relatively rare occur-rence, examples being the introduction ofthe Faster Payments scheme in the UKand Eurozone SEPA schemes.

In system terms, interaction with a newscheme usually requires the introductionof a Payments Gateway. It will typicallyalso require a new Payment Engine ormodification to an existing Engine.Product Systems must accommodatedebits and credits associated withinbound/outbound payments via thescheme, affected by the Payment Engine.

Channel systems may also be affected ifinitiation of the payments through the new

scheme is permitted directly in the channel.The preferable approach, however, is thatthe responsibility for method of payment(MoP) selection logic is held outside thechannel system itself within the IntelligentPayments Routing service. The channel isthen isolated from the payments schemespecifics and is not affected by such a trig-ger. This event provides the opportunity tointroduce this architectural approach.

Summary

Type Impact

Front End Introduction of a new Gateway andintegration with the associatedPayment Engine.Other channel connections to supportpayment initiation unless intelligentMoP is adopted.

Back End New routing capability to route fromthe new Payment Engine to theexisting Product Systems.

New Customer Channel

The New Customer Channel triggerrelates to the introduction of a new chan-nel system within the bank. An examplemight be the introduction of a mobilebanking channel. The new channel systemmay be required to initiate payments viaone or more of the payment schemes. Thiswill require integrations from the channelto each scheme-specific Payment Engine.

As discussed in the ‘New ACH’ trigger,if the MoP determination is done inde-pendently of the channel, this problem is

Page 35

Farrow

Summary

Type Impact

Front End New integrations from the channelsystem to multiple Payment Enginesin the circumstances of scheme-specific payment initiation in thechannel.


lessened, as the channel needs to integrateonly with the component providing theMoP.

Regulatory ChangeA Regulatory Change trigger relates to amandated capability that must be incorpo-rated into a bank’s payments processing.Regulatory Change triggers are verydiverse and are not easy to predict.Typically, regulatory triggers fall into oneof two categories:

(i) the introduction of watch lists againstwhich transactions are monitored andreported; a recent example of this cat-egory of Regulatory Change trigger isForeign Account Tax Compliance Act(FATCA)8; and

(ii) a requirement to report on liquidity orother financial attributes of the bank.

From an IT perspective, both these cate-gories require monitoring of paymentevents and the introduction of logic toperform data capture and matching.Having a Payments Service Bus or Hubalready in place makes such monitoringrelatively easy, since this component willhave visibility of all payments. Similarly,implementing a payments ‘operational datastore’ is useful to capture payments trans-actions and constitutes a convenient datasource upon which to perform necessarymatching and reporting.

Summary

Type Impact

Front End Capture of payment events.Back End New components to store data and

perform matching and reporting.

IT Events

The following events relate to IT driversto modernise payments-processing sys-

tems. These typically arise through:

• the emergence of new technologies;• a desire to migrate from legacy systems

to more flexible packaged solutions; and• a need to migrate from applications and

platforms that are no longer supportedby a vendor and therefore present anoperational risk to an organisation.

Core Banking Platform ReplacementCore Banking Platform Replacementrefers to the introduction of a newProduct System to replace the existingbanking platform. Given the high businessrisk associated with the activity, this sce-nario demands a phased introduction ofthe new banking platform with customersegments being migrated gradually fromthe legacy platform to the new bankingplatform.

In system terms, legacy banking plat-forms and new platforms must operateconcurrently as the migration takes place.Thus, from a payments-processing per-spective, inbound payments must now berouted to one or other of the bankingplatforms. Similarly, outbound paymentsinitiated from Customer Channels requiredebits to be posted to the Product Systemdomiciling the customer account.

Summary

Type Impact

Back End New integrations from multiplePayment Engines to Product Systems.Routing to legacy and new ProductSystems.

Payment Engine Replacement

This trigger relates to the introduction of areplacement Payment Engine in the ITestate. As with core banking replacement,there is high business risk associated withthe activity, and this scenario also demands


Page 36


a phased introduction of the new PaymentEngine, using one of the defined microstrategies.

Similarly, the legacy Engine and newEngine must be supported concurrently asthe migration takes place. Thus inboundpayments from a given source must nowbe routed to one or other of the Engines.

Summary

Type Impact

Front End New routing capability to route torespective legacy and new PaymentEngines systems.

Industry standards refresh

This trigger relates to changes to industrystandards to which a bank must respond inorder to continue to interface with thescheme. The change usually infersenhancements to data transmitted to andfrom the scheme. The changes may involvethe introduction of essential new dataitems and optional ones.

Using the data has an impact on thePayment Engine that must interpret thedata for inbound payments or populate itfor outbound payments. If the data are notbusiness critical, the bank may elect not toprocess the new data. In these circum-stances, data can be transformed at theGateway to existing canonical formatsemployed internally within the bank. ThePayments Hub/Bus should perform this

transformation function. Adopting thisapproach does not affect downstream pay-ments-processing components and iseffective in quickly aligning changes toindustry standards.

Strategy robustness analysisA summary of front-end and back-endimpacts of the set of events is shown inFigure 10. The majority of events have afront-end impact. This suggests that aFront-End Hub solution can readilyaccommodate the impact of the majorityof the events. Fewer than half of the eventtypes identified have a back-end impact.This infers that a Back-End Hub solutionis less able to accommodate the impact,given the range of events that can occur. Itshould be noted, however, that someevents have both front-end and back-endimpacts, and so these particular events areless easily accommodated by either of theFront-End or Back-End Hub solutions.

Target architectures of EnterprisePayments Hub or Payments Service Buscan accommodate both front-end andback-end impacts within their scope.

Similarly, if one is adopting a front-endmigration strategy, it is likely that this canmore readily accommodate impacts tothe planning and execution than a back-end migration strategy can. A Scheme-by-Scheme migration will already addressboth front-end and back-end impactswithin its scope and so is consideredmore robust to the range of businessevents than either the front-end or back-end strategies.

CASE STUDIES

Major UK retail bankA major UK retail bank with a globalpresence embarked on a programme tosimplify its payments processing. Over 200separate sub-systems were to be consoli-

Page 37

Farrow

Summary

Type Impact

Front End Transformation of the industry datainto an internal canonical format.Impact to downstream processing,primarily the Payment Engineprocessing if the new data is businesscritical.


dated, and a common integration solutionwas to be adopted. The business and IToperations were primarily UK focused,but there was also significant Europeanand North American presence. Thisinferred substantial UK, Eurozone andcross-border transactions.

The target architecture selected was aPayment Service Bus, the primary objec-tive being a reduction in the PaymentsIntegration Space complexity with itsassociated business benefits. This approachleveraged the existing Payment Engines,but did not preclude targeted replacementof some legacy engines in the future.

Strategies adopted include:

• Channel by Channel Migration. The over-arching strategy was to introduce theBus in the first instance to connect theexisting channel systems and PaymentEngines, replacing the existing point-to-point integrations.

• Cornerstone Strategy. This strategy com-plemented the Channel by ChannelMigration strategy. Initially, integrationsfrom Channels and Gateways to thelegacy Payment Engines were to becompleted. In doing this, there were to

be no functional impacts to these com-ponents. New business services werethen to be added incrementally, orches-trated by the Bus. Corresponding legacyservices were decommissioned in acontrolled manner.

• Back-End Modernisation. On completionof the Channel by Channel Migration,new back-end services were to beintroduced. Key to this strategy was thedevelopment of services to abstract theinterface to three Product Systems andprovide a sophisticated Account Postingservice.

Shocks to the business environmentobserved during the period of the pro-gramme were:

• Regulatory Change 1. Introduction ofmandatory US regulation, specificallyFATCA. This regulation required themonitoring of financial transactionsrelating to a specific customer segmentand reporting on their activity. Above acertain threshold value of payment, italso required the withholding of a cer-tain percentage of the payment’s value.

In systems terms, a desirable strategic


Page 38

Figure 10PaymentsIntegration Space

Front End

Back EndBan

king M

erger

Bankin

g Dive

stmen

t

New A

CH

New C

usto

mer C

hann

el

Regula

tory

Chang

e

Core B

ankin

g Plat

form

Rep

lacem

ent

Paymen

ts Eng

ine R

eplac

emen

t

Indus

try S

tandard

s Refr

esh


solution was to store payments such thatanalysis of the transactions for the spe-cific customer segment could be per-formed. This in turn inferred that theBus was required to have visibility of therelevant financial transactions and thenemploy a new service to store them inthe short to medium term for analysis.

• Regulatory Change 2. Introduction ofmandatory regulation relating toaccount switching.9 This regulationrequired the identification of paymentsfor accounts that were closed up to oneyear previously and the re-routing ofcredits to a defined switched account.In system terms, the impact was tomonitor payments and match paymentsagainst a set of known switchedaccounts.

• Industry Standards Refresh. This eventrepresented the annual update to theSWIFT standards.

In executing the Front-End Migrationstrategy, it was apparent that there was sig-nificant complexity to even achieve theCornerstone strategy. This was becauselegacy systems themselves were old andinformally documented. It required a sig-nificant concentration of effort to analyseand scope the Payments Service Bus for asingle Gateway connection.

Even prior to completion of the chan-nel migration, there were immediate andsignificant demands to increase the func-tionality of the Bus and provide servicesfor operational storage and to performanalytics on the payment transactions tosupport the FATCA requirements. So,while this requirement could be consid-ered a front-end impact and could beaccommodated within the chosen strategy,in practice it required much problemanalysis and created many cross-pro-gramme dependencies. It was difficult toaccommodate these within the timescalesof the regulatory requirement.

The regulatory change relating toaccount switching inferred a back-endimpact to mark switched accounts andtrigger specific processing when paymentsto these accounts were attempted.Addressing this requirement inferredbringing forward solutions relating toback-end systems processing. This againdetracted from the ability to execute theinitial front-end migration strategy.

Finally, the standards refresh should havebeen an event that was readily accommo-dated within the initial phase of the strat-egy, given it had a front-end impact.Achieving this, however, was dependent onthe early fulfilment of the Cornerstonestrategy, such that the Bus with its associ-ated transformation capability was available.This approach could have been used tobuffer downstream systems from changes.Timescales for the execution of the Front-End Migration strategy were affected bythe initial complexity and implementationof solutions to accommodate the regulatoryrequirements. This meant that this eventwas unable to be accommodated using thenew strategic solution.

In summary, the ambitious scope of thePayments Service Bus and the significantimpact of the business events that occurredmeant that the modernisation programmewas in a continual state of planning andproblem solving. The Front-EndMigration strategy was seen as a ‘quickwin’ to deploy the Bus and de-risk thetechnology solution. In practice, even thefirst scheduled phase of a single Gatewayintegration using the Bus proved to be alarge undertaking. It is too early to com-ment on the overall success of the pro-gramme, and this was ongoing as of late2012.

UK high street bankA UK retail bank embarked on a pro-gramme to replace its legacy productssystem with a new core banking platform.

Page 39

Farrow


The bank was a member of all UK pay-ments schemes and a major provider ofwholesale payments for corporates andbanking partners. The bank had limitedinternational payment transactions.

An Enterprise Payments Hub patternwas identified as the target end state,broadly occupying a mid-spectrum posi-tion in terms of its required functional-ity.10 A roadmap was defined to introducethe new core banking platform andPayments Hub, this being delivered over aperiod of several years in three majorphases of work.

Strategies adopted included:

• Scheme-by-Scheme macro strategy. Theoverarching strategy was to introducethe Hub on a per scheme basis.

• Product Segmentation. The initial ap -proach was to introduce the new corebanking platform to support a specificsavings product with payments beingundertaken using the UK BACSscheme.

• Cornerstone Micro Strategy. A strategy ofdeploying the Hub early within the ITestate was employed. Since the overallapproach was a Scheme-by-Schemestrategy, initially the Hub connected tothe BACS Gateway with routing andtransformation capabilities to integrateto both legacy and new ProductSystems. The initial deployment consti-tuted a Cornerstone strategy as the Hubprocessed transactions, but all wererouted to the original legacy system.

• Parallel Run. In the subsequent phase ofdelivery, the savings products were to beintroduced in the new Product System,and BACS transactions only for theseproducts were then to be routed by theHub to the new Product System. Thisconstituted a Parallel Run, as bothlegacy and new processing occurredsimultaneously, but for a specific seg-ment of the BACS transactions.

Shocks to the business environmentobserved during the period of the pro-gramme:

• New Channel. As part of the overall ITmodernisation, a replacement internetbanking system was to be introduced.The Payments Hub could be employedto integrate this channel to the ProductSystem to support payment initiation.

• Banking Merger. The bank acquiredanother financial institution that sold arestricted range of financial productsand had limited payments-processingcapability. This merger could be accom-modated by subsuming the paymentsprocessing, with the bank acting initiallyas an Agency for the acquired bank.

• New Product System. A replacementcredit card system was also commis-sioned as part of the modernisation. ThePayments Hub could be employed toundertake integration of this newProduct System with card schemeGateways.

In summary, the strategies adopted werebroadly able to de-risk the business pro-gramme for the initial planned phase. Theyalso proved robust to significant shocks inthe business environment, these being anacquisition and two technology refreshes.It should be noted, however, that the pro-gramme is still ongoing, and the originaltimescales for the work were extended.This is indicative of the complexity of theplanning activity and of the significantimpact related to the business events thatoccurred.

CONCLUSIONAchieving modernisation and simplifica-tion of payment-systems processing is ahugely complex undertaking. In migratingto a new target systems architecture, astructured approach to the planning is


Page 40


considered essential. Two types of strate-gies for guiding the migration have beenpresented:

• macro strategies, to guide the overallsystems planning; and

• micro strategies, to provide localised de-risking of the delivery phases.

The business environment for banking,and payments in particular, is subject tosignificant shocks, especially in the currentclimate. The types of business events thatcan occur have been identified, and theirpotential impact on payment systems pro-cessing has been determined. Some busi-ness events infer primarily a front-endimpact, whereas others infer a back-endsystems impact or both. The robustness ofthe target architectures and strategies hasbeen evaluated in terms of their ability toaccommodate these events.

To provide maximum robustness toshocks to the business environment, banksshould adopt either the EnterprisePayments Hub or Payments Service Busarchitecture. Both these architectures areconsidered to provide the greatest robust-ness, since they can more readily accommo-date both front-end and back-end impacts.A Front-End Hub is considered morerobust than the Back-End Hub, since thebusiness events are shown to be more likelyto affect the front-end processing.

The overall system’s robustness isstrongly determined by the choice oftarget architecture, but the choice ofmigration strategy also plays a role. AScheme-by-Scheme migration strategy isconsidered most robust to possible busi-ness events, since the planning activity isalready addressing improvements to bothfront-end and back-end processing. AChannel by Channel Migration strategy isconsidered more robust than a Back-EndModernisation, again because of the morelikely impact of business events to front-

end than back-end processing.Regarding the micro strategies, the case

studies highlight a potential drawback ofthe Cornerstone strategy in that there is asignificant amount of integration work in‘re-wiring’ the existing legacy compo-nents. Given the undocumented nature ofmost legacy systems, there is a risk that theprogramme becomes entrenched in tech-nical integration work. Several deliverycycles could complete without any signif-icant realisation of business benefit.Furthermore, the approach may incur sig-nificant integration effort for a legacysystem that is in fact due for replacement.This integration effort would be repeatedwhen the replacement system was intro-duced.

The experience highlighted by the casestudy in undertaking a Channel byChannel Migration suggests that knownor emerging business events can soon dis-rupt the strategy execution. If such eventsbegin to dominate the planning and exe-cution, a modified strategy of prioritisingand aligning improvement phases to theemerging business events is consideredeffective. Using this approach, each phaseis aligned to the specific requirements of abusiness event and delivers only the mini-mal functionality necessary to support thatevent. Furthermore, legacy componentsare only decommissioned if they areaffected by the particular event.

Adopting this approach means thateffort is focused on priority businessimperatives. The downside, however, is thateven a series of business events is unlikelyto affect all the payment sub-systems, andso modernisation of some componentswould not be triggered. This implies thatthe target end state of a fully integratedHub cannot be achieved by this approachalone. This contrasts with the macro strate-gies that are designed to achieve the com-plete migration of all components to thedesired target architecture.

Page 41

Farrow


In conclusion, it is clear that all thehighlighted strategies must always be com-plemented with planning to accommodatethe emerging business events. The scale ofimpact of the business events, their visibil-ity on the planning horizon and oftenchallenging timescales will continue tomake the payments planning problemextremely challenging. The structuredapproaches presented here help addressthat challenge.

REFERENCES

(1) Farrow, G. S. D. (2012) ‘Patterns forPayment Systems Integration’, Journal ofPayments Strategy and Systems, Vol. 6, No. 1, pp. 15–36.

(2) Ibid.(3) The Open Group Architecture Forum

(2009) ‘TOGAF 9’, ISBN978-90-8753-230-7. Available at:http://www.opengroup.org/togaf(accessed 2nd March, 2012).

(4) Porter, M. E. (2004) ‘CompetitiveAdvantage’, Free Press, New York.

(5) Farrow, G. S. D. (2011) ‘The Payments

Hub Spectrum: A Model for the Designof Payment Hubs’, Journal of PaymentsSystems and Strategy, Vol. 5, No. 1, pp. 23–24.

(6) Hayden, R. Akash, L. Ledford, S. andNunn, C. (2010) ‘Payments Hubs:Redefining the Industry’s Infrastructure’,McKinsey Quarterly, No. 8, pp. 16–21.Available at: http://www.mckinsey.com/clientservice/Financial_Services/Knowledge_Highlights/Recent_Reports/~/media/Reports/Financial_Services/MoP8_Payments_hubs.ashx (accessed12th February, 2012).

(7) Farrow, ref. 5 above.(8) Foreign Account Tax Compliance Act

2011. Available at: http://www.irs.gov/Businesses/Corporations/Foreign-Account-Tax-Compliance-Act-(FATCA) (accessed 20th November,2012).

(9) Payments Council (2011) ‘AccountsSwitching’, Payments Council, London.Available at: http://www.paymentscouncil.org.uk/current_projects/account_switching/ (accessed 20th November,2012).

(10) Farrow, ref. 5 above.


Page 42


Economy & Finance

Strategies for Payment Systems Planning