Payments management might appear to be a fairly straightforward, although clearly important topic; in reality differences of scale, geographic location and treasury department mission and policy result in marked differences being encountered. This is reflected in the demands imposed on supporting treasury and finance technology.
Payments management is marked by an often fuzzy boundary between treasury and finance; one reason why the subject is less clear-cut than might be supposed by the casual observer.
Treasury management system (TMS) payment modules originally developed as a logical extension to general treasury management functionality as the values and benefits of straight-through processing (STP) treasury workflows achieved general acceptance. Previously, 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.
Generating and executing a payment is a highly sensitive and risky treasury process, especially given the relatively large size of the typical treasury payment. The workflow involved clearly merits high levels of transparency and control to secure and clearly document all relevant actions and events.
It might help to summarise the typical range of pure treasury payments that might be created and managed by a TMS for a treasury department’s operations. The scope generally extends to deposit placements; loan, bond, medium-term note (MTN) and commercial paper interest payments and maturity redemptions; foreign exchange (FX) and commodity deal openings and closings; option premium payments; interest rate swap interest payments; forward rate agreement (FRA) and futures transaction settlements; bond, equity, money market instrument and other investment purchase transaction settlements.
TMS payment modules construct payments for settling 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 used mostly by a corporate through a specialist service bureau. A common multi-banking arrangement is where 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 appear daunting, and the reasons for a specific choice often include bank relationship considerations, cost and efficiency issues. An added factor in solution selection is the solution providers’ established capabilities in supporting and resolving problem issues.
Payment messages created or processed generally fall within standards such as the SWIFT MT 10 – it is the responsibility of the TMS to construct each message in compliance with the standard used by the bank(s) in question. It should be noted that these standards are not, in practice, absolutely consistent. The effective TMS needs sufficient flexibility to accommodate variations from bank to bank, which can be subtle. The TMS may also have to handle multiple payment system message standards, protocols and security requirements; for example, SWIFT, automated clearing house (ACH), Fedwire and Clearing House Automated Payment System (CHAPS) might be needed.
The security imposed on payments workflows is rigorous, while the 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.
Reason for doing this via a TMS include:
• Dealing staff are not permitted to create or change settlement instructions, which are the responsibility of a distinct set of individuals from the finance team.
• Similarly, 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, time stamp and clear identification of the individual responsible.
• The TMS workflow will monitor attempts to breach the defined rules and alert nominated managers if any breach is detected.
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 100% transparency for all payment events.
The simplest payment execution process found in older treasury technology is for the TMS 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, with any subsequent problem issues researched and corrected manually.
More Sophisticated Payment Workflow Management
SWIFT has led 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 detail and any detected errors to be corrected – with manual intervention kept to a minimum. The information exchange includes positive and negative messages (acknowledgements and non-acknowledgements, or ACKs and NAKs) and the transmission of diagnostic codes that can be interpreted and acted on by the TMS. In some solutions, multiple levels of the acknowledgement message type are set; enabling sophisticated tracking, analysis, repair and reporting.
The availability of such transparent information exchange has substantially enhanced the quality of corporate treasury payments management in recent years, enabling intelligent interaction between bank and TMS, facilitating faster error research and correction. Payment processing is 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 small numbers of payments when they function as group treasuries, simply concerned with executing a few – usually substantial – foreign exchange (FX) hedges and occasional loans and deposits, as compared with large global or regionally centralised operations performing treasury operations on behalf of a network of subsidiaries, 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. In such situations payment workflows may still be paper-based and require the re-keying of payments into banking or other specialist software. There is increasing management and audit pressure to fully automate such workflows; the cost being 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 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 various reasons. Often, these are high value ‘payments on behalf of’ (POBO) a corporate operating unit, made through treasury in compliance with the organisation’s finance policy. The general benefit of this approach is immediate visibility of the outflows to treasury, optimising cash visibility and hence, potentially, the quality of 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 must fulfil requirements such as payroll execution and the payment of commercial invoices such as rent and operating expenses.
In some situations, 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 (SSCs), and especially in the phenomenon of payment factories.
Payment factories have historically been seen as the preserve of major organisations; but the benefits of operational standardisation and streamlining, combined with enhanced control and visibility of cash are now affordable to 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. Traditionally much, especially older, TMS technology has not handled relatively high volumes of payment transactions that efficiently as it was not designed for this type of function.
So what constitutes ‘high volume?’ This varies from system to system, but today’s threshold lies somewhere between 2,000 and 5,000 payment flows daily. When overloaded with payments, TMS performance can decline exponentially. The reasons are complex and concern both system and database architecture; but from the treasurer’s perspective extreme volume testing is an essential element in evaluating a payments factory solution. ‘Extreme’ in this context means running through something like three 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 efficiently. Other systems require supplementing with a stand-alone payments management solution designed to handle high volumes well and provide adequate capacity. As noted earlier, this is a surprisingly complex subject, and locating the optimum solution in a given situation can prove challenging.
There are additional factors involved when comparing TMS and specialist payment solutions for bulk payment management.
As mentioned, 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 enterprise resource planning (ERP) and accounting systems, and often merge 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 vary radically between companies. The underlying requirement is for 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 involves authentication of the signers who are permitted to validate, authorise and release items. 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 must 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 of progress, especially through the slowly growing corporate adoption of SWIFT and the emergence of the single euro payments area (SEPA). Payments management has evolved to meet increasing stringent regulatory, audit and user demands over security, transparency and flexibility, and will doubtless continue to do so.
Despite all the automation and improvements that digital banking has the potential to achieve, customers and their needs still form the very core of the banking sector.
Politicians have united in urging the Reserve Bank of Australia to lend its backing to the digital currency by officially recognising it.
In order to survive, banks must get ready for an open application programming interface-led economy and develop superior value propositions for their customers.
The banking industry will meet the challenge of the new era introduced by Europe’s Payment Services Directive, but it is up to its individual members to determine whether they sink or swim.