Yesterday, I sat in a board meeting presenting my completed forensic investigation report related to a recent fraud at their company. As the individual board members wrestled with the realities of my presentation, I heard several board members utter what I have heard so many times in the past… “we just trusted them”.
Yes, unfortunately with the continued uptick in fraud occurrences, the most common problem we encounter is the company that “just trusted” their CEO, CFO, accountant, clerk, etc. etc. just a little too much. However, if we ever get to the point in society where we determine that trust is not allowed, not an option, well… I’m not sure I want to go there.
So how do we balance the trust that we should place in our employees with the certain accompanying fraud risk?
The answer can be taken from the pages of history. In 1987, during the nuclear arms treaty negotiations between President Ronald Reagan and Soviet leader Mikhail Gorbachev, Reagan consistently joked with Gorbachev that he would sign the treaty, and would "doveryai, no proveryai" – Trust, but Verify. Gorbachev always laughed when Reagan said this, and at the official signing of the treaty, upon Reagan’s final attempt at speaking in Russian, Gorbachev asked him “why do you always say that?” Reagan’s response? “Because I like it”.
The Monitoring element of an anti-fraud program speaks directly to the issue of “Trust, but Verify”. An anti-fraud program is rendered useless if there is no Monitoring, no compliance testing, of the included internal controls. The absence of Monitoring in a designed internal control system is akin to President Reagan blindly trusting Gorbachev, with no verification… no “proveryai”.
So why should we adopt the “doveryai, no proveryai” response to internal control design?
Because we like it… or at least we should.
In a recent fraud we investigated, the perpetrator was able to pocket a little over $1.3 million by having his company reimburse him for “business travel” that he paid for personally, and by having his company make payments to two of his personal credit card accounts with VISA and MasterCard. The fraud is much more interesting when one knows that the company didn’t even have a VISA or MasterCard for business use. They only had an American Express card.
Additionally, there was not one single valid receipt turned in with these reimbursement requests. Instead, the attachment to the reimbursement request was a stack of small pieces of paper stapled numerous times between two pieces of copy paper. As the individual responsible for approving the reimbursement reviewed the stack of info, he observed a reimbursement request with a thick attachment of supposed “receipts”. As you can guess, he never unstapled the attachment which would have revealed the fraudulent nature of the reimbursement request. Did we get that? He never verified, he just trusted… for a period of ten years!
When we reviewed the system of internal controls at this company, we concluded that it was a good system. It required the requisition, the necessary approval places on the requisition, the requirement to attach receipts in support of the requisition, etc. However, as stated previously, without any verification, without any compliance testing that the controls were being followed, the established processes were rendered useless.
So what do we do with this information?
Hopefully, this example makes one aware that maybe fraud prevention isn’t that hard. The requirement to monitor the implementation and effectiveness of an internal control is present in most internal control structures we encounter. The problem lies in that the “authorization” person is too busy to look through that entire stack and, when coupled with the fact that nobody internally is testing compliance with that control, the fraud is easy. So, 1) do your job, and 2) have someone monitor that the job is being done. Simple, Easy… and most importantly, effective.
The Monitoring element of an anti-fraud program asks and answers two questions:
“Are processes and controls working as intended?”
In order to answer this question, compliance testing must be performed. If the answer to the question is “no”, this testing can also aid in determining whether this is a human problem or a design problem. If it is a human problem, management must deal with that person accordingly. If it is a design problem, then the second question can be asked:
“Are there processes or controls that we need to refine, add, or delete?”
Once the compliance testing has determined the existence of a problem, modifications of controls can be implemented. Additionally, it is always a positive experience to include those that have to perform the control be allowed to have input into the design. This is what we refer to as a process of inclusion. Inclusion translates to the hope that those that are part of the design of a system are less likely to steal from that system.
As you have the opportunity to influence the design of your company’s anti-fraud program, shift the final focus to the Monitoring element. You may be surprised what you find.