skip to content

We use cookies to offer you a better browsing experience, analyze site traffic, personalize content and serve targeted ads. We also share information about your use of our site with our social media, advertising and analytics partners who may combine it with other information that you’ve provided to them or they have collected from your use of their services. Read how we use cookies and how you can control them in our Cookie Disclosure Policy. By using our site, you consent to our use of cookies.


RPA in Mortgage Mythbusters

By Narayan Bharadwaj

Robotic Process Automation (RPA) has gained steady mainstream adoption over the past decade or so in the mortgage industry. But what IS RPA?

Gartner defines RPA as:

“… a productivity tool that allows a user to configure one or more scripts (which some vendors refer to as “bots”) to activate specific keystrokes in an automated fashion. The result is that the bots can be used to mimic or emulate selected tasks (transaction steps) within an overall business or IT process. These may include manipulating data, passing data to and from different applications, triggering responses, or executing transactions. RPA uses a combination of user interface interaction and descriptor technologies. The scripts can overlay on one or more software applications.”Link to reference

What it boils down to is that RPA is a technology used to emulate any repeatable and rules-based action performed by a human being on a computer, such as keystrokes or navigating between different screens or applications, to enable process automation.

While there is a very general understanding in the mortgage industry about what RPA software can do, serious misconceptions have been floated by overzealous marketers and consultants which has led to confusion in the industry about the pragmatic evaluation and usage of RPA. Let’s bust some of the myths associated with RPA in the mortgage industry:


The term bot (a short form for Robot) is very loosely used and associated with a number of automated software and hardware technologies. In the new world of automation, a lot of things are called bots but not all bots are necessarily RPA. In the context of RPA, a “Bot” is a piece of “agent” software that is deployed on a machine in a lender’s environment and works off of the system that it is automating tasks out of. An example is a bot that works on the screens and navigations on a LOS.


Chatbots are conversational software agents that deliver pre-configured responses to questions. While it is a “bot”, it is not RPA as a chatbot does not automate a workflow or a process that is executed using a series of rules-based and repeatable steps. It delivers canned responses to (mostly) standard questions. There are “bots” that automate processes like handling service desk requests (password resets, etc.), but they are a sub-set of the larger function of a chatbot and not a core process automation bot like RPA. A chatbot is “chatty.”


RPA is largely used to automate tasks that users interact with on a screen (user interface or UI). Think of the process of placing an order for a flood using a LOS which is one of the most common tasks automated by our clients using BotGenius. The user opens a loan, navigates to the services ordering section, clicks on the specific service (flood, in this case), enters the credentials, selects the product to be ordered, and submits the order.

While this is UI-based, RPA technology has matured to automate tasks using non-visual input forms such as XML or JSON files. For example, one of the most popular tasks we automate via our BotGenius RPA solution is appraisal reviews, which involves an exhaustive review of an appraisal file that is delivered via XML.


RPA software can handle complex “scripts” i.e., “code” to codify complex logic. Once again, referring to the above appraisal review example, BotGenius bots currently perform a thorough and complex appraisal review including checks for rural property, declining market conditions, PUD, private road conditions, rent comparison, subject to properties, vacancy factor, property flipping, HOA calculation from appraisal, site value as a % of value, listed for sale, deferred maintenance, seasoning requirements, etc.

Therefore, while RPA software is thought of as a screen scraping/emulation utility, built with the right technical expertise, it can automate complex tasks as long as they are rules-based and repeatable.


You shouldn’t! Unfortunately, many industry analysts and experts paint a black or white picture of RPA. i.e. if you are automating a sub-optimal process using RPA, you are stuck with that inefficiency forever and therefore you should reengineer the process first and not implement RPA!

While this is a very idealistic view, not all processes can be re-engineered simply because they depend on factors outside of a lender’s control. For example, a very common task we automate through BotGenius is flood review. BotGenius bots review a flood report, identify if a property is in a flood zone, and execute a set of follow-up actions.

In the ideal world, if the underlying LOS had data-enabled workflow automation i.e., identify from the flood report that the property is in a flood zone and then execute a set of workflow steps, then there would be no need for a human to eyeball this and perform this activity in the first place. RPA alleviates the need to perform such repeatable and rules-based tasks by emulating this human action either using the UI or direct data.

However, if and when your core systems such as LOS or servicing systems can deliver this automation, you should automate it natively.


While overzealous marketing has led to some vendors and consultants using the term “bots” liberally, LOS systems do not have bots embedded in them by default. RPA is utilized to overcome the native gaps and workflow deficiencies in RPA systems, so it is inconceivable that a LOS company would build a “bot” rather than automate that workflow natively (refer to the flood review example above).

Sometimes, task-based automation using database objects is also characterized as bots which is a mischaracterization of what a bot actually is. A bot is a separate piece of software that emulates human actions. A LOS does not have a “bot” feature.


If a lender has a highly proprietary process on a custom LOS or servicing system and is keen on building RPA as a strategic differentiator, then the DIY approach of

  • acquiring software licenses for RPA,
  • engaging a professional services company,
  • assembling a team to approach it like a traditional software development project spending hundreds of thousands (if not millions) of dollars in development and maintenance),

maybe a consideration.

However, RPA is not ubiquitous anymore and has become fairly commoditized. If you are using an industry-standard LOS or servicing platform with (mostly) common screen and navigation pathways, what is the strategic differentiation that requires you to develop this capability in-house? At least, that is the philosophy we have espoused with our BotGenius bots and make RPA-based automation pragmatic and accessible to lenders of all sizes without burning a hole in their budgets.


A POC is a marketing technique to lock clients into licenses, fixed costs, and undetermined ROI. If it is a standard, repeatable and rules-based process with clearly established ROI metrics (say services ordering) upfront, then there should be no need to perform a POC as both the vendor and the lender knows exactly what is in scope and what to expect as benefits.


No. While cost savings are a substantial cost savings driver, our BotGenius bots have been used by lenders to gain the following benefits:

  • Compliance checks to analyze compliance reports, perform safe harbor checks, etc.,
  • Arresting pricing leaks
  • Borrower communication such as performing Change of Circumstances and generating disclosures/re-disclosures
  • Addressing loan quality issues to ensure a defect-free investor delivery
  • Building a non-linear capacity model i.e., bots can scale up and down based on volumes saving lenders from the trouble of scrambling to hire during times of high demand and resorting to layoffs and capacity reductions during times of downturns


The term “Cognitive” has once again been abused. RPA has no “cognitive” or “thinking” capabilities. It executes a set of pre-programmed instructions with no native capability to “improve” itself which is a pre-requisite of a thinking, cognitive, human brain!

The only reference RPA vendors make of “cognitive” RPA capabilities is an embedded OCR tool that may have a machine learning model built-in. For example, RPA software that extracts data from the PDF of a flood report and identifies a property in a flood zone is deploying a machine learning model on an OCR tool to identify and extract data. This is what is commonly labeled as “Cognitive.”

RPA need not be scary or intimidating. It is a very effective lever to improve a lender’s operational efficiency in the mortgage middle office with numerous benefits that we outlined above. So go forth and welcome bots into your workforce!