Robotic Process Automation (RPA) or ‘Bots’ is the new buzzword within financial services. But is RPA revolutionary? Or even new? Or is this just a clever way of characterising small improvements in efficiency? We’ve attempted to answer some of these questions here.
The word robot is relatively new with its origins only dating back to the early 20th century. It was first used by the Czech playwright, Karel Capek, adapted from the Czech word robota which translates as forced labour or drudgery!
RPA, as a function, has been around for over 20 years. When using COBOL systems, I used to often hear the words ‘let’s write a macro’ for that or ‘let’s screenscrape’ the information. These words were synonymous with making repetitive tasks more efficient by speeding up their processing and increasing productivity.
The RPA solutions of today are far more sophisticated in terms of their functionality and scalability, and they continue to bridge a gap between the intended system design and the required business outcome.
A Bot, in its simplest form, is the replication of a manual task. A task should be clearly understood and broken down into the individual processes needed to carry it out, and these process steps then fully mapped end- to-end across applications, and then scheduled to run as and when required on as many Bots as needed.
The Bot should allow the task to be performed more quickly, more consistently and more cost effectively than using a human and therefore have a positive impact on productivity. It should also improve the overall quality and reduce the overall risk upon integration into a workflow.
Bots are deployed to fullest advantage when used to replace human labour in the handling of bespoke or repetitive tasks that are not part of a core or strategic platform. Bots, ideally, should not be deployed to handle core processing where a specifically designed and robust system should be implemented.
A good way to define or identify these types of tasks would be:
Bespoke requirements: In effect, making systems do what they are not intended to do but where there is a genuine business rationale. Bots should be built on the edge of the process and not core to the central system design.
Repetitive actions: Non-core, repetitive actions, which can be automated by an RPA are the perfect example of the benefits of utilising a Bot. This is especially beneficial where the Bot is being used for non-time sensitive tasks.
Bots, ideally, should not be deployed to handle core processing where a specifically designed and robust system should be implemented.
Bots should not be used to replace core system design or fix upstream problems. This type of strategy may save time today but will add overall cost to your investment budget over the longer term. Core processing should be handled by a system which is designed for the specific purpose and built on strategic architecture to enable it to handle the volume and volatility associated with our markets.
Bots should not be at the core of your platform design otherwise you could be storing up a bigger problem for a rainy day in the event that volatility brings a surge in volume.
Standard Chartered has selectively introduced Bots into its Securities Services business focusing on use cases ‘on the edge’ of the core platforms:
Integrating a T+0 settlement cycle into Hong Kong’s T+2 market standard poses big challenges to global institutional investors investing into China via Stock Connect. Standard Chartered’s unique panel broker model provides clients with the enhanced ability to trade with multiple brokers, compared with the single broker models generally offered by the market. Due to the short settlement cycle making it difficult for clients to send their instructions ahead of the market deadline, Standard Chartered relies on using the broker transaction files to instruct the Hong Kong Central Securities Depository (CSD) for same day settlement.
We designed a Bot to ‘consume’ the broker files and auto-create the settlement instruction for matching. We also created a secondary Bot to extract broker transactions from the CSD and auto-create the settlement instruction should the broker be unable to send the file or to provide back up to Bot 1. This process enabled us to provide a robust and scalable solution with full straight-through-processing capability that allows clients to invest in China via Stock Connect using multiple brokers.
Due to the short settlement cycle making it difficult for clients to send their instructions ahead of the market deadline, Standard Chartered relies on using the broker transaction files to instruct the Hong Kong Central Securities Depository (CSD) for same day settlement.
Invoices are simply a representation of the fees charged for a service. That said, they involve copious amounts of data from different sources and need to be 100 per cent accurate. We developed a Bot to automate the collation of data from multiple different sources to automatically prepare the invoice and load this into our automated client reporting platform. Additionally, a separate Bot was designed to create and post the accounting entries, by product type, in relation to the invoice. Both Bots significantly reduced the manual effort to produce the invoices and post the entries whilst simultaneously reducing the risk of the overall task. This led to faster invoice production and reduced errors and a material reduction in FTE cost.
Model: The governance models surrounding the use of Bots is increasingly important. Whilst the Bot may be simple by design, the level of governance should reflect the intended importance of the Bot process or output.
Resilience: Where Bots are used to input or extract time sensitive data, there needs to be a comprehensive business continuity plan to ensure continued coverage in a contingency scenario.
Ownership: The Bot design, use, change process and maintenance should be documented to the standards of a fully functioning system and the Bot should be appropriately owned and managed by business stakeholders – IT should in no uncertain terms be the owner of the Bot.
Performance: The performance of Bots should be actively measured on a regular basis. The business function who has overall responsibility for the Bot needs to ensure it is running as expected to ensure that any incorrect processing is spotted in real time and addressed accordingly.
Security: With cybersecurity a key concern for our industry, the security aspects of each Bot should be understood and approved to ensure this does not introduce any additional cyber risk. This is particularly crucial for Bots which are built or run on third party software / platforms.
It is clear that systematically deployed Bots can provide significant automation to providers and lead to enhancements to the client experience.
Standard Chartered plans to progressively integrate Bots into appropriate workflows / ecosystems, on a selective basis, which are not part of the core system design whilst ensuring that core processing capabilities continue to be serviced by our target and strategic system infrastructure. As such, it would be more accurate to describe Bots as evolutionary rather than revolutionary, as they are designed to support and complement technology-powered banking operations developed over time.
