Best practices in payments infrastructure investmentarchive.bottomline.com/collateral/banking/Best_Practices...This multi-national corporation (MNC) had multiple enterprise resource

Eric Campbell is Chief Technology Officer atBottomline Technologies and an expert onglobal cash management, wholesale electronicbanking, custody, SWIFT connectivity and theuse of Service Oriented Architecture withinbanking applications. Eric has more than 30years of industry experience in technology innovation in global cash management, securi-ties and straight-through processing and isactively involved in helping many of the world’sleading banks and financial institutions deploysoftware architectures for advanced treasuryservices. He was recently recognised for thethird time in four years as one of GlobalFinance magazine’s ‘Who’s Who in Treasuryand Cash Management’.

ABSTRACT

This paper explores how to invest strategicallyin payments infrastructure, identifying where theneed is greatest and most urgent, with an expla-nation of the available options. For many com-panies, getting a solid payment processingfoundation in place could mean more thansimply saving money and eliminating fraudpotential. The right foundation might actuallyenable business scalability or provide funda -mental client satisfaction criteria affecting theoverall success of the business. It is important tounderstand that the word ‘payments founda-tion’ is appropriate because it sets up a platformwhere continuous improvements can be madeover time as part of an ongoing programme,where each phase will bring additional returnon investment (ROI). The payments environ-

ment is constantly evolving, with new risks,compliance challenges and changes in standardsoccurring regularly. An organisation without acomprehensive payments foundation could finditself in a bad situation owing to factors com-pletely out of its control; in a worst case scenario,the distribution of the problem may make itunsolvable in a timely manner. Getting the firstproject off the ground and laying down thefoundation is critical. The right combination ofproblems must be identified in the first phase toyield an ROI. It is the intention of this paperto help the reader to identify that list of issuesas well as provide a background for organisa-tional buy-in and presentation of a successfulbusiness case.

Keywords: cash management, trans-action banking, SWIFT, payments hub,payments

INTRODUCTIONWaking up each morning and thinkingabout how payments are executed from anenterprise perspective is not a normalactivity for every key executive. As manyorganisations have grown and expandedtheir activities over the years, however, theIT infrastructure for payment processingmay not have kept up with the complexityof today’s banks, other diversified financialinstitutions and large corporations. Thismeans that this space has become both ahidden gem for massive cost savings as

Page 127

Journal of Payments Strategy & Systems Volume 4 Number 2

Journal of Payments Strategy &SystemsVol. 4 No. 2, 2010, pp. 127–144� Henry Stewart Publications,1750–1814

Best practices in payments infrastructure investment

Eric CampbellReceived (in revised form): 12th March, 2010Bottomline Technologies, 325 Corporate Drive, Portsmouth, NH 03801, USA. Tel: +1 603 501 4898; Fax: +1 603 501 4027; e-mail: [email protected]

Campbell:JSC page.qxd 14/06/2010 11:19 Page 127

well as a fertile ground for fraud, organisa-tional risk and even catastrophe.

So who should be thinking about thisand why? This paper’s goal is to categorisethe IT payments space and help readers todetermine whether or not their organisa-tions are candidates for change and, if so,to what extent.

It is first necessary to understand thatthere is no written ‘cookbook’ on how toproceed, but there are common driversthat can be easily identified and quantified.For some organisations, improvement maybe as simple as choosing the right bankwith the right payment initiation product,while for other organisations, a multi-phase, multi-million dollar project mightbe extremely appropriate and provide asurprisingly rich return on investment(ROI) or address a much more costly crit-ical business problem.

CASE STUDIESOver the past ten years, many corporationshave focused on strengthening their enter-prise payments strategies and haveachieved a substantial ROI on the initialinvestment. More importantly, they havelaid a foundation for a programme ofongoing improvement. Several case studiesare included in this paper.

Case study 1: Retail brokerage This organisation had a completelymanual process in place for making pay-ments on behalf of their clients. Wireinstructions were faxed to the head officefor manual approval, general ledger (G/L)and client account systems were manuallyupdated, and bank workstations were usedto initiate the payments. Creating and re-keying the transaction happened multipletimes, and the confirmation process wascompletely manual. There were well over1,000 remote offices which kept chequebooks in their offices for servicing client

account withdrawals. All the processes sur-rounding the cutting of cheques weremanual: debiting the client’s account,approving the payment and crediting theoperating account G/L. Because chequeswere manually written, it was impossibleto generate positive pay transactions effec-tively, and the additional risk of distributedcheque stock remained.

Case study 2: A large financial institutionThis client had multiple systems initiatingpayments to multiple banks using bank-provided software and host to host inter-faces. In some cases, more than onesolution was required per bank. The com-plications of maintaining multiple bankworkstation technologies (some of whichwere deployed on early 1990s technology)was becoming increasingly risky and diffi-cult to manage. Every bank required pro-prietary processes, and each occurrencehad a different degree of compliance. Inaddition, bank-reported transactions hadto be manually matched against outstand-ing mutual fund orders for settlement.This matching process involved cuttingand pasting transactions into multiplespreadsheets and then emailing the spread-sheets to regional operating centres wherethe open fund orders could be settled orexceptions handled.

Case study 3: A multi-national corporationThis multi-national corporation (MNC)had multiple enterprise resource planning(ERP) applications which needed to initi-ate high-volume/low-value payments.These ERP systems connected to multiplebanks using multiple ‘host to host’ bankproprietary solutions. A large number ofbank workstations were also used for cashreporting and payment/money movementinstructions. Daily cash forecasting wasmanually intense and required business


Page 128


units to submit daily and weekly forecasts.As actual transactions were executed, theyhad to be managed against the forecasts.This was complicated by the fact that theycould occur multiple times in the paymentexecution life cycle and could only becounted once.

Case study 4: A large public entityThis government agency had over 30,000suppliers who were being paid by chequeand paper remittance. Each payment’s pro-cessing cost was estimated at US$4.25, fora total monthly cost of well overUS$100,000. This was just to process thecheque payments.

A PAYMENTS HUB — SIMPLYDEFINEDAt the heart of any enterprise paymentsinitiative there needs to be some sem-blance of a ‘payments hub’, which simplydefined is a conical payments data modelwhich receives payments from any sourceand stores then in an efficiently designeddatabase where various workflow tasks canbe performed. Once a payment or batchof payments is ready for execution, theyare dynamically routed, appropriately for-matted and sent to the system or bank of

execution. Some kind of confirmation,return or notice of change (NOC) mes-sage is matched against the original pay-ment to complete the transaction lifecycle. Subsequently, the payment isstored/archived for the required amountof time to allow audit trail enquiries aswell as normal business as usual queries.The simple diagram in Figure 1 illustratesthis proven model for building a solid pay-ments processing foundation.

The left-hand side of the diagramshows systems and people originating pay-ments, and the right-hand side shows thepayment destinations, or payment execu-tion. The hub’s destination can be SWIFTfor settlement across banks, a direct bankinterface or a payments back-office ap -plication if the hub is installed at a bank orin a country where direct access to theclearing system by non-banks is allowed.

The validation rules imposed by thehub should directly mirror those requiredby the final clearing system and any rulesimposed by applications/networksbetween the hub and the final clearingsystem. For example, a payment beingpassed through SWIFT to the Real TimeGross Settlement (RTGS) system inAustralia must pass all SWIFT validationrules and Australian RTGS rules. It is

Page 129

Campbell

Figure 1 Model forbuilding a solidpaymentsprocessingfoundation


important to understand that these twosets of rules are completely independent.If FileAct is used across SWIFT for pay-ment delivery, there are no validation rulesimposed by SWIFT, and all the rules arehandled by the FileAct Receiver and finalclearing system only. Ideally, validationrules should be implemented as a servicethat can be shared by both systematic pay-ment initiation as well as manual paymententry/modification/repair screens.

The data model holding the paymentsmust be capable of handling any clearingmethod and be flexible enough to handleboth batch and individual payment work-flows. Once in the data model, the realvalue of a payments hub can be realised:

• Payment methods can be changedeasily, allowing for transactions either tobe routed to a lower cost method or,conversely, to be accelerated based onurgency.

• Anti-money laundering (AML) andother compliance functions can be cen-trally applied.

• Approval workflows which mirror cor-porate mandates can be universallyapplied.

• Dynamic limit checking can beimposed.

• Feeds to cash forecasting functions canbe constructed to provide better cashmanagement visibility.

• Positive pay transactions can be auto-matically generated in cases where thehub is managing cheques.

• Repair functions can be implementedto allow imported transactions to befixed in a timely manner instead of re-processing them in the system of ori -gination.

• Duplicate checking can occur to pre-vent the same payment from beingprocessed more than once.

• Additional approval workflow can becreated for payments that are considered

risky (ie keying on beneficiary coun-try).

• Transactions with duplicate beneficiarydata (often caused by systems that maybe processing multiple independentpayments for a given customer) can beconsolidated.

There are obviously many more functionsand benefits of a payments hub, but thegoal of outlining those mentioned above isthat readers should understand the valueof the payments hub foundation and howit plays a role in a long-term programmeof continuous improvement.

DIVIDE AND CONQUERWith any complex problem, the best placeto start is breaking the problem down intocategories. In this case there are three:

• Direct cost takeout: If cheques can beconverted to low-cost electronic trans-actions, direct savings can be attainedsimply on the removal of the processingcosts involved with the paper instru-ment, not to mention environmentalconcerns. Usually any float gains areoffset by payment predictability anditem cost, but that is an age-old argu-ment not worthy of discussion here.There is general acceptance that a peritem cost savings of US$3–5 can beattained whenever a paper instrument isconverted to electronic. This is similarto bank repair costs — reduce failurerate, reduce cost.

• Process efficiency: Manual intervention,paper tickets, faxes, re-keying, etc. Whatcan be saved by simply improving thefactory? How can process improve-ments or best practices be engineeredinto the infrastructure, but be imple-mented only once and used across theboard?

• Fraud prevention: Sometimes process effi-


Page 130


ciency problems lead to fraud problems,but this category really focuses ontopics such as board mandates, compli-ance for payment approval as well ascreating end-to-end ‘tamper proof ’ pay-ment transactions. Even though positivepay services have been available foryears, it is sometimes shocking to findout how many companies operate out-side this protection.

Although there are three categories, theyare often related. In order to apply a fraudprevention or direct cost takeout initiativeeffectively, process efficiency projects mustbe undertaken. Often, the key is prioritisa-tion. Having a slow or error-prone pay-ment process could cause a company tolose market share if it is a financial servicescompany, so having a streamlined efficientprocess could be as important as an airlinekeeping its jets well maintained. Similarly,a highly publicised fraud case could causeextreme reputational damage, even if theactual dollar losses are minimal.

Direct cost takeout initiativesThere are two primary focus points forthis category: cheques and wires (RTGSpayments) (see Tables 1 and 2). Settlementpurposes can sometimes drive the choiceof needing a wire or a cheque payment,but moving to low-cost electronic pay-ments (automated clearing house (ACH)),if possible, can offer significant cost savings

WiresCase study 2 (the financial institution)focused on a repair function which couldfix incorrect settlement information storedon the originating systems. Transactionswith missing mandatory fields, incorrectbeneficiary or intermediary banks or disal-lowed characters are now pushed into arepair queue within the organisation,avoiding a costly repair at the bank. Thepayment repair screens restrict modifica-

tion only to the fields which affect the set-tlement: fields such as the beneficiaryinformation or amount are not touched toavoid going through another round ofapproval workflow.

This financial institution achieved bankindependence and eliminated bank repairfees. Infrastructure support costs associatedwith the bank proprietary software andmanual intervention/re-keying were alsoeliminated.

ChequesCase study 4 (a large public entity) joineda payment network which enabled theelectronic migration of their cheque pay-ments. By converting a significant portionof paper cheques to ACH payments withelectronic remittance information, thisorganisation saw savings of more thanUS$500,000. An established network canprovide upwards of a 50 per cent hit rateon vendors, hence providing almost instanton-boarding. The remaining vendors canbe selectively on-boarded based on pay-ment volumes. An advanced network cantake over the entire vendor paymentstream immediately, continuing normalcheque payments to those vendors whorepresent too low volumes to migrateonto the network. In this case study, about45 per cent of the vendors were on-boarded, and approximately 35 per cent ofthe total cheque payments were convertedwithin the first eight weeks.

Process efficiency initiativesThere are several key metrics and ques-tions to look at when measuring paymentprocess efficiency:

Manual originationHow many human payment originatorsare there? In other words, outside an ERPor other back-office system, how manyusers initiate payment requests each day? Ifthere are a substantial number of origina-

Page 131

Campbell



Page 132

Table 1: Wires (RTGS payments)

Cost takeout opportunity Obstacle Solution

Wire competitive pricing —wire payments are a high marginservice with a very low fixedcost. Prices can vary from US$2to US$30 for a domestic wire.

Putting in a solution that allowsan organisation to changedestination banks for wireinstructions will force banks intomore competitive pricing, andpricing can be re-visitedwhenever there is anopportunity for improvement.

A wire that should have been anACH. Paying dollars forpayments when one could havespent cents.

Wires are primarily donethrough bank proprietarysoftware using proprietaryformats.

Banks have installed proprietarycommunication software forsending files.

Bank software is often packagedso that single ad hoc payments,when created, will result in awire.

Migrate to a SWIFT FIN orISO20022 standard industry messageformat that could be used with anybank. MT103 FIN messages areused in the US for wires, andMT101 FIN messages are usedeverywhere else. Confirmationmessage with clearing referenceinformation is returned in anMT900 which contains the originalinstruction reference number foreasy matching.

ISO20022 will probably be acceptedby most banks within five years, butacceptance is patchy currently. It isstrongly recommended that, if acompany has a projectedimplementation target over the nexttwo years, it uses the FIN standardinstead of ISO20022. FIN will be anavailable format indefinitely.

Migrate all communications toSWIFT. The SWIFT Network canbe used to send wire instructions toany SWIFT member bank.

If an organisation is not some typeof financial services firm, SWIFTmembership will involve joiningSCORE or a bank’sMember-Administered Closed UserGroup (commonly referred to as aMA-CUG).

With the Introduction of SWIFTAlliance Lite, SWIFT membershipand communication has becomeeasy and extremely affordable forcorporations of varying sizes.

Some banks are now offering theirusers the ability to toggle betweenwire and ACH clearing methods. Ifa bank workstation is part of an adhoc payment operation, make surethat this is available, and make surethat all the users are educated on thesavings potential.


Page 133

Campbell

Table 1: Wires (RTGS payments) (continued)


Wire Repair fees can beextremely costly.

Erroneous or duplicate wires.Unlike ACH, wires areirreversible, so there is inherenthigher risk using a finalsettlement instrument such as awire.

Payments are getting approvedlate because of inefficientinvoice approval processes.

Settlement information,especially any requiredintermediary banks may beincorrect or incomplete. Thereis no validation when theinformation is entered.

Wires can accidentally becreated multiple times owing toa breakdown in a manual orsystematic process.

Look for invoice approvalautomation solutions which canremove paper invoices from theprocess and streamline the workflow.The right solution can also bringthe much more substantial benefitsof realising vendor early paymentdiscounts and optimising workingcapital.

Reference information providers aswell as some banks can validate thatthe intermediary bank is the correctone for the chosen beneficiary bank.If a business involves many ad hocwires, this type of service needs tobe a critical factor when choosing itswire bank or end to end wireprocess.

Use of payment templates on acentralised payments platform —independent of the back office orERP can enable more efficientmanagement ofvendor/counterparty directorieswhile maintaining the correctstanding settlement instructions.Many source systems may not havethe necessary fields to provide finalsettlement and ensure straightthrough processing (STP).

Implement inbound/outboundduplicate checking into theenterprise payments environment.Outbound duplicate checking (wiresleaving the enterprise paymentsystem) is relatively straightforward,inbound duplicate checking(checking fuzzier logic on paymentsoriginating from different sources)can require some business-specificanalysis, but can usually be leveragedacross all payment methods — notjust wires.



Page 134

Table 2: Cheques


Vendors and service providersare being paid by cheque withpaper remittance. Converting acheque to an ACH payment canyield between US$3 and US$5per item, depending on howefficient the existing chequeprocess is. Much of the float‘benefit’ used as an excuse tocontinue with cheques has goneaway based on the introductionof Check 21. This is particularlytrue in times of low interestrates, such as today.

It is also key to understand that avendor/supplier chequeconversion strategy is not an ‘allor nothing’ proposition. Lowvolume or one-off vendors canremain on cheque payments.

The successful paymentnetworks can come with over 50per cent of the vendors andsuppliers already enrolledallowing for almost instantconversion.

Managing account signatories.

Vendors and service providersdo not want to share theiraccount and bank information.

There is no clean way toprovide the remittanceinformation along with thepayment.

Physical signatures must bemaintained by the bank tosupport cheque processing —this is also cumbersome whenopening accounts.

In some markets, such as most ofEurope, vendors and suppliers alwaysprovide their account/IBANinformation to their customers forelectronic payments. This, however,is not the case in North America.Therefore an electronic paymentnetwork can be used where thevendors can be on-boarded andauthenticated to the network, andthe paper cheques can be replacedwith ACH payments while thevendor banking details are keptprivate by the network provider.

The electronic network providerwill communicate the remittanceinformation to the vendors/supplierselectronically. These vendors canprovide services to populate CTXaddenda to accompany the actualACH payments, but they can alsoprovide secure vendor access to theremittance data, which can include awide variety of translation/mappingservices to streamline the processesto both counterparties.

Digital signatures on electronicpayments will eliminate the need tohave a potentially large number ofpayment originators on file andmanaged by the bank.Banks are supporting the electronicopening of accounts (EBAM), andadoption of the SWIFT ISO20022messages for account openings hasbeen in practice since 2008.


tors against a high volume of payments,chances are this is an area where improve-ments are very achievable. In a purestraight-through processing (STP) envi-ronment.

• The payment originator would requesta payment, attaching a level of detailenough to allow an approver to per-form the function quickly. The origina-tor would be able to enter all the payeedetails, where validation rules would bereadily available to ensure that the cor-rect information is captured at creation.Repetitive payments could be createdfrom pre-established/approved tem-plates.

• The approver(s) would be assignedbased on the mandates provided by cor-porate governance, and they would bealerted in a timely manner.

• The correct operational debit accountwould be automatically assigned orassigned by treasury before the paymentwas sent to the bank.

• Approved payments would pass unat-tended to the paying bank, where exe-cuted confirms would be matched backwith any additional routing informationtagged to the payment.

Automating wire initiation was consideredlow-hanging fruit for three of the above-mentioned case studies. All three usedSWIFT for bank communication andwere able to stop using bank-proprietarysoftware anywhere within the wire trans-action life cycle. The retail brokerage casestudy actually automated all the account-ing with interfaces into both the G/L aswell as the client account systems. In addi-tion, clients’ transactions were routed tothe appropriate account managementgroup for approval, and treasury assignedthe debit account number on all theapproved wires. The brokerage firm’sclient would have the settlement informa-

tion verified on the spot, so that issuescould be resolved at point of capture, anda Fed wire confirmation is now in handwithin minutes. The MT103/MT101messages (depending on servicing bank)were routed (by setting the destinationBIC) to the appropriate bank based on theaccount selected by treasury, and in mostcases the wires were confirmed withMT900 debit confirmations (includingthe Fed reference number in field 72) inunder five minutes.

One would expect this to be a reason-ably easy process to implement, but thereare many obstacles (see Table 3).

ERP or back-office originationDo multiple ERP or back-office systemsneed to communicate with multiplebanks for multiple payment methods? Ina pure STP environment, any systemoriginating a payment could providethose instructions in a single format thatwould be pre-validated and routed to thecorrect destination bank without anyhuman intervention. Confirmationsand/or rejections would be passed backand matched against their unique refer-ence assigned by the origination system(see Table 4).

The Financial Institution and MNCcase studies had multiple systems whichneeded to create payments. It was not atall practical to put settlement interfaces onall the originating systems, nor was it prac-tical to choose one of those systems to bea settlements hub. A payments hub whichsat between the originating systems andthe delivery channel (in both casesSWIFT) was clearly the best alternative.The payments hubs maintained the settle-ment information for some of these sys-tems, particularly those that were designedand built before IBANs were introducedand did not maintain the appropriate set-tlement information. Therefore, the pay-ments hubs had to maintain payment

Page 135

Campbell


templates keyed by a client ID whichcould resolve the settlement informationupon payment import. To allow this, thepayment templates needed to go through asimilar approval workflow to any free-form payment with the same level of man-dated approval compliance.

Managing cash positions

Does the company have issues managingdaylight overdrafts, or optimising dailycash positions? This is perhaps one of themost difficult process efficiency problemsto solve, because it tends to be specific toeach organisation. One major company


Page 136

Table 3: Process efficiency initiatives

Obstacle Problem Solution

Treasury does not want theoriginators to access the bank’spayment origination system andthe operational debit account is amandatory field.

Bank-specific browser productsmust be used to originate manypayment types.

Remote locations need tooriginate and approve payments.

Originators need a way tosupply detail about why thepayment is being made so thatthe approver can make aninformed decision.

Remittance detail cannot beeffectively passed on to thepayee.

A manual alternative method isused to request the paymentfrom treasury. The payment isthen re-keyed by treasury whereany problems have to beresolved by treasury instead ofthe Originator. Alternativemethods such as fax or e-mailsopen the door for fraud anderrors.

Payment details must be keyedinto each bank’s system. Banksystem may or may not be ableto provide an approvalworkflow that meets corporateapproval mandates.

Many payment originationsystems operate on older clientserver applications orbrowser-based solutions whichcan only safely operate within aLAN environment.

There is no clean way toassociate the paymentinstruction directly with theinvoice or vendor data.

Clearing systems do not havesufficient capacity to passenough detail, and certainly no‘attachments’ are allowed.

The payment origination messageshould only require debit G/Linformation in addition to the payeedetails. Treasury should be ablesimply to tag the payment with thedesired operating account on theway out.

A bank independent paymentorigination system needs to bedeployed which can provide anentry screen for the requiredpayment details, provide clearingvalidation rules, meet approvalmandate requirements, andcommunicate payment instructionsto any bank via SWIFT.

The payment application must betotally Web based, allowing secureconnection even from the publicInternet.

The payment system should allowfor attachments of vendor invoicesor detail so that the approver hasdirect access.

The payment system must providealternative ways to pass remittancedetail to the payee. There must bemultiple options, including e-mail,fax and Web-based solutions for thevendor.


Page 137

Campbell

Table 4: ERP or back-office origination


aIf five ERP systems required five bank interfaces, it would mean 25 total interfaces. With five ERP interfaces toa single data model, and five bank interfaces from that data model, the total number of interfaces would be onlyten.bA change in the bank interface to the single data model would not affect any of the ERP interfaces to the datamodel.

Bank-specific host to hostproducts must be used.

Multiple ERP/back-officeapplications need to provideautomated paymentinstructions to multiple bankswhere each bank channel isunique.

ERP systems do not have therequired clearing validationrules.

Reconcilement betweenpayments and reportedtransactions can be manual andtime consuming.

Remittance detail cannot beeffectively passed on to thepayee.

Each bank requires its owncommunication protocoland/or formats.

Each ERP must have aspecific interface created foreach bank and potentiallyfor each payment method.Every time a bank changes,every system must changethat requires that interface.

Payments originating inERP system have to beaugmented or repaired.

Many of the bank’s host tohost products do not provideadequate confirmation files— particularly for low-valuepayments.

Clearing systems do nothave sufficient capacity topass enough detail.

A bank-independent payment originationsystem needs to be deployed whichcommunicates payment instructions toany bank via SWIFT in ISO format.

Implement a hub that can receivepayments from any source, map it to asingle data model, and then extract it tothe appropriate destination bank. Usingthis methodology, the number ofinterfaces will be drastically reduced,a andthe ERP/back-office applications areinsulated from external changes createdby bank counterparties.b

ERP payments can reference paymentsystem templates so that settlementinstructions can be managed in a singleplace. An enterprise paymentinfrastructure needs to be able to publishWeb services for payment validation fromany system needing to originateinstructions so that they can be validatedat source.

The payment system needs to be able totrack payments based on status and returnto the origination system a reconcilementfile that matches the outgoing referencenumber (from the originating system) tothe payment status and clearing referencenumber (if one exists). Any NOC, returnor other such file received from the bankmust be processed and passed back,notifying the origination system of theproblem. Payments that do not failshould have the option to be ‘autoconfirmed’.

The payment system must providealternative ways to pass remittance detailto the payee. There must be multipleselections including e-mail, fax andWeb-based solutions for the vendor.



Page 138

Table 5: Managing cash positions


Cash decisioning isaccomplished bymanually populatinghighly tailoredspreadsheets.

The same data canappear from multiplesources.

Information heldmanaged within thespreadsheet must be actedupon in a timely manner— possibly near realtime.

The data collection canbe incredibly timeconsuming.

Critical transactions canbe included more thanonce.

Excel does not createmoney movement orpayment transactions.

Inclusion of daily cash projections by dynamicallypopulating cells within a spreadsheet from multiplesources, such as accounts payable and accountsreceivable. Using database query tools,transactional and balance information can beretrieved from multiple systems. To facilitate thistype of external data source for Excel, groundworkand additional views need to be configured withinthe data source databases. It is recommended that a‘Data User’ maintenance function be establishedwhich will automatically provide read-only access,as well as provide a means for setting up dataaccess restrictions based on G/L accounts or otherorganisational parameters so that the access viewscan easily be re-used across the organisation.

Multiple third-party industry tools are available tosupport this functionality of dynamicallypopulating cells within a spreadsheet from multipledatabase sources.

When combining outgoing payment informationwith bank intra-day reporting for a real-time cashposition, the outgoing payment needs to flip fromone source to the other when it appears in theintra-day bank reported data. This process mustrely on matching the client reference, whichshould under most circumstances be includedwithin the incoming cash reporting messages.

When deploying a cash decisioning tool usingExcel, there needs to be an automated way toexecute money movement instructions once thedata have been collected and position decisionshave been determined. The payment ITinfrastructure should be able to recognise thepayment instruction type needed automatically,based on the debit account, credit account, amountand value date. Hence, the one file with themoney movement instructions could translate intowires, book transfers, account transfers, multi-bankMT101, etc., depending on the relationshipbetween the two accounts.


was managing their cash position with aseries of calculators (for tracking outgoingwires) in association with six differentbank workstations to track balances andincoming wires.

It is not a coincidence that Excel isused to manage this process for mostcompanies; the rules need to be easilyconfigured and changed, and Excel pro-vides a good tool for some organisations.The problem is populating Excel withthe right information as automatically aspossible. Many organisations which ulti-mately use Excel as the final decisioningtool have to deploy incredibly complexand manual data collection processes infront of it (see Table 5).

In the MNC case study, the organisa-tion needed to manage its cash positionsclosely with maximum up-front visibilityso that the daily positioning strategy couldbe as effective as possible. Every night,business units report their cash forecastsfor the following day and for the weekahead. In the morning, the daily cash pro-jections are updated by each unit as theday starts. As real payments start to hit thepayments hub, they are matched firstagainst the forecasts to avoid doublecounting, and again as the payments getreported by the bank in current day trans-action reporting. At a certain point of theday, operating accounts are swept andtopped based on all the transactions in thesystem (forecasts, payments that have notbeen reported back by the banks yet, andpayments that have come through a cur-rent day BAI feed from the banks). If anyexceptions occur after the sweep, adjust-ments can be made to the cash positions,and there is full visibility to what hasoccurred or perhaps what has notoccurred.

Fraud prevention initiativesThis section identifies areas which, if leftunnoticed or unaddressed can cause signif-

icant risk to the organisation (see Table 6).Often those addressing the exposures pro-duce an instant successful business case forIT funding.

By incorporating cheques into theirpayment hub, the retail brokerage in casestudy 1 was able to automate the chequeinitiation processes completely, leveragingthe exact same services and approvalworkflow used to support the wire initia-tion process. This demonstrates how astrategy combining all payment methodsinto a single payments hub foundation canallow deployed services to be leveragedacross the board, once they are created.These types of payment processing serv-ices are almost always payment-typeagnostic. Taking a generic perspective onpayments is extremely important so thatthe services can easily be reused.

The deployed software allowed theremote offices to enter the cheque detailsand manage the MICR cheque printingprocess on plain paper stock, using only abrowser. Positive pay files were then auto-matically generated with all the benefici-ary detail. These two functions eliminatedtwo huge fraud risk factors.

Tamper-proof transactionsSometimes payment processing can besimilar to the Great Wall of China. Thesame way in which the immense wall wascompromised by bribing the right guardon the inside, apparently very secureprocesses often have very exposed backdoor vulnerabilities (see Table 7).

It has become industry best practice toprotect payments from an electronic bank-ing system with hash-based messageauthentication codes (HMAC). The trans-actions generally come from well-fundedaccounts, and hence the risk of generatinga high-value fraudulent transaction is highgiven the power of an internal databaseadministrator (DBA). Similarly, companiesdeploying a payments hub internally

Page 139

Campbell



Page 140

Table 6: Fraud prevention initiatives

Fraud risk Problem Solution

Blank cheque stock can bestolen and forged.

Without a positive pay interfaceto the bank, fraudulent chequescan be paid.

A physical signature is too easilycompromised.

Many companies still managepre-printed cheques.

If cheques come frompre-printed stock or use ade-centralised process, it canoften be impossible to capturethe cheque information to sendto the bank.

Approvals are done by signingcheques, tickets, forms, letters,etc.

Browser and client/server softwarecan print MICR cheques on plainstock eliminating printed chequeinventories. MICR printers areavailable in a very wide range ofprices, and browsers can printMICR cheques as easily as travellersprint boarding passes today.

A centralised cheque managementsystem will capture all chequeinformation and manage the positivepay interfaces to the bank toguarantee that all cheques havepositive pay on them.

Payments now need to be approvedelectronically with two-factorauthentication. If the originator isinternal, the need for an actualdigital signature for non-repudiationis probably minimal, but having asecure single-use password or USBdevice protected by a PIN orpassword is an important safeguardthat the correct person is actuallyapproving the transaction. Inconversations, some executives havestated in the past that ‘I sign anypiece of paper that my secretary putsin front of me, and if I’m in a rush, Imany not look at it at all’. Havingelectronic approval, with a timelye-mail/SMS alerting mechanism, is akey way to build the right culturefor executives in a payment approvalrole. If the originator of thepayment is outside the organisation,done by someone who is dulyauthorised on the payment account,then it is essential that a digitalsignature be calculated from thepayment digest, stored with thepayment details, and subsequentlyusable to ensure non-repudiation bythat third party originator orcustomer.


should make this a security requirementfor the initiative.

BANKS AND CORPORATE HOSTCONNECTIVITYOne of the key issues facing the bankingindustry over the past ten years has beenthe resistance to embracing SWIFT as achannel to support the initiation of pay-ments. This was caused by a number offactors:

• Banks viewed their legacy ‘host to host’

products as being ‘sticky’, and end oflifing them ran the risk of offending astrategic client. As a result, many corpo-rations ended up with literally dozensof host to host links — sometimes tothe same bank.

• Ironically, many banks in the US andUK viewed corporate SWIFT access asa threat, believing that it commoditisedpayment services. This perception wasnot shared by their European counter-parts, who embraced it — probablybecause in those countries multi-bankpayment services have been part of the

Page 141

Campbell

Table 7: Tamper-proof transactions

Fraud risk Problem Solution

Payment files that are droppedonto a network drive forexecution are not secure.

DBA can create fraudulenttransactions.

Systems often pass files bydropping files in a directory foranother system to pick up andexecute.

By definition, the DBA hasaccess to a database withcomplete freedom to changefields.

Unless the key fields are put into asecure digest or HMAC andchecked by the receiver of the file(the bank), there is little guaranteethat the file did not get tamperedwith. Encryption is often used to tryto secure these files, but it must trulybe industrial strength, with excellentkey management, to be an effectivemeans of payment detail integrity.

This is a huge exposure to thepayment process, since paymentsgenerally pass through one or moredatabase tables as part of their lifecycle. Similar to the HMAC processon the file drops, transactions can beprotected from the DBA bycalculating an HMAC from the keyfields, storing that HMAC with thetransaction, and then comparing thestored HMAC against the currentcalculated value whenever thetransaction is accessed. Thismethodology will not protect thetransaction from being changed, butit will recognise that the transactionwas changed, and stop it in its tracks.It will also passively identify wherethere is a serious internal issue, sothat it can be effectively dealt with.


banking landscape for years.• Banks are often organised in stove

pipes. Cash management specialists atthe banks were completely taken offguard when a large client asked aboutsending transactions via SWIFT. Theestablished SWIFT teams were totallyfocused on supporting correspondentbanks, and this change required a cross-organisational team (sometimes peoplewho had never met each other) to sat-isfy an enquiring client.

• The ‘plumbing’ simply was not there.There was no connection from thebank’s SWIFT interface to the ACHback-office or DDA system where thecorporate accounts were maintained.Many times, this created a ‘sneakerbrigade’, which was often discovered bylarge clients sending test transactionswith text intentionally transposed. Byreceiving a confirmation that was cor-rected, it ensured that someone at thebank had manually re-keyed it some-where in the process.

During the initial roll-out of SWIFT cor-porate access projects, it was difficult to getgood information. Some banks claimed toprovide a certain payment service — suchas BACS payments in the UK — only tofind out later that they did not have thiscapability once the lack of ‘plumbing’ wasdiscovered. In one particular case, a finan-cial institution client was told by theirbank that they simply could not take wireinstructions from them via SWIFT, since‘they were set up on the Corporate DDAsystem that did not have an interface withSWIFT’; this was said despite the fact thatthe requesting financial institution was afull SWIFT member.

The good news is that these trail-blaz-ing 800 pound gorilla corporations pavedthe way for everyone else. Banks werepractically forced into bolstering their cor-porate SWIFT STP capability because

their largest clients threatened to do busi-ness with their competition if they didnot. In conjunction with industry initia-tives such as SCORE and a vastly simpli-fied SWIFT membership process, SWIFTis the right bank connectivity alternativefor any payments hub initiative.

MULTI-CHANNEL SUPPORTOne of the more obvious industry needsis for banks to provide a unified, Web-based application which looks across allpayment initiation channels. Today, if acorporation submits payments via host tohost channels or SWIFT, there is rarelyvisibility to those payments (before exe-cution) on the Web channels. Corporateclients can only view the Web-initiatedpayments within the Web-based channel.This shortcoming is usually a result ofsiloed bank organisational structures forthe different channels. As banks take amore client-centric approach to productmanagement, this gap will probably beeliminated over the coming years. In thefuture, host-submitted payments (viaeither SWIFT or direct file channels) willbe reviewed, approved, repaired andmonitored directly on the bank’s Webchannel.

PAYMENTS IT SCORECARDThe purpose of this scorecard is to meas-ure the likelihood that opportunities mayexist within an organisation for improvingits payments IT infrastructure (see Figure2). The higher the score in the variousfocus areas, the greater the need for atten-tion. This should help to establish priori-ties for possible investment.

CONCLUSIONThe payments IT infrastructure of manyorganisations, both large and small, have


Page 142


Page 143

Campbell

Figure 2 IT scorecard

Focus area Scoring method Score

Direct cost opportunity

Percentage of total payments that are done by cheque 0–10 per cent (0), 11–40 per cent (1), 41–60 per cent (2), 60 per cent+ (3)

Do you use bank proprietary software for ‘host to No (0), One interface (1), More than one host’ transmissions? interface (3)

The number of wire payments originated every day 0–5 (0), 6–20(1), 20–50 (2), 50+ (3)

Direct cost opportunity score (0–9)

Process efficiency opportunity

The number of human payment originators not using 0–5 (0), 6–20 (1), 21–50 (2), 50+ (3)an ERP or back-office application

Number of back-office systems that originate 0 (0), 1 (1), 2–5 (2), 6+ (3)payment instructions

Number of bank counterparties receiving payment 1(0), 2 (1), 2–5 (2), 6+ (3)instructions

Do you have a home-grown payment system in use No (0), Yes (3)that is over two years old?

Rate the efficiency of your daily cash position Rate yourself (0) hands free and accurate, (3) manual management process and problematic. Add up to 3 more points if you feel this is a critical function within your business based on the amount of cash involved.

Do you have comprehensive payment approval No (0), Yes (3)mandates that are not being complied with because of ERP or bank software limitations?

Do payment instructions come into your treasury area No (0), Yes (3)via fax or e-mail?

Do you use pre-printed cheque stock? No (0), Yes (3)

Are all your cheques covered by Positive Pay services? Yes (0), No (3)

Do you have multiple geographic locations that No (0), Yes (3)require payment approval from other geographic locations?

Are your payments being approved by having a signed No (0), Yes (3)ticket or paper form?


often evolved into a fragmented andoverly complex but critical piece ofplumbing. This paper was aimed at help-ing to heighten awareness and potentiallyproviding input into a business case tomake improvements. After a discussion atSIBOS (Swift International BankingOperations Seminar) a couple of years ago,a large corporation realised that, after aseries of bank acquisitions over the pastten years, they actually had 40+ interfacesin one bank which they were actively

maintaining. Things that work — orappear to work — are easy to ignore.What would be the cost of taking out orreducing those interfaces to one? If no oneis taking the time to look at it, the costswill simply continue. Asking the rightquestions and performing the analysis isthe critical first step. In many cases, theopportunity for reduced cost, improvedefficiency and heightened security is wellworth the investment, given the rightapproach and advice.


Page 144

Focus area Scoring method Score


Process efficiency opportunity score (0–36)

Fraud prevention opportunity

How comfortable are you with any ‘file drop’ security Rate yourself (0) very comfortable, (3) you have in place for files containing payments? not comfortable

Have you thought about and planned for a rogue DBA Yes, and there is protection in place (0), compromising a payments database? No or Yes and nothing has been done to address the issue (3)


Do third parties or customers create payment No (0), Yes (3)instructions without a digital signature for non-repudiation?

Are your electronic payments being approved by having No (0), Yes (3)a signed ticket or paper form?

Do you use pre-printed cheque stock? No (0), Yes (5)

Are all your cheques covered by Positive Pay services? Yes (0), No (5)

Fraud prevention opportunity score (0–27)


Documents

Best practices in payments infrastructure investmentarchive.bottomline.com/collateral/banking/Best_Practices...This multi-national corporation (MNC) had multiple enterprise resource