What do you do if the TMS doesn't work? | KPMG | DE

Business continuity in Treasury – what do you do if the TMS doesn't work?

What do you do if the TMS doesn't work?

Tips and tricks to handle TMS breakdown


Related content

FTM Bildwelt: Haus im Schnee

It's 15.30 on a Friday afternoon in the back office of a Treasury department at an international German industrial company: the deposit capital for the new subsidiary in the US needs to be transferred today. All signatures are in place, the USD payment recorded in the Treasury Management System and the Head of Treasury issued the final release into the system for the transfer of payment to the bank just a few minutes ago. Shortly before the end of the principal bank's cut-off time, beads of sweat start to break out on the forehead of the responsible back office employee. Instead of seeing the usual bank confirmation statement in the form of a green light next to the payment on the screen a few seconds after payment release, there is nothing at all. A technical problem? Did the Treasury Management System even transport the payment to the company's own SWIFT gateway? Is the SWIFT gateway possibly unavailable at present? Is there a processing problem at the bank? And if a problem really is found, is it possible to remedy this quickly or do you need to find an alternative payment method using e-banking or fax necessary at short notice?

The one who is able to keep his/her nerve and to have competent and rapidly active technical support, with transparency over possible sources of error along the entire Treasury process chain, as well as relevant instructions and documentation in reserve as guidance for such emergencies is indeed fortunate in such a situation. It is not always small incidents relating to the Treasury Management System, such as a payment that is not forwarded, an account statement that is not imported or an FX transaction that was executed on an external trading platform but does not appear in the in-house system. What is to be done if a more extensive scenario really does materialise: when entire systems fail in computer centres or workplaces are simply not accessible for Treasury? Are plans on hand for such situations, are all employees aware of these and – equally important – are they regularly reviewed and updated?

Globally networked organisations are exposed to virtually an infinite number of threatening scenarios that can be monitored or limited to a certain extent but are partly also not foreseeable. Unfortunately, the second category is increasing in significance – from natural catastrophes, through technical and human error to deliberate attacks of a cyber-crime nature. Plans and precautionary arrangements for risk provisioning are thus necessary both on a professional level and in the technical infrastructure. These packages of measures are usually covered by the overarching term "business continuity" (from the user perspective) or "disaster recovery" or "service continuity" (from the IT perspective). On the one hand, the issue is to prevent possible catastrophes or emergency situations and to reduce the probability of their occurrence in keeping with risk mitigation measures. The other perspective relates, in particular, to reacting appropriately to these events in order to continue the core processes through targeted recovery planning.

Thus far this is all theory as described under IT technical standards such as the ITIL process or the ISO or national BSI standards; it doesn't take account of Treasury specifics. The truth is that a globally positioned Treasury organisation, in which processes are based on a complex system landscape with a large number of internal and external connected and networked systems, can never be comprehensively prepared for all eventualities. As this would mean continuity in a catastrophe case for all sub-functions, units and countries. Fail-safe operation from the connection of external trading platforms through to the interfaces in all local accounting systems – that would mean achieving the unachievable. From the Treasury perspective, there are thus some initial elementary considerations of significance when it comes to finding an approach that takes account of the particularities of Treasury processes and respective systems.

• What is the general strategy of the entity in terms of Business Continuity Management? The Treasury's overall plans are incorporated from this point through to the issue concerning which failure scenarios even require a Treasury emergency operation.

• Which general conditions are set by the IT and/or IT operator(s)? Systems in Treasury are not islands but embedded in a complex basic infrastructure composed of hard and software in nested network topologies. All this requires coordination if the concern is to design fail-safe operation. High-availability demands of trading and payment systems are completely futile if your IT provider does not guarantee the same services for the underlying networks.

• A complex distributed and less manageable system landscape for Treasury already in productive operation cannot be designed to be effectively fail-safe. One has thus to begin with the optimisation of "first" architecture. The keyword here is centralisation in a uniform platform through to use of cloud services in order to minimise the technical effort for the "second" environment - namely emergency operation.

Business impact analysis in Treasury: what needs to be secured?

Two determining factors are the guiding principles for the generation of a Treasury-specific Business Continuity Plan (BCP): availability and efficiency.

IT technical options ought not to be the deciding factor, rather demands on availability and the reliability of time-sensitive business processes in Treasury, such as payment transactions or external trading with financial instruments, are decisive. The identification of precisely these processes ("vital business functions") and their measurement in terms of potential damages in the case of failure determine their criticality and are designed to answer one key question: what is the maximum tolerated period that conducting processes can be forgone. You are probably already beginning to consider what you could forgo and for how long: the supply of cash forecasts for subsidiaries, market data, bank statements? How do you generate payments without the system? How do you close open futures positions without a trading platform?

This admittedly simple presentation of one of the thoroughly complex business impact analyses of processes in Treasury in practice is nevertheless the decisive step in establishing a comprehensive contingency plan: first, the identification and evaluation of critical processes is primarily the responsibility of Treasury, and secondly, as all other steps – in particular IT technical steps – are based on this analysis. Issues of possible threats, risk mitigation and security needs, particularly for time-sensitive Treasury processes, logically lead to greater investment needs to protect availability. This is where the second guiding factor comes into play: the efficiency of requirements needs to be ascertained to achieve the best possible balance between investment and risk tolerance. Naturally your IT can safeguard the liquidity planning tool so that it can be restored within 60 minutes of database failure. But does that make economic sense in view of the time sensitivity of the process? And naturally your front office would prefer to use the trading system without interruption so that no unplanned P&L effects occur. But is this access really necessary on a 24-hour basis or could it be reduced to peak periods of the trading day?

Avoid just producing paper: regularly test and train employees

Congratulations! You have managed to produce a comprehensive Business Continuity Plan for your global Treasury organisation. The CFO and CIO have prepared a budget, all emergency processes are documented, the Treasury Management System is operating in redundant mode by IT, responsibilities and escalation steps for certain scenarios are defined, emergency workplaces (where necessary) are provided for your essential resources and, if the occasion does arise, you have arrangements in place for emergency operations with the most important banks.

The point of practical implementation is the point at which the cardinal error emerges at many companies. Once documented and technically established, most Business Continuity Plans, including associated technical disaster recovery environments, remain in the virtual desk drawer of the persons responsible. This is a fatal error, especially for the Treasury function. Your Treasury Business Continuity Plan includes (ideally) scenarios, processes, technical processes and manual workarounds, reporting channels, escalation steps and contact partners in the specialist area, in IT and at your external counterparty. By its very nature, this needs to be updated regularly. It would be extremely annoying if, for instance, a failure to your SWIFT service bureau at night was determined by automatic monitoring of the connection to your computer centre; however, owing to a change of contact, your contact could not be reached and you were to find no account statements or financial status in your Treasury Management System the following morning.

In addition to the requirement to be up-to-date, reviewing and testing emergency measures are top priority for a BCP. Only this can ensure that alongside operability of technical emergency systems, your staff are also prepared for emergency and have an awareness and understanding for the established processes anchored in their mindset. While not all events and failures can be avoided, at least the Head of Treasury can sleep easier and back office staff no longer need to panic shortly before cut-off times.


Source: KPMG Corporate Treasury News, Edition 50, December 2015

Author: Michael Baum, Senior Manager, michaelbaum@kpmg.com

© 2017 KPMG AG Wirtschaftsprüfungsgesellschaft, ein Mitglied des KPMG-Netzwerks unabhängiger Mitgliedsfirmen, die KPMG International Cooperative (“KPMG International”), einer juristischen Person schweizerischen Rechts, angeschlossen sind. Alle Rechte vorbehalten.

Connect with us


Request for proposal