Are You SWIFT Enough?

It may come as a surprise to bankers, but most companies use more than one bank for their needs. Further, companies no longer have to be ‘big’ to use 10, 20, 30 or more banks on a global basis. Yet, regardless of a company’s size and complexity some basic needs for corporates never change, only the manner in which they are executed:

• It’s 9.00am, where in the world is my cash?
• It’s 11.00am, do I invest or borrow today and in what currency?
• It’s the end of day, what should I do tomorrow to match future uses with sources while minimising my risks?

Executing the solutions to the issues above usually falls on the chief liquidity officer (CLO) (i.e. the treasurer) and the resources they command, which can include internal staff expertise, third parties (banking partners and others) and the use of various technologies.

To determine if a company is ‘SWIFT enough’ to accomplish its matching goal it is important to examine the structural integrity of processes in place, whether the resources available (i.e. capacity) are sufficient, and whether there are metrics in place to even know if success has been achieved.

Structural Integrity

Companies are organised into business units, with those in charge tasked to generate profitability. In many companies, liquidity or market risks at the business unit level is not important. The importance of liquidity and market risk is often higher at the corporate level, but the structural integrity or integration of these processes can be compromised when there are many banks and currencies in use. Also, a decentralised operating or company portfolio structure, as found in many private equity firms, may contribute to profitability but can compound liquidity management. The intertwining of these processes is further jeopardised if there are multiple financial systems or an inordinate use of older technologies like spreadsheets or even continued use of systems built for a purpose that existed in years past.

SWIFT’s one, all-encompassing, hub approach is an important step that companies should take to improve integration of profitability with cash flows. However, the one hub approach overlooks some corporate and banking environmental issues:

• SWIFT is one of many standards when it comes to sending/receiving transactions safely among most of the world’s banks. Its MT messages and FileAct abilities make it ideal for most transactions, although BAI/EDI/SEPA formatted information can compete in certain instances associated with accounts receivable (A/R) cash application or executing outgoing payroll. The idea of a universal standard is still a work in process.
• Most corporates are already SWIFT-capable through their concentration bank. Almost all banks today are capable of sending/receiving SWIFT formatted transactions for their customers as well as serving as a hub for messages from other regional or local banks. One of life’s great mysteries is why corporations have not taken more advantage of this multi-bank reporting process. Many are still content to use paper-based transactions or stitch their cash flows together using spreadsheets, emails and multiple bank websites. Perhaps lack of proper cost or risk metrics contributes to this inertia.
• Companies continue to favour many banks to minimise their funding or operational risks. Why a company uses so many banks with the attendant maze of inputs or outputs is not, strictly speaking, a SWIFT issue but many corporates feel an obligation to reward various banks they use with some business (credit, cash management, etc.). However, having too many banks means having many moving parts and increase operational risk. In a recent Financial Executives Consulting Group (FECG) survey of large multinational companies, only 35% used 20 banks or more. Better connectivity via SWIFT (or any other medium) maybe efficient, but not necessarily effective in a multi-bank situation. Having fewer banks would help as much as better connectivity.
• Managing liquidity requires managing not only cash balances but debt and investments so that the risk that liabilities will come due without sufficient ability to repay them is avoided. SWIFT by itself may not accomplish this task if cash equivalents or debt are at many financial institutions which do not use MT messages. For example, cash equivalent balances or short-term investments such as government notes or money market funds (MMFs) can be maintained in accounts at non-bank institutions or brokers. These balances may not be part of MT940/941 messages.

Multiple Financial Systems

SWIFT can serve as a powerful integrator of financial messages from multiple sources, but once delivered what happens to those messages? Another poorly-kept secret is the knowledge that many companies use multiple enterprise resource planning (ERP) or general ledger (GL) systems, each with their own transactional formats.

Best practices requires a corporation to simultaneously track cash flows and account for it by crediting/debiting a GL account, reconciling interest paid to interest accrued based on changing balances and interest rates over time, calculate foreign exchange (FX) gains/losses based on changing market rates, and decide whether to seek hedge accounting treatment. Examples include:

• Incoming transactions – most incoming transactions represent cash received in payment of outstanding accounts receivable A/R, but which GL accounts are affected? What accounting rule should be used to credit/debit a GL account based on the content and value of the message received? What format should the message and the accounting information take so that it can be promptly posted/stored to a GL system?
• Outgoing payments – before any transaction is released to a bank it must be authorised. In addition best practices calls for a proper accounting before that transaction is released to a bank. With multiple GLs, outgoing messages can have many forms which must be mapped into an acceptable MT or FileAct format and be linked to/include the appropriate accounting data
• Rates and dates – accruals, FX gains/losses and the relation of a hedge to its underlying transactions (a requirement when seeking hedge accounting) all require knowledge of what interest or FX rate was/will be used and when. This information must be embedded in the transaction for accounting purposes even if not included in an outgoing SWIFT message. Integrating this data for accounting purposes then stripping it out prior to transmittal is an important control feature for any company.

Just like a river that is composed of many tributary streams, the stream of transactions through a corporation’s systems requires each to be properly tagged, combined and reconciled internally (eg. vendor liability or debit to accounts payable (A/P) is generated at the same time a cash credit is created) to prevent a loss of control over a flood of transactions. A single point of connectivity between a bank and a corporate can help in the control process but what goes on before that transaction reaches this release point is equally important, especially in a multi-GL situation.

Proper Metrics

Because the future is uncertain, a company can only say with certainty that future, unexpected, events will occur. The ability to react in time to these unexpected events is just as important as the response itself. The use of SWIFT as a single point of entry/exit for transactions leaving/arriving at a company’s doorstep can minimise but not prevent these unexpected events. Recognising these events and executing timely and proper action requires adopting certain internal standards associated with the volume and value of transactions which are being input, processed and output.

What gets measured gets managed. Arguably, earnings per share (EPS) is one of the most well-known measures of corporate profitability. What is its equivalent for measuring liquidity or risk? There are measures for these issues (eg. free cash flow, financial leverage, etc.), but they are not as common at all levels of a company.

The use of SWIFT as a single source to power a company’s other, internal transaction processor/s requires some built in volume and value metrics if various goals are to be achieved. For example, few companies today can answer these questions:

• “How many of what type transactions did I receive/send?”
• “How much does it cost (internally and externally) to receive an incoming or outgoing transaction?”
• “How many transactions required multiple processing (i.e. is this transaction related to others requiring errors to be detected and corrected)?”

In a racecar, raw horsepower seldom wins the race. Proper brakes, steering, a transmission (i.e. connectivity) a dashboard, not to mention a well-trained driver and a race strategy, are just a few of the many factors necessary to control a global, 24/7 operating environment. To be ‘SWIFT enough’ a company should consider how the outputs from one part of its process are input to another and what controls must be available to tell it that success, as defined, was achieved.

Conclusion

If a company wishes to be ‘SWIFT enough’ it must consider that one set of outputs are another’s inputs and all must be coupled together. A proper set of metrics that measure inputs, outputs and performance quality must be adopted so that success, once achieved, is known with certainty.

A single point of connectivity between a corporation and its banks is not sufficient by itself to make a company ‘SWIFT enough’. For many reasons, companies will continue to use various financial third parties who do not use a universal message standard. Also, companies will continue to use multiple financial systems with various abilities to identify, account for or analyse their impact on liquidity and risk. At issue is the idea of ‘too much’.

This network of multiple systems, banks and businesses will continue resist the use of a single point of connectivity, but fewer points of connectivity should be a goal along with simpler networks of internal systems, better user training and greater use of more ‘purpose-built’ systems designed to mange liquidity and risk on a more frequent basis than the typical accounting period. Knowing when something happens is as important as how much it has occurred.