Robotic process automation applied to internal control: food for thought

There is a misperception that robotic process automation (moreover, RPA) is something revolutionary, futuristic, hypothetically possible to implement but practically difficult to apply.

Maybe the concept of "robot" in our mind has too often been perceived as a mechanical apparatus or humanoid (a scary thing doing some strange repetitive movements) rather than just a software agent that can perform a wide range of virtual activities and gradually learn from them thanks to the information that is logged throughout the process.

What is robotic process automation?

I will describe RPA as a process automation method, supported by a specialised software, that enables virtual agents (aka robots) to interact with a wide range of data sources residing in disparate technology platforms in order to perform repetitive, rule-based and non-judgemental activities. Keep in mind here that by “technology platform”, I mean any internal/ external system or application (from the most sophisticated off-the-shelf applications to bespoke in-house developed systems, to excel files, emails, external content providers, etc.).

RPA software can be deployed quite smoothly without requiring highly complex technical integration activities with existing technology platforms, and more importantly without impacting their “core” processing logic and underlying data dictionary.

The first objective of RPA is simply to emulate the human way of performing a specific task or set of tasks, and nothing else. A subsequent objective (once the organisation has reached an appropriate level of maturity) is to take RPA to the next level where the cognitive and learning aspects come into the picture. For the purpose of this post, I will just focus on the first objective.

So what is “emulate”? I will just make reference to a very simple definition taken from the Cambridge dictionary: “to copy something achieved by someone else and try to do it as well as they have”. This definition says it all so probably no need to elaborate on that. I would just add that the word “emulate” comes from the latin “aemulor” which fundamentally means “to copy or imitate, especially a person”. The reference to a person is quite important here because the main intention of the robot is to copy what a human is doing when interacting with a wide variety of technology platforms.

How can RPA be applied to internal control?

The main focus of RPA has been on existing business processes (where the money is and where cost reduction is a key driver) but very rarely (not to say never) to compliance processes. Organisations are facing increasing costs of compliance that have become almost unavoidable and most of the time unquestionable. I personally think that there is a need for a top-down paradigm shift on how we manage the internal control environment.

As mentioned in my previous post, I have been privileged to help organisations defining and changing their internal control environments and I have seen from my own eyes the almost unbelievable volume of routine, labour intensive and alienating activities that are performed on a day to day basis by the 3 lines of defence. So my legitimate question here is: why RPA cannot be (seriously) applied to targeted internal control management processes and underlying activities?

In the context of internal control management and as an illustrative example, this could mean that the RPA software would access any system or application where a specific control is:

• Operated (on-going control operations performed by business units).
• Evaluated (periodic control evaluations performed by business units, control oversight functions and independent control assurance providers).
• Managed (maintenance of control framework by control oversight functions and independent control assurance providers).

In addition to just accessing any system or application, the RPA software would also perform the following tasks, just as any human will do:

• Operate a control based on a predefined frequency, acting as a control operator (1st line of defence). As an illustrative example (I promise that I will just elaborate on that specific task in this post for the sake of readers’ patience):

(1) the robot will extract data on a weekly basis from a customised report (generated in a specific transactional application) and an Excel spreadsheet (sent by a third party and maintained in a desktop or shared document repository) and perform a reconciliation by comparing records.

(2) the robot will detect any significant differences between these two sets of records.

(3) if a significant difference exist (based on a predefined threshold), the robot will connect to Outlook application (acting on behalf of the designated control operator) and create an email (via an "auto-fill" feature and based on a predefined template) before sending it to the control owner for further review (this action will require some human intervention). The control owner will investigate discrepancies, attach the necessary evidences and reply to the initial email (as proof of evidence of review and formal attestation).

(4) the robot will store evidences (including emails) in the designated document management system (in a predetermined folder called “Control operation with issues”) for subsequent audit trail.

(5) the robot will then inform all interested parties via email notifications in order to perform a review, add further comments and raise ad-hoc issues, if needed.

• Evaluate a control operating effectiveness by performing periodic control self-evaluations, acting as a control owner (1st line of defence). Here again, the robot will be fitted with additional processing capabilities to periodically go to the folders called “Control operation with issues” and “Control operation with no issues” in order to aggregate and consolidate evidences, respond to a specific set of questions and provide an overall rating of control self-evaluations for compliance purposes. The robot will even be able to make a decision and take an action, according to a rule-based approach based on a decision tree mechanism, to raise an issue and assign an appropriate remediation owner.
• Evaluate a control operating effectiveness by performing periodic management testing of control effectiveness, acting as an internal control tester (2nd line of defence).
• Evaluate a control operating effectiveness by performing periodic independent testing of control effectiveness, acting as an an internal audit tester (3rd level of defence). The robot will re-perform the control following a tailored execution scenario (in line with Internal Audit requirements) including sample selection, test steps execution and determination of pass/fail rating.
• Manage and enable the control framework by maintaining, planning and reporting on control operation and evaluation activities, acting this time as an internal control manager and/or internal audit manager. The robot will plan control evaluation cycles, trigger control evaluation activities, monitor execution, generate reports and finally push the right information to the right stakeholder.

Finally control oversight functions are able to focus on judgemental and high-value activities, such as analysis of unusual situations and definition of responses in order to implement optimal remediation measures...No more "operational" burden and hassle !

Envisioning the future of internal control

Just imagine if one or multiple robots can actually:

• Orchestrate all the above specific activities triggered and executed via predefined events and scripts. The "robotic" orchestration element here would be called "scripting of scripts". I will refer here to a very insightful position paper from the Institute for Robotic Process Automation called “Introduction to robotic process automation - A Primer" developed and written in association with Carnegie Mellon University.
• Execute all these activities that are usually performed by all the lines of defence without any segregation of duties conflicts. As long as the scripts and the “scripting of the scripts” are secured and closely monitored (for unintentional changes) and the context of the control is continuously evaluated (in order to ensure an adequate design effectiveness), all the 3 lines of defence should be able to rely on the processing activities of the robot.

You can even go one step further. Imagine if the organisation is using a sophisticated enterprise GRC technology to define, manage, consolidate and report on most of its internal control activities. The robot will be able to access one source of information and leverage all the pre-delivered functionalities (control operation and evaluation workflows, data analytics, continuous monitoring, planning, issue management, remediation management and reporting capabilities) in order to optimise the orchestration layer and be more accurate, consistent and efficient.

In order to sustain and improve this model, organisations will transform their existing highly manual and labour intensive “control operation” hubs, usually located in offshore shared service centres, into “robotic monitoring, calibration and learning” competence centres where critical activities will be mainly focused on:

• Monitoring the appropriate execution of the “scripting of the scripts” to detect deviations and errors. A dedicated team will analyse logs and data in order to teach robots to avoid errors and to start recognising patterns/trends.
• Refining the "scripting of the scripts" based on changes to external and internal context impacting the control design. A dedicated team will constantly amend scripts and add new processing rules in order to ensure that robots are, slowly but surely, becoming more intelligent and aware of the current context.

Maybe I am thinking too far outside of the box here but just imagine how much more efficient the internal control world would be if we, humans, can actually work in symbiosis with robots.

Cheers,

Opinions expressed are solely my own and do not necessarily express the views or opinions of my employer.