Cash Management – Payments Management
The application of corporate treasury technology in the origination, validation and execution of treasury and commercial payments
The gtnews series about the practical application of technology in corporate treasury continues with this discussion of the use of technology to manage and control payments, or ‘wires’ as they are commonly called in North American banking practice.
On initial consideration, this might seem to be a relatively straightforward (although clearly important) topic; in fact, it is an area in which differences of scale, geographic location and treasury department mission and policy result in marked differences being encountered in practice. This spectrum of differences is accordingly reflected in the demands imposed on the supporting treasury and finance technology.
Payments management is an area in which there is often a fuzzy boundary between treasury and finance, and this is one of the reasons that the subject is by no means as clear cut as might be supposed by the casual observer.
TMS payment modules originally developed as a logical extension to general treasury management functionality as the values and benefits of STP treasury workflows achieved general acceptance. Prior to this, it was common practice for TMSs to generate lists of payments to be made, and for these to be manually entered into bank workstations, or directly into the banks’ payment portals.
The generation and execution of a payment is clearly one of the most sensitive and risky treasury processes, especially given the relatively large size of the typical treasury payment. The necessary workflow clearly merits high levels of transparency and control to secure and clearly document all relevant actions and events.
It may be useful to summarise the typical range of pure treasury payments that might be created and managed by a TMS for a specific treasury department’s operations. The scope generally extends to: deposit placements; loan, bond, MTN and commercial paper interest payments and maturity redemptions; FX and commodity deal openings and closings; option premium payments; interest rate swap interest payments; FRA and futures transaction settlements; bond, equity, money market instrument and other investment purchase transaction settlements.
TMS payment modules construct the payments needed to settle the transactions and events listed above, and export them for processing by single or multiple bank communications channels. These typically include direct corporate-to-bank connections via the web, bank workstations and SWIFT, which is typically used by a corporate through a specialist service bureau. A common multi-banking arrangement is that the TMS exports some or all payments to a single ‘lead cash management bank’ which then assumes responsibility for sending on payment messages to different banks for execution. This type of solution is also offered by specialist third parties. The range of alternatives can seem quite daunting, and the reasons for a specific choice often include bank relationship considerations, as well as cost and efficiency issues. A factor that should not be neglected in solution selection is the solution providers’ established capabilities in supporting and resolving problem issues.
The payment messages created or processed generally fall within standards such as the SWIFT MT 101 – it is the responsibility of the TMS to construct each message in compliance with the standard being used by the bank or banks in question. It should be noted that these standards are not, in practice, absolutely consistent, and the effective TMS needs a sufficient degree of flexibility to accommodate variations from bank to bank – which can be quite subtle. The TMS may also have to handle multiple payment system message standards, protocols and security requirements; for example, SWIFT, ACH, Fedwire and CHAPS might be needed.
The security imposed on payments workflows is naturally rigorous, and the necessary design and implementation requirements can be especially demanding on smaller operations, because of the essential non-negotiable finance policy requirements of segregating duties and responsibilities, and of imposing other prudent controls.
One (out of many) models for doing this via a TMS follows:
• Dealing staff are not permitted to create or change settlement instructions, which is the responsibility of a distinct set of individuals from the finance team.
• Similarly, the finance team members are not permitted to perform or process treasury deals.
• The normal settlement process including payment export centres on the use of pre-defined and secured standard payment instructions.
• All payments are authorised and released by different people in the workflow.
• A separate process requiring a different set of senior authorisations is required if it is necessary to over-ride or change the standard payment instructions.
• The TMS maintains a complete and indelible audit trail of the payments workflow, showing each operation performed, with a date and time stamp, and clear identification of the individual responsible.
• The TMS workflow will monitor for attempts to breach the defined rules, and will alert nominated managers if any breach is detected.
The key features are that the workflow once defined is locked-down, so that special procedures are required for any over-ride or modification to be performed, and also that there is 100% transparency of all payment events.
The most simple payment execution process found in older treasury technology is for the TMS simply to create a secured file of payments on the corporate network for collection by the bank, or to export the information directly to the bank via a portal, in both cases without further follow-up. The underlying assumption is that the bank will take care of matters from the point of export from the TMS, and that any subsequent problem issues will be researched and corrected manually.
More Sophisticated Payment Workflow Management
SWIFT has led the way for the evolution of a much more interactive process, in which payment status is fed back from the bank to the TMS, enabling payment progress to be monitored in some detail, and for any detected errors to be corrected – with manual intervention kept to a necessary minimum. The information exchange includes positive and negative messages (‘ACKs’ and ‘NAKs’) and the transmission of diagnostic codes that can be interpreted and acted on by the TMS. In some solutions, there are multiple levels of the acknowledgement message type set; this enables sophisticated tracking, analysis, repair and reporting to be accomplished.
The existence and availability of such transparent information exchange has substantially enhanced the quality of corporate treasury payments management in recent years, through enabling intelligent interaction between bank and TMS, facilitating faster error research and correction. These developments have made payment processing much more transparent and robust, better controlled and of significantly higher audit quality. Technically, these interactive facilities enable true end-to-end process automation, as they allow the entire treasury payments cycle to be tracked and monitored, for example from the original entry of a time deposit transaction to its ultimate settlement as an executed cash flow from the corporate’s bank account to the receiving bank.
Corporate treasuries may originate very small numbers of payments when they are functioning as group treasuries, simply concerned with executing a few (usually substantial) FX hedges and occasional loans and deposits, as compared with large globally or regionally centralised operations which perform treasury operations on behalf of a network of subsidiaries, and which can generate substantial daily volumes of external (and internal) payments. Companies that operate in-house banks see this process amplified, as treasury assumes some or all of the roles of external commercial banks, including responsibility for payments management. In-house banking is the subject of a future dedicated article in this series.
In cases where volumes are small, it can be difficult to cost justify the STP integration of payments execution, and in such situations payment workflows may still be paper based, and require the re-keying of the payments into banking or other specialist software. Today, there is increasing management and audit pressure to fully automate such workflows; the cost of doing so is often justified by the disproportionate potential costs of payment failure, error and fraud. The expense of setting up and supporting the automated payments process may be regarded as an insurance premium, securing the organisation against the possible costs and losses incurred when there are serious problems with the payment workflow.
Many treasuries process significant numbers of non-treasury or commercial payments, for a variety of reasons. Often, these are high value ‘payments on behalf of’ a corporate operating unit, which are made through treasury in compliance with the organisation’s finance policy. The general benefit of this approach is the immediate visibility of the outflows to treasury, optimising cash visibility and hence, potentially, the quality of the subsequent cash management operations, and the management reporting of enterprise-wide cash positions and projections.
Another reason for significant volumes of non-treasury payments being executed by treasury is when the treasury department has a finance company role, in which case it will need to fulfil requirements such as payroll execution and the payment of commercial invoices such as rent and operating expenses.
In some situations, and especially in larger corporations, treasury cash management functions overlap with finance department responsibilities, for example in the management of commercial bulk payments. This is seen in shared service centres, and especially in the phenomenon of payment factories.
Payment factories have historically been seen as the preserve of very large organisations; but the benefits of operational standardisation and streamlining, combined with enhanced control and visibility of cash are now affordable to more and more companies, given the availability of powerful and effective supporting technology.
Payment factories focus on the efficient and secure management of large volumes of low value commercial payments – and this is the reason that much – and especially older – TMS technology does not traditionally do a good job of handling relatively high volumes of payment transactions; it was simply not designed for this type of function.
So what really constitutes ‘high volume?’ This of course varies in detail from system to system, but the threshold today lies approximately between 2,000 and 5,000 payment flows daily. When overloaded with payments, TMS performance can decline exponentially. The reasons for this are complex and technical, and concern both system and database architecture; but from the treasurer’s perspective, extreme volume testing is an absolutely essential element in the evaluation of a payments factory solution. ‘Extreme’ in this context means running through something like 3 times the expected daily maximum volume, to construct a reasonable performance test.
In practice, some TMSs whose technology is up to date can handle high payment volumes effectively and efficiently. Other systems require supplementing with a stand-alone payments management solution that has been designed to handle high volumes well, to provide adequate capacity. As stated at the beginning of this analysis, this is a surprisingly complex subject, and locating the optimum solution in a given situation can often be a complex undertaking.
There are additional factors involved in the comparison of TMS and specialist payment solutions for bulk payment management.
As explained above, treasury settlements tend to be executed on an individual basis, as befits the management of high value cash movements. Conversely, high volume commercial bulk payments are originated or channelled through ERP and accounting systems, and are often merged with other high volume flow such as Payroll. Invariably, bulk payments are organised and controlled in discrete files, and this provides rather different control and security requirements than are posed by single payment transactions.
Effective TMS and stand-alone solutions offer the necessary flexibility for batches and files of bulk payments to be managed in full compliance with corporate finance policy. This flexibility extends to the definition and operation of the security environment, which can (and does) vary quite radically between companies. The underlying requirement is for the flexible definition and enforcement of rules that precisely fulfil policy mandates – which is essential in this most sensitive of business applications. In practice, the detailed approval process for batches and files will involve the authentication of the signers who are permitted to validate, authorise and release items, and this requires that complex sets of company-specific rules can be defined and effectively enforced. Some companies impose complex hierarchical structures of signer authority, reflecting the management of variables such as transaction size, currency, beneficiary and business purpose. There are further complexities such as payment routing (finding the most cost effective route that will deliver on time) that need to be accommodated to achieve a best practice payments management solution with the practical boundaries of today’s operating environment.
Initiatives to standardise payments and financial messaging have occurred regularly, and there is evidence that progress has been achieved, especially through the slowly growing corporate adoption of SWIFT and the emergence of SEPA – the Single European Payments Area. Payments management has evolved to meet increasing stringent regulatory, audit and user demands over security, transparency and flexibility, and will surely continue to do so.