Automation of Third-Party Due Diligence: Before Starting

So there we were, me and a fellow compliance enthusiast, talking about automation of third-party risk management. This is the sort of conversation you have when you’re me.

Automating portions of your third-party risk management is a great idea. After all, large corporations are awash in third parties these days. According to the 2016 Kroll Anti-Bribery & Corruption Report, 17 percent of respondents said they had more than 25,000 third parties. Other surveys routinely find that most large companies have several thousand.

At the same time, the compliance risks caused by third parties are increasing. Almost every significant enforcement action around the Foreign Corrupt Practices Act involves a third party somehow. Data breaches can be caused by third parties, as we saw in the Target breach in 2013 (when hackers infiltrated Target’s payment systems via one of its HVAC vendors). Human trafficking problems are inevitably caused by some third party far down your supply chain.

Given all those risks and third parties, I don’t see how a compliance program can work well without some level of automation, really.

So where do you start?

The natural inclination when you ponder that question is to think in terms of tasks. Which routines of due diligence and monitoring are so rote, so repetitive, that they can be turned over to an algorithm and an exhaustive database of information?

As natural inclinations go, that’s not a bad start. But compliance officers—specifically chief compliance officers, in charge of a large and complex compliance program—should beware the pitfall here. You don’t want to rush into tactical decisions like which tasks to automate, before considering the bigger strategic question.

That question: How can you best deploy the resources you have to manage third-party oversight?

Technology that can automate some of your third-party oversight is one of those resources, certainly. We just need to remember automation’s true purpose before we deploy it—to strengthen the compliance capabilities of your human team.

That’s a point worth belaboring. The goal of automation shouldn’t be to save money, or to reduce staff, or to save time. If any of those things happen along your way to automating third-party oversight, that’s great—but they are only side benefits to the main goal. The main goal of automation should be to empower the humans helping your compliance program to do that job better.

What ‘Empowerment’ Really Does

A great way to think about this comes from our friends in the IT security department. They’re desperate to automate tasks because they don’t have enough skilled cybersecurity people, period. No matter what a company’s cybersecurity budget might be, it still struggles to keep pace with the sheer volume of threats because there aren’t enough cybersecurity engineers to hire.

For IT security, then, automation is more about enhancing the capability of a junior analyst, so he or she can make decisions more efficiently and do the work of, say, 1.25 junior analysts. That alleviates the burden on senior security analysts, who can focus on more sophisticated jobs like identifying outside attackers rather than helping overworked junior analysts.

In other words, automation isn’t done for automation’s sake; it’s done to ensure that your most valuable assets are assigned to your most important tasks. A compliance officer should go through that same strategic thinking exercise about how all your compliance program assets, human and IT alike, fit together before starting any automation project.

That strategic perspective is very much in the spirit of what the compliance community says all the time: “the business unit owns the risk.” If that’s true—if we want responsibility for compliance risks to be assigned to specific people in the business units—then automation should exist only to help those persons manage their compliance risk effectively.

If we view automation as a way to remove a risk somehow, to take it off the shoulders of the business unit, that’s dangerous thinking. It falls into the trap of the technology owning the risk. And that’s just another way of saying the compliance officer owns the risk, since you’re the one configuring this constellation of IT and human assets. The IT should only support the humans, not relieve them of their duties.

Automation Examples

Let’s bring some specifics to this idea. One obvious target for automation is due diligence of third parties: screening them for adverse media reports, searching for owners who are politically exposed persons, and the like. Many vendors offer this service and it’s just the sort of rote, bulk task that should be automated.

The question is how you design all the other compliance and risk management processes that still exist, automation or not. For example, some of your third parties will be flagged as higher risk, and need follow-up attention. Do you want to impose a strict rule eliminating those third parties from your business? Or do you want to assign business unit people to engage with those parties to decide how to proceed?

You could go the route of a strict rule—but then you’re just automating the higher-level task of deciding the fate of potentially risky third parties. Is that what you want to do? What message does that send to business unit leaders? (Hint: “Oh, someone else handles due diligence so I don’t have to think about it.”) Or do you want to design policies telling business unit leaders how they should follow up with a higher-risk party and decide its fate?

Ultimately you’re going to split that difference somehow, drawing a line for some automatic rejection of high-risk third parties, with human review of those on the other side of that line. Where will that line be? Who does the reviewing? What documentation will the compliance department require from that person? What part of that documentation process can be automated?

The answers to those questions will depend on your company, and how it treats the compliance function. Just be sure you know and like the answers before you daydream about automation too much.