If you work in banking, you’re familiar with the Federal Reserve’s Regulation D: It sets requirements for banks’ cash reserves. Part of that requirement governs how many withdrawals a bank’s customers can make from their savings accounts in any given month. It’s a regulation that many bank customers are unaware of, and so they often violate it. This creates mountains of paperwork for all banks that have defied efforts to automate them—until recently.
In this article, drawn from recent real-life case studies with multiple banks, we’ll show how The Lab was able to employ its unique à la carte approach to robotic process automation, or RPA. And it was able to configure and install a fully-functional “Reg. D bot” in just three weeks.
Don’t know what RPA in banking is? Find out more in The Lab’s Banking RPA 101 Guide
Drilling down on Regulation D for banking RPA implementation
Some of the following details will vary from bank to bank, but the broad framework should ring familiar to you:
Bank customers are limited to just six withdrawals or electronic transfers out of their savings accounts in any month. If they do too many, they get a warning. If they get enough warnings, they’ll get a penalty, in the form of a fine. And if they continue this prohibited behavior, the bank will step in and automatically convert their savings accounts to checking accounts, which don’t fall under the Regulation D requirements. Of course, the customers are warned of this possibility before it happens. And if it does, they’re notified that it’s taken place.
On the banks’ side, that’s a lot of monitoring of customer accounts. It’s a lot of letter writing, printing, and mailing—not to mention the storage of each letter to satisfy a potential audit.
https://www.youtube.com/watch?v=Lxive03vlIE&t=13s
More specifically, this entails a lot of low-value work from high-value (and highly paid) knowledge workers. This case study will focus in on a back-office worker whom we’ll call Margie. She needs to check the system for violations every other day. And when it comes time to create all the letters, it takes her an entire day. Most of that time is spent simply opening file systems, checking for information, exporting reports as Excel sheets, and copying-and-pasting data into other systems and Word docs for letters. In short, it’s a ripe opportunity for robotic process automation.
The bigger picture of robotic process automation for banks
As you can see in Figure 1, this RPA opportunity represents just the tiniest sliver of a massive opportunity for the bank.
Automation predicates on standardization. That is, processes and data all must be standardized first. Variance—the nemesis of every business—must be eliminated.
The Lab specializes in finding opportunities for eliminating variance and standardizing processes and data. That’s what we’ve been doing, for Fortune 1,000 leaders, for more than 25 years.
Want to find out more about banking process and data standardization? Click here: How to standardize banking operations
As Figure 1 makes clear, we identified nearly 450 opportunities to standardize and bring processes up to leading practices. A full 272 of these—what we call Class I opportunities—require no new technology whatsoever. Another 89 sub-processes—what we call Class III—are ripe for robotic process automation. (Class II, in case you were curious, represents those that do require new, and costly, non-robotic core technology intervention.)
Drilling down into those 89 RPA candidates, we can further subdivide them into three categories, as shown in Figure 2. Look at that bar graph closely:
In the far left column, we can see that there are 50 use-cases that are ready for automation “straight out of the box,” with little or no new standardization required. Each of these, if automated, could yield anywhere from 15 to 50 hours of monthly knowledge-worker savings.
The middle column is intriguing: It reveals that 27 processes require “root cause investigation.” Translation: There’s no point in automating these processes because they’re redundant or wasteful. With proper standardization of other processes, these processes would go away completely. That’s what yields the “10 to 140 monthly hours” of savings, per use-case, as shown at the top of the column.
The right column is arguably the most enticing for big productivity benefits from RPA. It’s the smallest of the three, with only 12 RPA use-cases in its consideration set—a mere 13 percent of the original 89. These are the use-cases that would require real standardization of their underlying processes before they could be automated. But the payoff is huge: Anywhere from 35 to 600 hours of monthly knowledge-worker savings, per use-case. Just using the average savings time per use-case, that would net about 3,800 hours of savings per month!
Indeed, if you take the average savings from all three columns, you’re up to 7,500 hours of savings per month.
From these 89 RPA use-case scenarios, the “Reg. D bot” is just one. In other words, the potential is truly staggering.
The “before robotic process automation” scenario for generating Regulation D violation letters
Let’s return to Margie and her back-office chores when it comes to generating and sending out Reg. D letters:
First, Margie must determine which customers need letters sent to them—and what kinds of letters must be sent. So she logs into the bank’s Acquire system. From here, she queries the system: “What were today’s violations?” After the system responds to her query, she then must take its report and export it into an Excel spreadsheet. Note that this action alone requires that she navigate to the proper folder in which to save it, that she creates a new filename for that report, and so on. It’s a lot of basic work for a college grad like Margie.
For this bank, there are four types of letters that can be sent. So, for each customer in violation, Margie must see what type of letter to send. If a penalty is required, she must log that in the core banking system (in this case, it’s Horizon. But it could be Fiserv; it doesn’t matter for our purposes).
Then Sally must navigate to, and then open, a Word template of the proper violation letter. She must paste the customer’s unique information into the appropriate fields. She must save this letter—in the proper place, with its own new, unique filename that adheres to proper protocol—and then put it in a batch for printing.
So far, the work she’s done, to generate just one letter, without even printing it, it’s taken her 13 steps, 32 clicks, and more than 12 minutes. And then she turns to the next one in her stack.
As you can imagine, this is hardly an efficient—not to mention fulfilling—way for Margie to spend her work day.
At the end of the day, she’ll see how many letters need to be sent. This number is important, because if it’s below a certain designated threshold, she will send the letters to the office printer, and then fold them and stuff them into envelopes so they can be mailed. If the number is higher than the predetermined cutoff, she’ll email the entire batch to a third-party vendor which will do the printing, stuffing, and mailing.
Breaking Reg. D down for the robotic process automation
At the surface level, Margie’s actions seem like they can just be automated with bots easily.
But looks can be deceiving. The processes, as we’d mentioned above, must be standardized to the “bot-level” of quality. Fortunately, at The Lab, we’ve been specializing in analyzing processes at the bot-level—that is, 5- to 15-minute increments of activity—for more than 25 years. Now that RPA is here, the technology has finally caught up to our front-line, sea-bed level process analysis expertise.
There’s another aspect to this challenge that you won’t hear from most bot-software vendors. And that’s the fact that their bots don’t work straight out of the box. That’s because Margie’s versions of Acquire and Horizon—not to mention all of those file-storage locations and file-naming conventions—are unique to Margie’s bank. So the bot must be “taught” what to do. At The Lab, we do this kind of work all the time, so it’s fast and easy for us—and thus quick and painless for the bank.
How the banking bot was built
The bot—in this case, it was UiPath, but it could be Blue Prism, Automation Anywhere… we don’t care—was configured to do what Margie does, step-by-step, and click-by-click.
Think of the bot simply as a high-powered Excel macro, except one that can work across numerous systems and apps. It can be configured and updated quickly. There’s no coding required. You don’t even need IT department intervention—just like when you make an Excel macro. Business lines can own the implementation without the IT department. And the bots are reliable.
There are some interesting differences. The bots are so fast that they can actually run too fast for the systems they’re on, which can cause problems. So we routinely “throttle them down,” by inserting pauses into their routines. For example: We recently configured a bot that needed to query a client’s database via a website, and we inserted a four-second delay into that step, in order to account for the lag from the website.
Incidentally, the bot we built for Sally’s bank was created—start to finish—in just three weeks. And we did it 100 percent remotely, from our offices in Houston, saving the bank time and expense.
The “after RPA” scenario for generating Regulation D violation letters
Today, with this one single “Reg. D bot,” the process is almost entirely automated. Margie sits at her desk and clicks “Run,” and then watches, in amazement, what happens:
- The bot logs into the Acquire system for Margie, using a configuration file from which it pulls her current login and password.
- It re-formats the raw data to extract the customer information and determine the number of violations. It creates the Excel sheet. It names it. It stores it—in the exact right place.
- It updates the penalty fee and product type in the Horizon System (don’t worry; it logged into that one for Margie, too).
- It creates the appropriate letter, based on the customer’s violation status.
- It even sends the customer an email, if that customer has opted out of postal mailings.
- It batches the letters for printing, using Margie’s rules for in-house vs. send-to-the-mailing-house.
And it does all of this at ten times the speed that Sally could. Without making any errors, or taking any breaks.
Indeed, after the first few times, Margie stopped watching in amazement. Today, she gets herself a cup of coffee—and then turns to more productive work, helping customers.
All contingencies considered—exceptions due to bad data—no big deal for a bot
Margie does deal with the occasional exception. When the bot encounters a field it can’t reconcile, for example, it sends Margie an email, explaining, in plain English, the problem it encountered. (“When I got to Row 80, I found numbers in Column AJ, where there should be a name. Could you check that for me, please?”)
So Margie’s main interaction with the bots, these days—aside from clicking “Play”—is processing the exceptions.
RPA training and setup requirements or bots from The Lab
Since the bot basically does what Margie used to do, she didn’t really need to learn much in order to operate it. Indeed, we were able to train Margie, and all the others in her department, in just one day, remotely, with online meeting software. It was easy.
And despite the prevailing claims from big-name consultancies, there’s a lot we didn’t do—that they’ll tell you is required—before we got this Reg. D bot up and running:
- We didn’t create a center of excellence. At this scale, none is required. When it even gets to that scale of 20-plus bots, it’s still not required. We can do it remotely, as needed.
- Similarly, we didn’t do this via a forced-down-from-the-top approach. We took a bottom-up/front-line groundswell approach which is embraced by the knowledge workforce.
- We didn’t require a slew of RPA licenses. We automated all of the above with just one bot for Margie—and everyone in her department.
- We did this all from the USA. At our Houston, Texas office. Nothing was outsourced or offshored.
- We didn’t take six months or a year. We configured and implemented this bot, start to finish, in just three weeks. That’s because we boast a library of banking bot templates, and are able to adapt them quickly for a variety of use cases.
- We didn’t charge a million dollars. Nowhere close. Not for a single à la carte bot! And it was fixed fee, so no surprises at the end with billing.
Bottom-line benefits of this banking RPA bot
Today, the bank’s Regulation D violation-letters process is transformed. It’s automated with robotic process automation. What used to take Margie 12 minutes per customer, is now accomplished by the bot in just 60 seconds. It’s a 1,000-percent-plus productivity gain. Bank-wide, it’s saving 345 person-hours per month, while eliminating errors and improving customer service. It’s also transformed Margie, who now spends her days far more productively, not to mention happily. Like so many other knowledge workers whose lives have been transformed by RPA, Margie loves her Reg. D bot.
As we’d noted above, Regulation D violation letters are just the tip of the iceberg—in this case, one of 89 RPA-friendly use cases, amid nearly 450 standardization opportunities, bank-wide.
If your bank is looking to quickly automate its production of Reg. D violation letters—or explore any of countless other time- and labor-saving use-cases— contact The Lab today at (201) 526-1200 or info@thelabconsulting.com.