What better to blame – when all goes wrong – than the evil robotic thing you just inserted into your system. Many of you saw the recent article in ABA Banking Journal where they blamed RPA for the “burden on their processing system and diminishing of its capabilities”. We will discuss this debacle in a more detailed POV (stay tuned) but the crux of the issue here is a poorly run government IT function tinkering with software to try and process a mad scramble for many thousands of small business handouts from the recent Covid-19 stimulus package – and most likely in some weird virtual lockdown vacuum. And it appears woefully understaffed.
In short, APIs + humans + bots need to work within system parameters, or we’re always going to have failures of scale like this one.
RPA is a highly useful tool to support this environment, but please let’s start deploying it as part of the overall tool-box
As we’ve said of late, the digital workforce that wasn’t finally has its burning platform chance to shine. Since global lockdown commenced, we’ve been tracking, talking, and learning about the ways in which enterprises and their service and technology partners are using automation to help them function. One of the most prevalent use cases in recent weeks is in the banking and financial services sector where lenders are using automation, largely, RPA, to support loan processing for government-backed loans. RPA is helping lenders grapple with massive loan volumes and get them submitted quickly so loans can be approved and dispersed.
Insert monkey wrench.
The U.S. government’s Small Business Administration (SBA) application and approval portal was overwhelmed with demand as a second tranche of government funds were made available on April 27. The funds are intended to support loans for small and medium-sized businesses (administered via banks) as part of the Payroll Protection Program (PPP) during the Covid-19 pandemic. The SBA E-Tran system receives the loan applications and then the SBA processes and approves them. The system struggled to handle the new surge of applications coming through and repeatedly crashed. As of Tuesday, April 28, the SBA prohibited the use of RPA bots in the application process.
RPA fail, right? Not exactly. It is actually the overwhelming success of a blunt instrument.
The HFS team dug in and spoke with a variety of ecosystem players – banks, software companies, and service providers to get the straight scoop. We also reached out to the SBA, but they have not responded. We view this as a case of RPA being used as a blunt instrument allowing any bank that invested in RPA to automate loan application submissions. RPA very legitimately helped banks and lenders process scads of PPP loans. This presented two immediate issues:
- The SBA E-Tran system crashed – it was way overburdened with hundreds of thousands of loan applications.
- Banks with automation were potentially able to submit more loan applications than those without thus more effectively accessing a limited pool of stimulus funds.
The SBA responded in a super butt-covering mode with its “NO RPA!!” edict. It will still allow loans to be automatically processed through APIs. So now banks are scrambling to convert their RPA processes to API-led. And the SBA assigned one person. Yep, one person to field all requests for API access. We hope this poor beleaguered contact has some help, but banks have reported the API access option is “very slow”. To address the potential of access bias for those firms with automation – deemed to be the larger banks – the SBA designated an eight-hour window on April 29 for lenders with less than $1 billion in assets to submit loans.
Bottom line: This SBA debacle is why you need nuance and a toolbox approach to automation to get desired results.
It’s too easy to say RPA failed. It’s more complicated than that. Really RPA was a blunt instrument here – for its speed to solution and ability to swiftly process loan applications and it worked remarkably well. Too well. It swiftly overwhelmed SBA’s E-Tran system – which was doomed to be overwhelmed anyway by these unprecedented volumes in a short period of time. But RPA exacerbated it and potentially gave access advantage to automation-savvy firms. While access through SBA’s XML API may allow for more efficient loan submission rather than the RPA model of going through the user interface and clogging the narrow pipes, this did not have to be an ‘either or’ situation. APIs versus RPA is not the point. Automation always lives in an ecosystem with upstream and downstream impacts and these were not adequately addressed. A better approach would have been a toolbox approach that leveraged RPA for loan preparation and access into legacy systems in the lenders’ shops, APIs for submission and humans for oversight with some substantial volume throttling to give the SBA’s system half a chance at doing its job. Automation cannot live in a vacuum.
Posted in : intelligent-automation, policy-and-regulations, Robotic Process Automation
Most apps with human centric User Interfaces (windows, Macs, phones) are designed atop a sophisticated technology stack specifically designed for humans, running at human speed. It’s always been the case. The stack can often easily be enhanced to go horizontal, meaning adding more users. BUT the technology stacks in the vertical layer (the desktop O/S, desktop memory (leaks), kernel, threading, interrupts, I/O channels, interface handlers (client and servers side) etc., were never designed to go much faster than a human. Nor process too many UI tasks in a single login session. Microsoft (nor APPLE) are not going to fix. You can witness the same often if you try to enter data into a web page before it’s completing loading all the objects (even when the UI looks like it’s rendered). This has got better in parts of the stack because PC’s have got faster, CPUS are multi-core, pipes are quicker and more. But it’s not all fixed.
So, whilst I’m a fan of RPA, be warned. API’s are designed on the other, from the ground up and have been designed to be throttled, queued, retries, resilience etc., They are not perfect but they are a lot more perfect, a lot more secure and a lot more governable.
I don’t know why the SBA shut down these RPA scrapes of the web pages but perhaps the bot builders should have learnt a little about event handlers and adding smart delays (ideally not indeterministic sleeps or pauses). Then SBA might never have known it wasn’t a human.
One senior Architect of one of the worlds largest banks once told me, “Francis, we have never had to worry about UI’s breaking bots before. And we have 6000 applications with a UI”.
We successfully used the API’s, and built new applications meaning there was no need for double entry and simulated rekeying. It would also keep the people applying for the loan (and the banks), up-to-date with their applications, and managed the entire end-to-end process. And built in less than 5 days and that could be shared between banks. The UI is very misunderstood and overplayed!
Hi Empbus,
Sorry I have to agree with Francis here. He is correct in his statement that the UI interface was designed for a human interaction and not a robot one which is very much faster and at a higher volume. Therefore if the RPA interaction with the UI is not configured correctly it will lead to failure.
I was involved in both functional and performance testing of a web based application at a large bank recently. In fact automated testing tools were the precursor to the RPA tools we see now. The testing we did and the expected results had tolerances based on what a human being would find acceptable and therefore testing was singed off based on that.
If you then go and completely change the playing field by firing thousands of robots at a process designed for far less then it’s not surprising the system failed because it was design with a different use case in mind.
It doesn’t need a PHD in applied mathematics to understand that.
All the best.
Dear Francis,
Your view on this appears reasonable, contrary to most other times. Perhaps that is because the space (HfS) has a more knowledgeable reader base than most of your other writings audience.
While I sincerely appreciate the more balanced view presented, yet I must specify the technological errors appearing: the description of scalability is just wrong, that’s not how apps scale. That’s especially not how virtual desktop environments dedicated to robots scale with their numbers and underlying software sessions. A simple rule is, if it can handle the users scale, it will handle the robot scale.
Also, no robot needs to handle more than one click in a single “login” session.
Another mistake is that RPA flows can be throttled and queued. They can also be intelligently throttled based on system and UI variables, unlike APIs. Which may also kill a system with DDoS or compromise it with injections.
As for retires and resilience, I’d like to introduce you to the fields of persistent and compensation-enabled stateful BPM. Welcome, there are about 20 years of formal mathematical research to assure app statefullness. It only gets more reliable than this in blockchain scenarios. Hint: future will have blockchain enabled BPM. Go for it, create your next rocket ship.
I’d like to mention here that both BPMS and RPA deployments can be stateful, persistent, eventually persistent, and handle acid transactions.
Speaking of acid transactions, perhaps I can remind you that the most stateful things are death and taxes as they say. I personally doubt that death was programmed in BPMS, but taxes all over the world surely have. I’d recommend to check with your local tax office to see magical 1980s and 90s BPMSs in action. And then check how your local tax office does want to make RPA dance on a form based BPMS, but only when it comes to you paying. When it comes to their turn paying, the green screen it is, what advanced RPA. Achieved time delay distortion: about 20 years.
Cheers to you Francis,
Empbus K.
This is such a joke, I submitted with Wells the first day of the first go around April 3, as of today nothing, but the standard we know email, we are working on it, really since the first day first go around?
All my docs are in order, and submitted perfect credit and didn’t ask for a large amount, less than 50k to stay afloat. I I have been a loyal Wells customer for 12 years, personal and business accounts and two mortgages both with them. Why has my loan not been submitted approved and funded? My doctor submit with Wells same issue, they went to a small bank I found out loan has been funded already, Wells blames SBA, I do not it’s the greed of the big banks. Chase, BOA, WELLS and Big business Big Banking just another big business bailout made to look like it helped out the little business owner’s. Remember without us there is no America.
I have been trying to fill out an application for the SBA paycheck Protection program ever since it was available. Every time I go on the Huntington Bank site to fill out an app or anywhere else the application is unavailable. I called the Bank and she told me on one of the days the application was only open for 15 minutes and then was paused by the bank. I said well can I do? She said the only thing she can suggest is keep going back in and refreshing the page. I am a small business and need help at this time. My paperwork is in order and I can’t even get an application filled out for a loan of less the $20,000. Is there any help out there??
Try Fundera.com. They have a working relationship with a number of lenders and may be able to get you funded. There is also a list of banks you can apply directly to on their website. You can apply with multiple lenders, but you can only get one loan. The first application approved wins. Best of luck!