Regardless of whether the new millennium starts on January 1, 2000 or 2001, its advent provides opportunities for undetected fraud and for the continuation of existing fraud schemes. In fact, most frauds abetted by the so-called computer systems’ “millennium bug” will be faits accomplis before the turn of the century.

Fortunately, analysis of the characteristics of “Fraud 2000” suggests strategic initiatives that can help to detect and prevent fraud as well as mitigating resulting direct and indirect losses.

Fraud and the Millennium Bug
Contrary to popular belief, computer systems problems with the Year 2000 (Y2K) were not caused by computer programmers’ needs to store dates with six characters instead of eight in order to save valuable storage space in primitive computers. A system to encode and decode a particular date using only three characters of information would last for over 45,000 years! Rather, the date format decision was prompted by familiarity of the visual representation of dates with two-digit years. As time passed and the volume of data stored this way increased dramatically, the cost of changing data and systems was an unpleasant thought in the minds of IT managers. Why not let some other manager take it out of their budget?

Fortunately, now that we have run out of time, software development costs have come down considerably. However, the cost of converting the old data to fit new systems is still prohibitive in most cases. The least expensive thing to do is to abandon the old data, thereby closing an important window on the past. We need this window to discover, qualify and quantify fraud. In some instances, the window may be partially ajar, but the cost of opening it wide enough to mine the old data properly may be greater than the value of the fraud, account imbalance or anomaly being investigated.

Fraud 2000 and Y2K Insurance Policies
In addition to a Year 2000 conversion closing the window on a past fraud, there is also a potential problem with fraud masquerading as a Y2K problem. Like the recently departed employee or El Niño, Y2K conversions may take the blame for everything. If a fraud is successfully disguised as a Y2K problem, whether intentionally or inadvertently, it could be covered by a Y2K insurance policy even though the policy excludes employee dishonesty. Further, the exclusion may even inhibit the search for fraud!

There are additional reasons for the insurance industry to be concerned with Fraud 2000. Both underwriters and brokerages are vulnerable to internal fraud. Underwriters have some of the oldest, largest and most complex systems and therefore some of the most extensive Y2K conversion programs. This, coupled with the high incidence of fraud in large companies (62% in 1966 and 57% in 1997 according to the annual KPMG survey), is cause for concern. While smaller brokerages will be less concerned with fraud related to their own Y2K compliance efforts, they should be aware of problems in dealing with underwriters’ and others’ systems and the potential for a post-dated cheque lapping scheme as described below.

The Red Flags of Fraud 2000
The red flags of Fraud 2000 are a combination of characteristics of Y2K compliance efforts/conversions and business operational/accounting procedures.

If a firm (eg. insurance brokerage) uses post-dated cheques to collect revenue (eg. insurance premiums) and its Y2K conversion will obscure past post-dated cheque payments, then the company is vulnerable to a simple lapping scheme using these cheques.

If Y2K conversion implies losing (electronic) details of sales transactions and/or bank deposit activity, then it can become too onerous to manually sift through bank statements and sales slips to find cash flow irregularities which could be caused by cheque/cash lapping schemes or other employee defalcations.

If Y2K conversion entails losing or obscuring return/exchange data, inventory transactions, related sales and supplier accounting information, then the ability to investigate unusual inventory shrinkages, high returns/low sales, item substitution and supplier exchange anomalies is significantly hindered.

Detection, Prevention and Mitigation Strategies

• Watch for the Red Flags of Fraud 2000: Y2K conversions that close the window on past information coupled with anomalies in business operations. Test for anomalies before conversion.
• If these or similar anomalies are found, then a more detailed Fraud 2000 audit may be warranted.
• Review your Y2K conversion plan with regard to the Red Flags of Fraud 2000 and to fraud in general.
• Open the window to the past by archiving old data in a format that can be mined in the future.
• Review and test your new Y2K-compliant systems for fraud accessibility.
• Implement anti-fraud measures in your Y2K-compliant systems.
• Develop a systems evolution plan and review it at regular intervals. Beware of system changes or enhancements that may provide the event necessary to close and restart or expand a fraud such as a lapping scheme.

Deployment of fraud detection, prevention and mitigation strategies and systems prior to Year 2000 conversions can not only alleviate these problems now, but they can provide a sound basis for fraud elimination in the new millennium as part of an integrated systems evolution plan.
 

The Forensic Systems Group provides data management, analysis and reporting services and systems for forensic and investigative applications. Stephen Markson, Principal, has been developing financial systems since 1967. Telephone 416-482-2140. Email smarkson@ForensicSystemsGroup.com. 500 - 120 Eglinton Avenue East, Toronto ON M4P 1E2.