3 Considerations for Identifying RPA Projects in Banking

Published By R-Path Automation

Published On August 14, 2019

If you’re beginning to wade into the waters of Robotic Process Automation or RPA, you’re not alone. According to Gartner, RPA software grew 63.1% in 2018, to $846 million, making it the fastest-growing segment of the global enterprise software market. Banks — with many legacy systems — are leading the way in RPA adoption. In one striking example, financial services organizations make up 51% of RPA adoption in Canada.

What Kinds of Opportunities are RPA Projects Driving in Bank’s Growth?

Banks lead in automation for a number of reasons. Systems are both legacy and mission-critical, making wholesale replacement risky. People are heavily involved in many tasks, and the regulatory environment adds to the number of processes that need to be performed. Finally, consumers demand digital banking, increasing requirements for banking speed and agility.
These drivers of automation have enabled RPA to penetrate huge areas of bank operations, including:

  • Opening and closing accounts
  • Processing loan applications
  • Performing back-office functions for trades
  • Ensuring compliance and KYC requirements are met
  • Automating accounting processes and checks
  • Performing risk management analyses such as stress tests
  • Resolving customer service requests
  • Automating HR tasks

How do You Identify Processes and Tasks That Are Best Suited for RPA?

This list of commonly-automated bank operations is more a list of destinations than a roadmap for your RPA initiative. To get started, you need to first identify possible areas for improvement with optimal “scores” in three categories: repetitiveness, potential KPI improvements, and project scope. We’ll discuss each category in turn.


1. Highly repetitive tasks

RPA articles inevitably bring up “repetitiveness” as the primary characteristic of tasks and processes that should be automated. But what does repetitive mean, specifically? Here are some considerations:

  • Paper to application and application to application — Data entry, whether entering information from paper forms and print outs or from one system to another, is a classic RPA use case. Applications for loans or new accounts are great examples of data entry tasks. Of course, even new digital banking applications may seem automated from the customers’ perspective, but the data collected on a website may need to be manually entered into a back-end system.
  • External systems checks — Credit checks and other data collection tasks involving external systems are a part of many banking processes, often required by regulations.
  • Comparisons of values and conditional checks — Ensuring that values match in more than one system or dataset corrects errors. Finance department tasks like bank account reconciliation and accounts payable are examples of this sort of repetitiveness. Other examples are quality checks; finding and closing zero-balance accounts is an example of scanning for a condition in a system and automating action once a condition is met.
  • Required steps and prescribed options — If a task or process has steps that are required — either by regulation, policy, or practice — then this activity may be appropriate for RPA. The steps should be the same or have limited variation each time that they are executed. If there are options in the process, each path should also have defined steps.


2. Meaningful KPI improvements

Another category to consider is the expected upside in cost or time reductions, improved quality, top-line improvement, and/or increased customer satisfaction. Whether you choose loan processing or trade execution, certain processes are more important for your business, and there are examples available to help you benchmark expected returns. Keep in mind that big initial wins don’t come by automating whole processes. See this post on the 4 Stages of an Effective RPA Initiative.


3. Ideal project scope

The last consideration is to take stock of your readiness and select RPA projects that are right-sized. A tactical project that improves the lives of employees is entirely appropriate for a pilot, when a primary objective is to garner support for RPA within your organization. In an early stage of RPA readiness, it can be disastrous to take on a large, complex process.
Consider these aspects of a project when assessing complexity:

  • How many people does the process touch? Does the process span multiple people and divisions? Have you considered the human aspects of RPA adoption? How many systems are involved?
  • How mission-critical is the process? Have you tackled easier tasks and processes before trying your most important process for creating value? Do you have the expertise and buy-in to handle a high-profile project?
  • How hardened is the process? Do you really understand the process? Is the “happy path” scenario assumed, when in reality, exceptions are the norm?


As you get deeper into RPA, tactical wins lead to more complex optimizations that touch more of your organization. Selecting the right RPA projects, particularly at the beginning, helps you to navigate to greater efficiencies to edge out the competition and ultimately serve customers better.

Image Source(s):  Photo by Jopwell from Pexels