|
More than a year ago, Nelson had accepted a promotion requiring a transfer to New Orleans from Dallas. The company extended him a $15,000 bridge loan, temporary funds to cover moving and household expenses. Nelson never paid back the loan, however, even after repeated requests to do so. Unbeknownst to the company, Nelson had been in serious hock for years. He and his wife just couldn’t seem to control their spending. With creditors hounding him, Nelson had taken the $15,000 and paid some of his most pressing debts. Now, with the boss facing him, he didn’t know what excuse to use this time for not paying back the company. But the boss was beyond being mollified with any more excuses. “Nelson,” he said, “the company has made it pretty clear: If you don’t get this debt taken care of, it’s going to cost you your job. Do you understand?” Nelson understood. Necessity being the mother of invention, Nelson concocted a plan made possible only by an internal control deficiency at the company big enough to drive a truck through: unrestricted access to “live” data (read: customer accounts). Even as the bank’s chief programmer, Nelson never should have had access to such data, but he did. That could have been because he was the principal architect of the entire computer system.
The first step of Nelson’s plan involved opening a savings account at the bank under someone else’s name. In this case, he chose the ID of his own elderly, infirm uncle. Once the account was active, Nelson set about reprogramming the bank’s computers to accommodate a highly complex and seemingly foolproof lapping scheme. Because Nelson needed $15,000 all at once, he easily located a customer checking account with a large balance. But since he knew a funds transfer would create a record on the customer’s statement, he removed the funds from the “ending balance” field on the statement itself. He transferred the money to the uncle’s account, over which he had signature authority. Nelson debited the uncle’s account and credited his own, using the proceeds to pay his bills. The bank’s computers were programmed to print account statements throughout the month (for example, customer A’s statement mailed on the first day of the month, customer B’s on the second and the last one on the 30th). That being the case, Nelson figured he would have use of the funds for 29 days—no more. So he programmed the computer to simply “roll” the $15,000 through the ending balance field on other checking accounts according to a predetermined schedule. Nelson’s plan, in effect, was to let the money bounce throughout the computer program until he could legitimately repay his “loan.” Alas, this method was too easy for Nelson, and therefore too tempting. He rationalized that the bank wouldn’t find out or even miss the cash. So he continued to “loan” himself more money to pay off other pressing obligations. When the amount ballooned to $150,000 and involved thousands of customer checking accounts, Nelson’s ingenious 29-day computer program failed to reverse some transactions in time to avoid detection. In his haste, he forgot there were only 28 days in February. Customers started pouring into the bank with statements in hand showing a major discrepancy: Their ending balances last month were different from the beginning balances this month—a mathematical impossibility. Although Nelson initially blamed the problem on a programming error, he finally confessed to his boss what happened. He had always planned to pay the money back, Nelson promised solemnly, but he was at a loss to explain exactly how he could do that. Ever the nice guy, Nelson helped the authorities gather the evidence to convict him of embezzlement. It’s a good thing he did, too. Chasing down every single transaction would have been extremely time-consuming. Nelson’s cooperation got him only 15 months as a guest of the Louisiana penal system. ROBBING PETER BUT FORGETTING TO PAY PAUL If Nelson had been anything other than a rank amateur, he never would have picked lapping as the scheme of choice for covering cash thefts. Although he managed to lap customer checking accounts for about nine months—no small chore—Nelson’s plan was probably doomed from the outset. That’s because lapping almost always goes beyond robbing Peter to pay Paul. Once the first attempt is successful, lapping tends to increase at exponential rates. Now, the fraudster has to steal from other customers. Then, there are many accounts to keep track of. Therein lies the fraudster’s pact with the devil: The more lapping occurs, the greater the chance of making a mistake. That’s exactly what happened to Nelson. In his case, even his “move-the-money-around” program couldn’t keep track of the thousands of transactions. So when an accounting student once asked me the best way to detect lapping schemes, I couldn’t help myself: “Time,” I replied, only partially in jest. “In time, lapping schemes will invariably reveal themselves.” A LIST OF SINS Because of Nelson’s sins, a lot of people in his company suffered. The boss lost a valuable computer programmer and long-term employee. Since the prosecution of Nelson drew headlines, the bank lost credibility with some of its customers, likely costing it many multiples of the $150,000 he stole. Nelson’s coworkers at the bank suffered a loss of morale. Management was embarrassed. Nelson’s family had to ask for public assistance while he was imprisoned. But Nelson wasn’t the only one at fault in this case. Take, for example, the bank’s upper management. It is ultimately responsible for the flawed system of internal control that permitted Nelson to commit his crime in the first place. Not only were there computer system problems, but the bank never should have allowed Nelson to open an account using the identification of a relative 40 years his senior. And management did not recognize the signs of a financially strapped employee. Had someone done so, the company might have sought an alternative to forcing Nelson into a tight corner; desperate people do desperate things. Many large companies, for example, provide financial counseling to troubled debtors. The bank’s external auditors should have detected the fact that Nelson could both program and modify customer accounts—a serious deficiency. The internal auditors should have spotted the glaring control weakness long before that. TURNING WATER INTO WINE To the bank’s credit, it decided to do something positive after Nelson’s fall from grace. First, it closed the internal-control hole. Second, the company appointed an ombudsman to counsel employees in times of stress—financial and otherwise. Most important, it implemented companywide antifraud training to sensitize its managers and employees to not only how workers commit fraud, but why they do it in the first place. When putting
together its employee video-training program, the bank went
looking for an expert to talk about the fraud problem. It
found one: From behind prison walls, Nelson—now full of
remorse—volunteered. He looked directly at the camera and,
through the tears, told his own story.
JOSEPH T. WELLS, CPA, CFE, is founder and chairman of the Association of Certified Fraud Examiners, Austin, Texas. Mr. Wells’ article “So That’s Why They Call It a Pyramid Scheme” ( JofA Oct.00, page 91) won the Lawler Award for best article in the JofA in 2000. His e-mail address is joe@cfenet.com . | |||||||||||
Lapping It Up
A skimming method doomed to failure over time.
BY JOSEPH T. WELLS
elson, a computer programmer for a financial
institution in New Orleans, sat across the desk from his
boss. Nelson flinched when the boss told him the news that
he, an 11-year company veteran, was in trouble with the home
office in Dallas because of irresponsible behavior. 
