Conflicts, Part II: A Process Perspective

Last week we had a post on managing conflicts of interest that proved quite popular with compliance officers. Today I want to circle back to that subject because I also heard from several internal audit leaders, who had quite a different perspective on how to handle this challenge.

Essentially, their view was that an organization should address potential conflicts of interest as part of other routine business processes. You embed checks for conflicts of interest into, say, purchase orders or vendor onboarding; and even engineer your ERP software to make those checks automatic. Then the company’s risk of missing a conflict goes down — or, at least, liability for missing it shifts onto the employee, since you’ve asked them to certify their statements about potential conflicts.

Of course, nobody should be surprised that internal auditors would see the issue this way. Their whole purpose is to find weaknesses and risks, and then recommend business process improvements to streamline those threats out of existence. So how much can that approach help with managing conflicts of interest, and where does it still fall short? Let’s discuss. 

One conversation I had with an IT auditor last week captures things nicely. He said Second Line management functions (purchasing, finance, HR, and so forth) could insert a step in routine business processes where employees are required to certify that, to the best of their knowledge, they have no conflicts of interest in a transaction — hiring a vendor, onboarding a third party, speaking at an outside event, or whatever. 

“You can do that in SAP and Oracle,” this auditor argued. “Have the employee declare, ‘I certify, by processing this transaction, that I don’t have any of these following conflicts that you list.’ I don’t get why that hasn’t happened. That seems straightforward.”

“I can’t believe technology can’t help here,” he continued. “Or, at least, that existing technology can’t be supplemented to help this to some degree.” 

What We Mean by ‘Managing’ Conflicts

My IT auditor friend is not wrong. Compliance programs already use employee certifications for risks as varied as SOX compliance and the accuracy of financial statements, to FCPA compliance and the legitimacy of third-party intermediaries you might want to use in overseas deals. So why not this same strategy for other conflicts of interest? 

Indeed, I tried to stump my friend by saying that certifications might work for financial transactions, but aren’t a good solution for non-financial issues such as favoritism in hiring. He shot down that objection swiftly. 

“Easy,” he said. “Just insert a step into Workday or whatever HR system you use, making managers certify, ‘I am unaware of any improper personal relationships between myself and the candidate’.” 

Another auditor framed the issue as follows. For individual employees, compliance is a choice. That’s not true for corporations — like, a company can’t just decide that it’s going to ignore the GDPR or not file quarterly financial statements — but an employee can choose to ignore your policies, and risk the consequences. 

Obviously an employee decided to behave like that introduces compliance risks to the larger enterprise. The company can counteract that risk by requiring certifications, which shift the liability for non-compliance back onto that rogue employee. You get to tell regulators, “It’s not our fault! The employee told us nothing was amiss!” 

That’s nothing new in compliance land. Financial employees have had to certify and sub-certify the accuracy of financial data pretty much since the Sarbanes-Oxley Act went into effect nearly 20 years ago. We’ll probably see the same take root among chief compliance officers forced to certify the effectiveness of their compliance programs to the Justice Department: have your minions sub-certify and sub-sub-certify further on down the line, so senior leaders and the enterprise overall can dodge as much liability as possible. 

So, again — why not use the same approach to manage conflicts of interest? Certifications give the compliance team documentation. Then, if you do have a conflict of interest (perhaps it comes to your attention through the hotline or an audit), it’s just a brute-force matter of investigating your way to a resolution. 

Or, as my auditor friend said, “You can turn to the employee and say, ‘Look, you signed it. You said you were not aware of it; we can prove that you were aware of it. We can prove that you were dating the job applicant, or the customer was your brother, or whatever. We can prove you knew it, or should have known it, so you’re fired’.” 

Being able to prove a conflict of interest, so you can take necessary action to rid yourself of the risk, is definitely a capability that compliance teams want. My auditor friends say that’s possible by astute use of technology, to embed and automate conflict checks into routine business processes. 

It’s a point worth contemplating.

Know the Limitations

All that said, those breezy statements from the audit community assume a few important points — points that the compliance team doesn’t have the luxury of assuming.

First, if you want to compel the disclosure of potential conflicts of interest, you still need to know what your potential conflicts are and communicate those issues to employees. That was one big theme in my previous post about managing conflicts of interest: the compliance officer needs a solid inventory of potential conflicts (usually derived from your risk assessment) and then must craft a disclosure policy that mentions those issues, but doesn’t present them to employees as a final and definitive list.

Second, encoding that list of potential conflicts into SAP or Oracle or some other ERP software system might not be easy. You could present them as an actual list, but that runs the risk of employees thinking, “My conflict isn’t on this list so maybe it isn’t a conflict after all and I’m good.” Or you try language like “I am unaware of any improper personal relationships,” like we mentioned above — except that depends on employees understanding what conflicts might be in a broader, conceptual sense. That’s fine, so long as your ethics and COI training is up to the challenge. 

Third, all of this assumes a certain maturity in enterprise software systems: that your enterprise does use SAP, Oracle, Workday, or other ERP software systems; and your people know how to modify standard workflows to automate tasks such as checking for conflicts of interest. 

That’s not necessarily the case at a lot of businesses. Startups or high-growth companies might not have ERP systems they can easily reconfigure. Highly acquisitive companies might have multiple ERP systems, where configuring all of them the right way (especially so that you, the CCO, can see consolidated enterprise-wide data) is no easier. 

Fourth, even if you do engineer your workflows to capture all this information, it’s still just information at one moment in time. You might have employees who correctly certify they’re unaware of any potential conflicts; then the company’s business model changes, and a relationship that hadn’t been a conflict now is a conflict.  

That change of circumstance is not on the employee to clean up; it’s on the company. So you need a mechanism to understand when potential new conflicts might emerge, and then re-canvass employees again as necessary to identify any new conflicts. 

Huh. No wonder so many compliance professionals say conflicts of interest are so maddening.