Introducing RPA and automation in the financial sector: Lessons from KAS Bank

Robotic process automation

The last decade had witnessed a tremendous interest in the automation of services through what had been coined RPA. RPA refers to the application of software programmes that process certain tasks previously performed by humans (Frank et al., 2017). RPA had been implemented to automate repetitive and rule-based functions typically handled by back-office employees. Typical processes that had been automated were cost accounting, payables and receivables, reporting, invoice sharing, and month-end close processes. A study by KPMG (2018) on intelligent automation (IA), an umbrella term for RPA, machine learning and artificial intelligence, predicted global spending on such technologies would reach $US232 billion by 2025.

Recent reports have persistently suggested that RPA is likely to deliver significant benefits to firms. For example, it has been suggested that RPA is likely to increase the accuracy of business operations, improve monitoring and analytics capabilities, and would allow to scale-up processing infrastructure while reducing operational cost. Indeed, there have been numerous reports on the degree of successful RPA implementation. For example, from the client side, Lacity and Willcocks (2016) studied RPA implementations at O2 that transformed the firm’s back-office services.

KAS Bank

KAS Bank is an independent Dutch bank founded in 1806. The bank is a leading European provider of custodian and fund administration services providing tailor-made financial services to institutional investors and financial institutions. As a response to market developments, KAS Bank decided in 2014 to initiate a cost reduction programme to minimise operating costs. A LEAN programme was launched to streamline and simplify financial business processes at the bank. However, the results fell short of the cost reduction programme’s objective. As a result, KAS Bank outsourced several IT functions to a service provider including the transfer of employees and IT assets to the supplier. The outsourcing programme proved successful, delivering significant cost reductions and pricing mechanism flexibility (pay per use). The executives were encouraged by the results and sought to explore additional mechanisms for further cost reductions.

Initiation bot program

KAS Bank’s executive management decided to explore the opportunity to automate business processes and in doing so, reduce operational cost. In 2016, the bank organised multiple internal workshops and invited senior management to co-create an RPA strategy in business and IT departments. The execution of the RPA strategy reflected a phased approach. As a start, executives decided to focus on primary business process (e.g. pensions, security, institutional and professional investments). By conducting multiple PoCs, RPA functionality was tested while IT integration and interoperability issues were explored. Finally, when PoCs showed to be successful, the programme was scaled-up to other business processes. By means of a phased approach, they mitigated against business interruptions and potential client dissatisfactions. Based on the RPA strategy outcomes, executives concluded the bank lacked relevant capabilities to select a proven RPA supplier. Moreover, they required support in selecting potential business processes candidates. To deal with this challenge, they hired a consultant with a strong track record in supporting clients in their RPA journey. Despite these steps, management was aware of inherent risks associated with implementation and the challenging odds of achieving ‘seamless integration’. The role of the consultant was twofold. On one hand, the consultant supported executives by means of subject matter related advice. On the other, the consultant was tasked with implementing the RPA solution; configuring and managing operational bots. As such, the consultant was responsible for business process optimisation ¹ and day-to-day operational support.

By analysing supplier track records, a shortlist comprised of five suppliers was presented. Their corresponding RPA solutions were interrogated from a technical perspective to analyse fit for purpose; business process functionality and levels of IT interoperability. Client reference visits were organised to collect lessons learned. After summarising the findings, Blue Prism, a UK based multinational software corporation was selected as a key supplier. The decision was based on their significant technical experience and market leadership in enterprise robotic process automation software. Blue Prism was one of the first multinational companies to introduce RPA to the world.

After finalising a strategy, KAS Bank’s operations department introduced the RPA programme (see KAS Bank video) and they explained the transition from manual, human controlled to automated processes. An internal roadshow followed. It included teams from various business departments and sample illustrations (see Figure 1) were used to demonstrate potential automation processes, as well as opportunities to automate multiple process steps. These internal presentations helped create employee awareness.

OPEN IN VIEWER

Figure 1.

Illustration – from manual to automated business processes.

Candidate business processes were selected and analysed in two steps. Four key criteria were used to assess processes best suited to the RPA programme as a first step. These included (1) transactional levels in process, (2) routine-based process, (3) levels of task repetitiveness, and (4) process complexity (low; standardised). As second step, three factors were used to rank corresponding scores within (1) degree of feasibility, (2) impact on service quality and (3) impact on customer management (see Figure 2).

OPEN IN VIEWER

Figure 2.

Selection criteria overview.

The operations department used this selection method to assess multiple business processes. A business case was developed according to those business processes considered favourably disposed to automation in which various aspects were analysed, that is, the impact of automation on the degree of business process improvement, costs, information systems, people support requirements and time to market; for example, trading services. By indicating the impact of automation on each business process they were able to define value to clients and the bank. In 2016, two business processes were automated within 6 weeks. This included design of a planning scheme, bot assembly, and 2-week implementation. Additional bots were introduced over 8 weeks that relied on a 6-week design phase and 2 weeks implementation period. In many ways, the KAS Bank’s bot implementation was consistent with Hallikainen et al’.s (2018) in which a four-stage approach (workshop, process assessment, business case proposal, RPA implementation) was pursued. At the time of data collection, KAS Bank automated 20 financial business processes, using five bots. The automated business processes included treasury operations, obligation payments, calculating and booking, and client data management (e.g. internal invoicing, new accounts and changes to existing accounts). These bots replaced manual transactions, which were previously carried out over decades by employees using Excel spreadsheets. While the original rationale for introducing bots was cost reduction, subsequent automation projects had shifted in focus to include business process quality improvement and reduced rework.

The development stage

The development stage was characterised by initial discussions about robotic process automation and the formation of a development team to assess which business processes might be candidates for automation. The development team comprised of a business process selection specialist, a process designer, an audit manager, an enterprise architect, a software programmer, and a functional application manager. The development team followed the selection method described above and subsequently brought its recommendations to the CIO:

At the start of the development period, we decided to set design principles; for example, ‘a bot is equal to a human’. By using guidelines and limitations to authorize bots, we ensured security and compliance agreement. In doing so, bots are treated in the same way as humans. By applying an authorization matrix, bots replaced tasks that were previously executed by a human. (Source: Enterprise Architect)

The development team worked in collaboration with operations personnel, that is, employees who had previously performed automated tasks. The team worked closely with the operations personnel to capture workflows (see Figure 3), steps in processing transactions, and the nature and structure of input and output data. The development team created a process design document that meticulously described day-to-day activities carried out by operations employees. While the development team and its activities created opportunities for employees to better understand bots (through consultation, for example, workflow and workarounds) applied over time in performing the manual tasks targeted for automation. The outcome of this stage presented a challenge for humans interacting with bots.

OPEN IN VIEWER

Figure 3.

Example business process visualisation.

The implementation stage

The next stage of human bot interaction occurred during implementation. Employees became aware of the impact bots would have on their jobs and specifically those operational tasks earmarked for automation. Operations personnel were informed about bot functionality, new business processes, bot delivery format and output, and steps required to be taken by operations personnel. Operations personnel were encouraged to get involved in the implementation stage as input was needed from all stakeholders. Indeed, initially operations personnel did seek to get involved and contribute their knowledge. One manager recalled,

For example, employees provided improvement suggestions to fine-tune the bots and optimize business processes. By involving operations personnel, the bots are trained in handling tasks better and better. (Source: Managing Director, Operations)

However, the introduction of bots to the operations environment created another challenge.

The operational stage

Bot integration became increasingly dependent on input data to generate meaningful output and reports. These were handed to operations employees for checking prior to release to external clients. The development team assumed input data from internal and external sources would align with bot capability, and subsequently generate accurate client reports. Operations personnel were simply informed about their new responsibilities for checking the reports before releasing them to clients. At the same time, the development team provided more detail about the way work would be affected and transformed, so personnel could identify the impact of bot implementation in their roles and adapt accordingly. However, the full impact of robotizing tasks was not fully assessed as input data was often incomplete and inaccurate.

Challenge 3: when the bot fails to complete a task

Bots were totally dependent on input data to generate meaningful results. The development team had assumed input data from internal and external sources would align with bot requirements (functionality). However, unforeseen gaps in input data and the problematic operational human/bot interface, impacted bot processing performance in those tasks they were designed to complete. When a bot failed to complete a task it was flagged as an exception. Typically, bot generated exceptions were data related that is, incomplete or inaccurate data fields were the main source of bot generated exceptions, which prompted an exception report review by operations personnel (see Figure 4, an example of an exception report). Therefore, an automated process with intended seamless integration still required human intervention that is, checking, final sign-off and release by operations personnel:

Within a business process at least 40% of all tasks can be conducted by a bot, but often more. The percentage is influenced by the number of exceptions regarding process tasks. Specifically, the data quality is a real issue as bots are rejecting tasks in case of poor data quality. That’s where the humans come in as they have to repair the quality of data first. (Source: Functional Application Manager)

A design criterion is a bot has to handle 2000 financial (swift) transactions per week. Based on our conducted proof of concept we experienced that 20% of all transactions were labelled as exceptions. That means that we still need humans to repair bot errors. (Source: Software Programmer)

OPEN IN VIEWER

Figure 4.

Example of an RPA exception list.

The implications of bot exceptions in operational processes, necessitated engagement of operations personnel in work they had previously performed manually. For example, data field entry, now required source exception analysis and information and data correction. Bot generated exceptions had changed operations personnel work performance in two ways. First, the need for root-cause analysis and redesign in collaboration with the development team to avoid re-occurrence of exceptions. These initiatives necessitated professional development of operations personnel to develop themselves further and assume new responsibilities for example, process improvement manager roles. Meanwhile, operations staff were finding the task of handling exceptions discouraging. In the past, these individuals were responsible for assessing the quality of data, as input, allocated to the data field and completed as data entry. Now they were being instructed by the bot to decode the nature of exceptions and take steps to fix these specific mistakes. They had little visibility to the input data, and yet, they were required to fix it. Clearly unsettled by these developments, many had consequently sought alternative lines of employment.

There were significant work challenges at the human/bot operations interface. Although there were opportunities for personal development and service improvement, many of the challenges encountered by KAS Bank appeared endemic to the way in which people perceived the impact of bots on their work and capabilities.

COVID-19 and RPA at KAS Bank

At the end of 2019 KAS Bank merged with Caceis, a department of Crédit Agricole. Caceis is known in the market as top 10 asset service provider. As part of the merger, a set of KAS Bank’s financial operations were to be transferred into Caceis in order to benefit from potential synergies. However, in early 2020, COVID-19 affected both firms, significantly interrupting manual work. Among the activities affected were those that KAS Bank was intended to transfer into Caceis, such as customer data, bank accounts, financial metrics and reports, compliance and audit reports. As a result, Caceis CIO examined alternatives to transition financial operations from KAS Bank to Caceis. Reviewing the various options and the experience gained in implementing RPA at KAS Bank, the CIO decided to use RPA as a mechanism to transfer financial operations activities. After testing the Proof of Concept, KAS Bank initiated a waved approach to transition its financial operations to Caceis, automating the services as part of the transition. Interestingly, COVID-19 has been the driver for KAS Bank and its acquirer to continue their RPA and automation journey.