RPA - The miracle solution for incumbent banks to bridge the automation gap with neo-banks?

Hypes and marketing buzz words are strongly present in the IT landscape. Often these are existing concepts, which have evolved technologically and are then renamed to a new term, as if it were a brand new technology or concept.
If you want to understand and assess these new trends, it is important to reduce the concepts to their essence and compare them with existing technologies, e.g.

• Integration (middleware) software ensures that 2 separate applications or components can be integrated in an easy way. Of course, there is a huge evolution in the protocols, volumes of exchanged data, scalability, performance…​, but in essence the problem remains the same. Nonetheless, there have been multiple terms for integration software such as ETL, ESB, EAI, SOA, Service Mesh…​

• Data storage software ensures that data is stored in such a way that data is not lost and that there is some kind guaranteed consistency, maximum availability and scalability, easy retrieval and searching of data, maximum security…​ Again there are multiple evolutions in this domain, from simple file storage to SQL databases, up to no-SQL databases and object storage services all the way up to decentralized Blockchains.

• Software development services try to build as quickly as possible software, according to the business requirements. Also here multiple evolutions have allowed to significantly improve the productivity of software engineers, via different levels of abstraction, i.e. from low-level assembly code, up to higher-level programming languages (with different concepts like imperative versus declarative languages, object-oriented versus functional programming languages, script languages…​) all the way up to the Low- and No-code tool which are becoming more and more common.

One other trend, which falls in this category, is RPA, short for Robotic Process Automation, which allows to automate simple tasks via virtual software robots and uses a combination of screen scraping, workflow automation and artificial intelligence to accomplish this. With double digit growth figures in the last couple of years and predictions by leading research companies stating that RPA will soon be used by almost half of the large corporations and can impact the job of up to 10% of the worldwide worker population, this trend is hard to ignore.
Nonetheless people working in IT won’t hesitate to say, that they have been automating tasks for decades, as this is exactly what a programming language does, or what Excel macros have been doing for years.

The difference is that RPA is aimed at business people, but haven’t we heard that argument before as well? Almost 10 years ago I was exploring BPMS for a large bank. One of the aims of BPMS was that business people would be able to model and manage the business processes.
Today, the Low- or No-Code platforms, also attempt to make it possible for business people to build "simple" applications.

So where is the difference? As always the difference is in the type and level of abstraction. RPAs are abstracting away the complexities of programming languages, by only providing a subset of programmatical options, required to automate manual tasks (such as logging into applications, copying and pasting data, moving files and folders, filling in forms, scraping browsers, extracting data from documents…​) in an easy way. But as with any level of abstraction, (prescriptive) choices have been made, limiting the flexibility (i.e. level of control) for the "programmer".

For years large organizations have dealt with shadow-IT, i.e. mainly sales and marketing departments that bought and/or built all kind of tools out of control of the IT department. Usually these shadow-IT organisations find their origin in the lack of speed, flexibility and available resources in the IT organization, but often backfire at a certain moment in time, due to the lack of good IT practices (like security, source control, Quality Assurance via different test environments, DevOps principles…​), meaning that such tools arrive soon at their limits.
It seems that with the rise of Low- and No-Code tools and RPA, we try once again to bypass the IT departments, while avoiding (or at least postponing) the associated issues.

We should therefore pose the question:

• Is such a shadow-IT desirable, given all medium- to long-term downsides such tools give? Shouldn’t we work on making existing IT departments more agile and deliver more and faster, so that we don’t need such tools?

• Do these tools really live up to their expectations? Just like I have never seen any business person, changing directly BPMS processes, I find it hard to believe the average business person setting up and maintaining (complex) RPA processes. The best proof of this paradigm is the number of consulting firms providing RPA services. If anyone without IT knowledge can setup RPA flows, it is strange to see that these external specialists are so desired.

Don’t understand me wrong however. RPA, even setup by external specialists (such as BrightKnight), can unlock enormous benefits for organizations, as they can reduce manual workload enormously by allowing to process data much faster and 24/7 (allowing to reduce resource cost and reduce lead time of business processes), without errors (increase quality) and fully confidential. Furthermore, they can make the boring, non-motivating work obsolete (take the robot out of the human), allowing employees to focus on tasks which give more satisfaction.
But let’s keep in mind as well, that it’s a temporary short-term patch, which often needs to be setup by external specialists. However, this "limitation" does not reduce its added-value. RPA projects can often be setup fully independent (as often no change is required to the existing legacy applications to automate tasks) and in a matter of a few days. With such short implementation times, we can easily find projects with pay-back periods of only a few months. As an organization, you wouldn’t want to miss out on such a business opportunity.

Despite this business opportunity, the above intro shows also the bottlenecks and pitfalls of such a tool:

• Don’t put too much business logic in an RPA tool: as an RPA tool is a quick fix, it should be considered as a short-term solution, meaning the logic inside the tool should be as limited as possible. If logic becomes too complex (too many systems involved, too many decision points or too many exceptions), it would be wise to consider pushing it back to the IT department, where it can be implemented using existing IT standards.

• Only implement processes in RPA, which are highly manual, always the same (= routine, repetitive tasks) and require little to no human interpretation or judgement (strict, pre-defined rules with few to no exceptions). Typical task examples include data entry, reconciliation, data transfer, report generation, data processing, archiving, data mapping…​ Within financial services specifically, common use cases include client onboarding, mortgage approvals, invoice processing, loan processing, account opening and closing, trade execution and KYC.

• Only implement RPA processes on top of stable (often legacy) underlying applications. This to avoid having to continuously change the RPA process if the underlying applications change (as even a small change can result an RPA process to stop working). Furthermore, a modern, fast-changing application allows most likely fast and agile delivery by IT departments meaning that RPA tools become obsolete (as automation can be directly built into the application).

• Most RPA implementations are using one of the 3 large market players, i.e. UiPath, BluePrism and Automation Anywhere. This means a strong vendor lock-in, re-enforcing the need to keep it a short-term tactical solution.

• As with many data-driven automations (applies also to machine learning), the principle of garbage-in, garbage-out applies also here. When the quality of data inputted in the RPA process is not good, the RPA process will just deliver bad outputs at a faster rate.

• Even if business partners with external specialists, an involvement of IT will still be required or at least desired. Typical roles at which IT will need to be involved are: implementing some minor changes to the legacy applications to facilitate the RPA process, security setup (such as setting up technical users for RPA to connect to the underlying applications), a mechanism to inform the RPA tool when underlying applications are not available or are evolving, logging and monitoring of the RPA processes, setup of the infrastructure for RPA processes to run on…​ If IT needs to be involved anyway, it is important to assess if a real automation (directly in the underlying applications) is not an option as well.
  This strong cooperation between IT and Business is important to convince all parties of the added value and to tackle as much as possible any concerns with regards to security, data protection, data quality…​ This can however be a pain point, as this lack of good cooperation is often one of the reasons for business to dive into RPA in the first place.
  In most large organizations the lack of good cooperation is often the reason why so many processes remain so manual. In my career in the banking sector I have seen dozens of examples where time-consuming manual actions done by operation departments could be easily automated (or at least supported by semi-automation) in a matter of hours, but as parties don’t communicate directly and as demands need to go through a tunnel of prioritization (making small cost-reducing improvements always to fall out as the first) they are never picked up.

The most important to remember is that RPA should always stay a temporary solution (a patch on a missing automation). The ultimate goal should still be a real STP (straight through processing) process, which is fully automated and integrated at its core (i.e. the underlying applications) via APIs which allow machine-to-machine communication. Tools like business process management systems and workflow solutions can help with that. Also interesting to explore are tools like crowd-sourcing marketplaces which allow to outsource simple micro-tasks to an army of workers (e.g. Amazon Mechanical Turk, MicroWorkers, ShortTask, RapidWorkers, CrowdFlower…​). Such marketplaces give the impression of automating tasks, as task execution becomes highly scalable and 24/7 available often at a fraction of the cost. Furthermore, tasks can be requested via a standardized API and results comes back in a standardized reply, just as if the task would be executed automatically.

Also interesting to consider is the analogy with well-established testing automation tools, like Selenium, which are also used to automatically execute user tasks, in order to automate regression testing, execute load tests and act as a robot in production systems to continuously probe the availability of the system. As RPA tools execute very similar tasks there is a strong overlap. Nonetheless there are also quite some differences, as the tool set differs. Test automation tools focus strongly on UI and comparing the obtained results with the desired results. Furthermore, they are good at simulate a large number of parallel executions of the same task and generating test reports in case of failures.
RPAs are not only focusing on UI and have more rules to manipulate the type of actions/inputs the bot should be doing.

The combination with AI can also give very interesting results, as it allows the RPA process to adjust to changing user interfaces or changing data. Furthermore, together with OCR, image and speech recognition systems and Natural Language Processing (often also based on AI), it can extend its scope to treat also unstructured data. The combination of RPA with AI is nonetheless brand new and thus still immature. Furthermore the use of AI brings us even further from a business person setting up and maintaining the RPA process.
As a general rule, the more powerful and advanced the RPA tool is setup, the more it becomes a real IT tool, which raises again the question if adaptations in the core underlying applications are not more opportune.

In the financial services industry, which has a lot of manual and administrative tasks and is still very dependent on large, complex and very difficult to modify legacy systems, RPA is a much welcomed evolution in this industry. Examples are American Express using RPA to automate ticket cancellation and reimbursement or Deutsche Bank using RPA for automating part of the credit decision process.
RPA can in any case bridge the time gap for incumbent banks till they have completed their digital transformation (to cloud, micro-services, agile…​), giving them additional time to catch up technologically with neo-banks and other Fintech players.