To Automate Or Not To Automate:That Is The Question

At ABA's 1996 Compliance Conference, Stuart Lehr, Vice President and Manager, Corporate Compliance for U.S. Bancorp shared advice on the risks and benefits of automation and how to use automation to enhance a compliance program.

The Benefits of Automation
Automation can make some compliance tasks "automatic" and therefore effective. By providing controls for complex tasks, automation can reduce the bank's exposure to compliance liability. If a step such as completing a form or running a calculation can be automated, the bank can control the accuracy of the task.

Automation is particularly suitable to centralization and standardization. As banking companies grow, they tend to move toward centralization. Back office functions are particularly suitable for centralization and automation. For example, customer service for existing accounts is often in one central place. Centralization provides savings because you can build one compliance system to support the entire company. The system ensures standardization and consistency for each automated function. One of the most significant benefits of automating compliance is the reduction in training needs. Tasks that staff must perform become more limited, and the corresponding training is reduced. As an additional benefit, the training for staff can be focused on customer interaction while the system takes over the management of the function. With a good automated Regulation CC program, you don't need to train staff to count the number of days for specific types of holds.

Training itself can be automated. With interactive computer programs, the centralized compliance department can ensure that accurate and complete information is provided to appropriate staff. Systems can also track who was trained, when, and test their knowledge.

Whether designed by bank staff or purchased from a vendor, a good automation program should increase staff efficiency. A system can perform automatically certain tasks that otherwise take staff time, time to learn and time to perform. With good automation, bank staff can be freed up to be responsive to the customer and sell.

Automation can save the compliance manager or auditor time also. To check for compliance, you only need to validate that the system is working and that it is correctly used. In other words, you validate the process rather than audit a series of transactions.

To the extent that you successfully automate compliance tasks, the system can play a significant role in loss prevention. Once tested and verified, accuracy should be guaranteed. The system that performs thus prevents losses from fines, penalties and lawsuits based on inaccurate disclosures.

Automation can actually enrich the resources you have to work with. For example, databases obtained and maintained by systems can be used for multiple purposes. The new, more data intensive CRA requires collection and maintenance of a large database. With automation, you can make other uses of the data. For example, it may be useful in evaluating or updating the Bank's business plan or it may help with the design and marketing of new products.

Risks of Automation.
Automation isn't necessarily an "automatic" solution to a bank's compliance problems. Balanced against the many benefits of automation are some very real risks.

The largest automation problem most compliance managers face is limitations on access to the resources needed to develop and maintain automation tools. Compliance may have to stand in line and wait for the system developer's time. And while waiting, compliance must continue as a manual process.

Not only can it be difficult to get access to the valuable time of the automation specialists to develop a system, it can be even more difficult when changes or support is needed later. If you cannot get access to the "techies" when the regulation changes the process or disclosure, you can be saddled with a system that doesn't comply and lack the ability to change it.

Often, the compliance manager is told to develop a manual "fix" for the problem, i.e. a step that bank employees must do by hand to perform the new compliance requirement. Not only does this consume much of the time the system was supposed to save, it has all the risks of non-automated compliance. You need to be able to win the battle for the limited time. Lehr recommends reducing to FTEs (Full Time Equivalents) the time it will take bank staff to work around a system that needs updating.

To make really effective use of the systems developers when you finally get to them, you need skills beyond compliance. This is a project with a diversity of team members. You need project management skills to stay on track. Also, having a compliance team member with technical skills is highly desirable.

If the system is wrong, you have a systemic error that will occur every time the transaction occurs. Any system needs to be carefully checked before it is put into use. To check the system, it should be tested with as many varieties of situations and possibilities as a creative test team can think of. It should be approached like your most rigorous audit. Don't implement a new system until it passes every perverse test you can think of.

System overrides can be a source of unanticipated compliance violations. If the system allows overrides, this "permission" will negate the benefit of the system. After all, it is only human to try to get around the system. In every branch, there is someone who wants to make the system do what they want for a particular customer, or who thinks they can design a better way to do it. Lehr recommends testing the system for immunity to overrides and computer hacks. Have your test team try to get around the system. Use the most creative or perverse minded computer hacks you can find. If they succeed in getting around the system, find a way to lock it up before you introduce the system to general use.

The more integrated your system is, the more effective it will be. Buying piece-by-piece solutions to compliance problems can saddle your bank with a burdensome series of programs that fail to reduce your burden. Each piece has to be used in its own way and may offer no additional savings unless you can build interfaces that enable the pieces to support each other.

Copyright © 1996 Compliance Action. Originally appeared in Compliance Action, Vol. 1, No. 12, 7/96