Tales of Disruption: The SBA’s PPP Bot Ban

The Small Business Administration (SBA) started accepting applications for the Payroll Protection Program (PPP) on April 3. Within fourteen days, the original $349 billion fund, as allocated by the U.S. Congress via the Coronavirus Aid, Relief, and Economic Security Act (CARES), was exhausted.

Based on the program’s popularity and the speed at which funds were dispersed, it was touted as a smashing success. So much so that, on April 27, Congress replenished the PPP with an additional $310 billion and started accepting applications via a second tranche in less than a month. As of the writing of this post (14 days later), 75% of these funds have been exhausted as well.

While politicians, pundits and economists can discuss the merits of the policy and the way it was executed, an interesting technical sub-narrative emerged from this story. That sub-narrative has to do with the use of Robotic Process Automation (RPA) bots to help banks facilitate filings with the SBA. This is a narrative with which we at KnowledgeLake are quite familiar because we were one of the first intelligent automation companies to help agent banks leverage RPA technology to accommodate the deluge of loan applications.

During PPP’s first tranche, all parties involved (the applicant businesses, the agent banks and the SBA itself) were learning on the fly, so there were several rate-limiting factors helping to regulate deals flow volumes. But as the process hardened, deal flow increased, and forward-thinking banks turned to technology to ease the burden. A number of banks leveraged RPA to handle repetitive data entry into their internal and external systems. This quick and innovative use of technology, coupled with the build-up of loan applications occurring between the tranches, overwhelmed the SBA E-Tran system.

On April 28, the SBA banned the use of RPA bots to submit PPP loan applications to the SBA. The SBA’s rationale for the ban was: “RPAs burden the processing system and diminish its capabilities. Without RPAs, the loan processing system will be more reliable, accessible, and equitable for all small businesses.” Whether it was the SBA’s intention or not, the implication was that RPA is a disruptive force in the process that destabilized the system and put some at a disadvantage. And clearly, that was the case.

But why was this the case and what are the potential lessons learned?

Why Was This the Case?

No doubt, RPA destabilized the system. But is RPA a villain or a hero in this story? Is “destabilization and disruption” a bad thing? Where you stand on this question depends on where you sit.

For example, if you’re at the SBA, destabilization is a very bad thing. Processing interruptions, delays and inconsistent performance don’t engender a whole lot of confidence with any of your constituencies – especially in times of crisis. If you’re a smaller lender without ready access and ability to employ RPA bots, you probably feel as if your firm was put at an unfair competitive disadvantage compared to larger lenders. And finally, if you’re a borrower and the processing of your loan is delayed because others are cutting the line via the use of bots, you probably feel something nefarious is going on and you’re getting hosed. All legitimate points.

However, do these points mean the use of bots is inherently a bad thing and should be banned? Of course not. Banks that utilized RPA dramatically increased deal flow (and commissions), at a lower cost point, while also reducing processing times and more quickly delivering urgently needed cash to their customers. So, to these institutions and customers, RPA was the hero. Criticizing the use of RPA bots is like saying we should not adopt the usage of bigger and better vehicles because old country roads can’t accommodate such vehicles. Clearly, the problem is not the vehicle, it’s the road.

The RPA revolution we’ve been experiencing over the past few years has been driven primarily by the consumer of systems and not the developer of systems. And that’s mostly because developers believe they have already made their systems accessible by providing APIs. They’ve done their part. In fact, the SBA made this point clear in its bot ban notice by stating: “Application Programming Interface (APIs) will still be permitted.” That’s a reasonable point of view. However, it fails to acknowledge the most compelling reasons that RPA is being rapidly adopted even in cases where APIs exist. These include:

1. Quicker time to value than API access.
2. Guaranteed delivery because every application possesses a user interface (versus applications that do not have APIs, require additional licensing to access those APIs, or do not support functions required to complete the task at hand).
3. Requires the same, and thus reusable, skill set for every integration project which dramatically improves development resource and expertise scaling.
4. Monitoring telemetry associated with managing integrations in production is generally better with RPA than with APIs.

The bottom line is that RPA is not going away regardless of such woeful tales of disruption. In fact, its adoption is increasing dramatically. That being the case, developers should consider the following when determining how to peacefully coexist with RPA bots:

1. Perform load and burst capacity testing on the presentation layer of their systems as well as the application and data tiers. The need to scale is expanding within the stack.
2. Build user interfaces that anticipate UI automation (e.g. consider alternative shortcut navigation paths to perform common functions users may want to automate).
3. Incorporate data entry speed threshold levels and UI throttling strategies.
4. Develop a bot usage contract that defines terms and conditions for RPA access (i.e. bot “usage rules of the road”).

Finally, the greatest lesson learned from the PPP experience is that RPA delivered as promised. No hype in this case. When banks were faced with the daunting task of integrating disparate systems, inside a week, RPA was able to deliver like no other alternative. In production, RPA entered loan application data faster, more accurately and at greater scale than human operators ever could. And it did it at a fraction of the alternative human cost point.

The SBA’s inability to accommodate RPA bots was magnified by an unforeseen and unprecedented global crisis. Most systems will never be forced to accommodate the demands placed upon the SBA via the PPP. However, your customers and partners do expect you to adapt or they’ll find alternatives.

So, when you ask yourself if your organization is ready for RPA and broader digital transformation, ask yourself if you are ready to disrupt the status quo. Ask yourself if you want a quicker time to value. Ask yourself if you want an unfair competitive advantage.

Of course not.