Robotics in treasury | KPMG | SE

Robotics in treasury - when the bot handles the overdraft

Robotics in treasury when the bot handles the overdraft

In the age of digitisation, establishing system-based workflows for the purpose of mapping end-to-end process chains takes on a whole new dimension in light of digitisation, however - partly due to the increasing pressure to automate everything from individual process steps to entire workflows, and partly due to the technological innovations in the necessary automation tools (bots) that enable repetitive manual tasks, normally performed by employees, to be automated.

1000

Partner, Head of Treasury & Investment Management Team

KPMG i Sverige

Kontakt

Relaterat innehåll

Don't worry, the term "Treasury Robotics" doesn't mean monstrous machines with massive clawed arms are invading the finance departments of this world, gradually taking over activities from liquidity planning to accounting and making human workers redundant. In modern parlance, a robot is simply a piece of software that performs automated tasks within or between existing systems. So just like a normal employee, but much faster and without making mistakes. In theory, at least.

Robotics Process Automation - new wine in old skins?

In the broadest sense, "Treasury Robotics" means the computer-assisted automation of treasury processes. So-called RPA (Robotic Process Automation) is not actually new, even in financial and treasury processes. What CFO would deny working constantly to create optimised computer-assisted workflows that offer maximum efficiency and effectiveness in his or her area of responsibility? In the age of digitisation, establishing system-based workflows for the purpose of mapping end-to-end process chains takes on a whole new dimension in light of digitisation, however - partly due to the increasing pressure to automate everything from individual process steps to entire workflows, and partly due to the technological innovations in the necessary automation tools (bots) that enable repetitive manual tasks, normally performed by employees, to be automated. In treasury, for example, wherever systems are not yet fully integrated due to a lack of interfaces (e.g. the intentional separation between the Treasury Management System and General Ledger) or where data has to be consolidated and processed manually (e.g. the compilation of budget forecast figures or the creation of a comprehensive set of treasury reports). It is important in this context that implementing software robots should not require significant modifications of the system landscape, as they can normally be integrated into the existing systems. There are downsides to this, of course - issues like system availability and performance spring to mind. So if your TMS is very slow, the bot will have to wait until the reports, whose data it would actually like to process right away, have been finalised. As such, all the systems and processes in the ideal system landscape would already be fully integrated - this would make bots that move data between systems redundant and thus just an interim step.

The first generation of bots have already been deployed

But this ultimate stage of the system landscape's technological evolution - i.e. the fully automatic, integrated mapping of end-to-end processes - is still a long way off for most companies. So the first thing to do is take a look at the technical possibilities with regard to automation available today and which are suitable for use in treasury in particular.

A prerequisite for the use of robotics and respective bots are rule-based decision-making algorithms. This naturally means that the processes that can be automated are first and foremost those that involve routine tasks based on set rules - and this can be done already today. This first level of automation is thus aimed at speeding up repetitive tasks; treasury-related examples include the distribution of master data between different systems or the automation of the reporting function and associated plausibility checks. The same applies to other rule-based activities, such as manual cash pooling or identifying and preparing FX exposures from disparate data sources. Common to all activities at this first level is handling structured data. Consequently, one of the prerequisites for using robotics in treasury is the availability of this information in digital form. Even the smartest bot couldn't manage to retrieve a file from a filing cabinet. For everything else, there are suitable solutions available on the market that, for a relatively minor investment, are comparatively simple to design, quickly tested and rolled out. It is quite possible to speed up processes by 80-90%.

The tasks at the next level become more interesting when they involve implementing augmented process automation and steadily introducing technical cognitive capabilities for decision support. This allows the second generation of software robots to deal with more complex tasks and induce a self-learning effect through the use of increasingly unstructured data. In these areas in particular, there are many possible applications for treasury too: in cash management, for the settlement/clearing of (unknown) account statement items, and in financial transaction fraud detection where software bots can be used to help identify potentially suspicious transactions. In both cases, the bot learns from the recognised patterns - here, the allocation of cash flows on the account statement, there, the identification of fraudulent payments. Corresponding pilot systems are at the market launch stage, so the use of specific applications on a broad scale here is not far off either.

The third level represents the ultimate in terms of automation, though: intelligent cognitive automation. This is where the bot not only learns; it thinks. This effectively means the integration of artificial intelligence processes and methods in order to map more complex decision-making processes or make sophisticated forecasts (e.g. automated liquidity planning/FX exposure planning). The bot generates projections of the exposure based on a variety of data sources, including unstructured ones (news, Twitter, ERP, TMS, market data etc.), which can then be used recursively in order to improve forecast quality. Ultimately, the key issue here too is the overall architecture, i.e. where is the information to be processed coming from, how is it being made analysable (keyword big data/data lake), and how do the various technologies ultimately work together in the extremely analysis-heavy subject areas? This is no longer about increasing the speed of processes, but automatically making complex decisions with corresponding implications for the beneficial impact of using robots.

So what is left for the treasurer to do when everything is running automatically?

The faster the pace of development of the above-outlined levels of robotic applications in treasury, the more salient the question of the human factor becomes in the context of software robot deployment. There's hardly a treasurer that will complain about standard processes being performed by technological pixies. But does the same apply to more complex tasks? Are jobs in the financial department at risk? Will the treasurer himself eventually be replaced by a bot?

A counter question: would you take a flight in a self-flying aircraft today? The situation is similar when it comes to automation in treasury. The key question in future will not be whether it is possible to implement the respective robotic scenarios or with what technological solution. There will be technical solutions for all types of processes - from standard procedures to complex analytical decision-making scenarios. Guaranteed. If not tomorrow, then in a few years at the latest. The strategic question that all CFOs and treasurers must answer for themselves concerns the appropriate level of automation and its management in the form of controlled intervention by the responsible persons. The conceptual basis behind this is the principle of "management by exception", i.e. every software robot must be capable of recognising predefined exceptions or exceeded thresholds within the processes it is monitoring. Whether it concerns financial transactions, cash management or analysing complex hedging processes - the decision as to when a particular situation is treated as an exception is down to the bot. The feeding of bots with the "exception handling" guidelines, the point at which and under what conditions an emergency stop is built into the process, will and must still be the result of deliberation by a human in future too.

Kontakta oss

 

Offertförfrågan

 

Skicka