In an increasingly saturated market, the need to stay competitive spurred banks to look at Robotic Process Automation (RPA) as an effective solution for delivering an optimal customer experience, keeping costs as low as possible, and also maintaining security levels. Lately, the RPA has become the way to go for the financial service industry in order to reduce costs and transition from services-through-labor to services-through-software. Robotic Process Automation replaces various manual workflows. It is more accurate and faster and proved its potential in reducing monotonous or error-prone work, and streamlining processes. Companies looking to improve these aspects start on the right foot by focusing on those processes that are relatively simple, repeatable, high in volume, and require a great deal of dull work.

We must note though that if qualitative thought is required, RPA should not be involved. Organizations must also be cautious as this technology isn’t ideal for every scenario. A poor fit could lead to project failure and set back a company’s RPA initiative for long periods of time.

Not just a solution for busy work, RPA is a solution for avoiding costly mistakes, like the ones in the financial sector. A properly designed RPA robot is able to take into account several types of errors thrown, new elements being present, and other types of bad scenarios, and can redirect to a previous step if needed. Considering it’s a tool meant to complete a task, not necessarily a testing tool, bad case scenarios should always be taken into account when designing the robot. However, each bad case scenario can be used to generate a log and keep track of what went wrong during its execution.

Data show that eliminating human intervention in routine tasks and decision-making dramatically improved operational efficiency. To put it bluntly, financial services personnel spend too much time on tasks that could easily be handled by RPA technology faster and more accurately and, of course, cheaper in the long term.

The most important uses of Robotic Process Automation in the banking system include customer service, compliance, credit card and mortgage processing, fraud detection, and account closure, to name just a few. When drawing a line at the end of the day one can observe that impact on everything, from performance and efficiency levels to staffing issues and operational costs are greatly improved.

Taking things to the next level requires coupling  RPA and AI in order to resolve complex activities that usually involve human intelligence or complex decision-making. The results are seen in financial institutions that achieve a lean operation and second to none customer experience, while at the same time remaining competitive in an ever-changing environment.

An example of how it’s done

Tremend’s tool of choice when it comes to RPA is UiPath, a high-quality product of one of the fastest-growing Romanian companies, which enables us to create highly complex frameworks. Our team attended to its own needs and created a robot to smooth the day-to-day activities. This robot was the starting point for creating one for the banking activities.

The robot can be operated by different individuals on their machines and if the organization requires it, this could also be adapted to be executed via Orchestrator, UiPath online platform, for a more centralized and easy to manage infrastructure. In this version, it reads an excel file and looks for rows with the “Pending” status. In a previous version, we also had a workflow that looked for email requests and inserted the new request in this excel file.

If we find at least one “Pending” status, we then open the web pages and start the checks. The same best practices which are used in developing a testing automation framework can be used in an RPA workflow/flowchart, IE: keeping functions fairly simple and easy to read, adding comments and explicit names for each step, small and reusable functions, avoiding duplicate code and so on.

If we “type” the address (simulating keyboard input, not just string insertion, thanks to the various input types available in UiPath) in a new tab and then click the Go button, we simulate a real person and the Captcha doesn’t appear. But in case of this behavior changes, we also look for the Captcha element each time we refresh the MFinante page and we prompt a dialogue box if it’s present, pausing the process until the Captcha text is inserted. In case the Robot is placed inside a VM, we could send an email notification when it appears, so any team member could reply to it.

Since we started the browser pages in a different workflow, we begin the ONRC Checks workflow by checking if the page is opened. If not, we open it from that workflow. If it’s present, we click on its specific browser tab. After that, we refresh the tab and check the login status. If it’s required, the robot logins on the page using the account and password supplied by the config.json file, since this version is meant for local machine use. If the process is directed via the Orchestrator platform, more secured user account data can be implemented. We’ve used this approach to each individual can set his specific account without needing to sort through the robot itself, he just needs to edit the .json information.

After the “page open” and “user logged in” checks and actions, we then check the page’s URL. If it’s not the one we need, due to a redirect caused by the login or a session timeout, we then click on the specific page button. We then search the company we want to check by its specific ID and check if the company has an ONRC file present. If it does, we return that as a failure reason.

Same as ONRC Checks, we check if the page is open or not. The page refresh is also present in this workflow. This page doesn’t require a login, but it’s the one where the Captcha might appear or not. After the refresh, we check if it’s present and act accordingly (detailed in the “Starting the process” step).

We then search using the business’s specific ID, and access that business’s page to start the actual checks. We verify if the name listed in the request is the same as the one displayed. Since it may be just a misspelling of the name itself causing a fail, we list as fail reason both the displayed name and the one mentioned in the request. That way when a person goes over the log, he can see if it’s actually a different company or not, or further investigate the cause. We then check if the company is still active, and after that, we verify its activity domain since some banks don’t grant credit to a number of volatile domains. If these fail, we add them to the checks that failed.

After all the checks are done we either Pass or Fail the request. In case of failure, we mention each individual reason. These reasons are returned as Out arguments from each workflow.