Fraud

CaseWare IDEA Applications

IDEA can be used to identify unusual and suspect transactions as part of a fraud investigation. There are a number of tools to prevent and detect fraud including personnel vetting, independent authorization of transactions, and observation of employees. IDEA does not replace any of these techniques but adds a tool that is particularly useful in the right circumstances.

Clearly the relevant information to check must reside on accessible computer files. Generally the larger the volumes and the more detailed the information held, the more useful IDEA becomes. Using IDEA on copies of the files can be done without alerting those under suspicion and can build up evidence to prove what has occurred. However, it should be noted that there could be problems in submitting computer records as evidence to a court. Hence, expert advice should be sought if information from IDEA needs to be submitted. Further, this guide does not cover dealing with fraudsters for which help from a specialist should be sought.

Three of the most common areas of fraud are Payroll, Purchases, and Banking.

Banking, Savings & Loans (Building Society) Frauds

Banking as well as Savings & Loans and Building Society systems are normally subject to strong reconciliation controls, but controls need to be of a preventive nature to stop fraud.

This is particularly the case with Funds Transfer where subsequent tests may establish how it happened but not stop the loss. Other types of fraud can be on-going and spotted by analysis and exception testing. This is true of dormant accounts, revolving loans, and money laundering. IDEA is a useful tool for testing in this area.

Money Laundering

• Identify accounts with a large average value of transactions. It may be necessary to first convert the transaction value to an absolute amount (use@Abs) to pick out both large debit and credit transactions. (Use Summarization and then a Virtual field to divide the value by the number of records). It is common for there to be a small number of high value transactions through an account being used for money laundering.
• Identify matched debit and credit transactions on the same account within a short time period. Such transactions would be identified through Duplicate Key Detection using the account number and absolute transaction value as the key.
• Search for large rounded transaction values (e.g., $250,000)
• Identify multiple accounts for particular individuals
• Identify large cash deposits
• Test customer identification procedures are in operation by searching for missing data in date of birth, Social Insurance Number, Social Security Number, and National Insurance Number
• Cross-check customer addresses against mailing address lists

Dormant Accounts

• Ensure accounts with no movement have been flagged as dormant
• Identify dormant accounts with movement
• Check transfers from dormant accounts to staff accounts
• Check changes of address to dormant accounts
• Cross-check new addresses to employee addresses

Revolving Loans

• Check for loans with the same address, postal code, or name
• Check loans advanced to staff accounts

Purchase Frauds

Purchase fraud is probably the most common type of fraud in an organization. It may be the simple submission of a dummy invoice, the reuse of another valid invoice, the withholding of a credit note, or a more complex arrangement. Many frauds involve the manipulation of the payments information on personal accounts within the Accounts Payable system. Examples include the creation in the ledger of a fictitious supplier or branch of a genuine supplier, or reactivating a dormant account. Particularly vulnerable are miscellaneous accounts, but the fraud perpetuated on a genuine suppliers account (with or without their connivance or knowledge) must not be overlooked. The cost must be charged somewhere and there are often accounts which are more loosely controlled than others, especially accounts with high levels of transactions where a fictitious item can be buried.

Many purchasing systems are complex with automatic re-ordering so that once a supplier has been set-up and/or a requisition input, payment will be processed automatically. IDEA can be used on a number of files: supplier master, purchase ledger, payments history, or purchase invoices. It depends on the system, the available data and the nature of possible frauds as to which test is best. The following are a few examples.

Supplier Master File

• Using the first five or six characters of the name, match supplier names against a list of employee surnames from a payroll or personnel file (use combinations of the @ Ltrim, @Isini, @Mid, @Strip, and @Soundex @Functions). (Europe only)
• Test for accounts without VAT numbers, duplicate VAT numbers, or VAT numbers where the check digit is incorrect. (Generally, fraudulent accounts do not have valid VAT numbers and use either someone else's or a dummy number.)
• Examine purchase ledger transactions for entries at or just below the approval level of managers. If the computer system captures the approving authority for a transaction, examine the value distribution for each manager
• Test to see if amounts are being approved at or just below break points in authority level by a value distribution across the whole ledger. If approval authority is not directly available, perform subsidiary analysis by types of supplier or approving department (e.g., marketing)
• Look for split invoices to enable approval to be kept by an individual
• Extract all invoices within 90% of an approved limit (preferably for a suspected manager or department) and search for all invoices from that supplier. Sort by approving manager, department, and date to identify possible split invoices or summarize payments by invoice number to determine how many part-payments have been made for each invoice
• Test for duplicated invoices using value and supplier code as the key fields for one test and purchase order number for another. The second processing of invoices can be used to establish a value on the purchase ledger to make a fraudulent payment. (This will also pick up accidental duplication.)
• For organizations which are eligible to reclaim VAT on specific items (or from specific suppliers), ensure that the correct amount of VAT is being reclaimed

Questionable Invoices

• Identify invoices without a valid purchase order
• Look for invoices from vendors not in approved vendor file
• Find invoices for more than one purchase order authorization
• Identify multiple invoices with the same item description
• Extract vendors with duplicate invoice numbers
• Look for multiple invoices for the same amount on the same date
• Find invoice payments issued on non-business days (e.g., Saturdays and Sundays)
• Identify multiple invoices at or just under approval cut-off levels

Journals

• Identify the number and value of purchase journals, particularly those transferring amounts into minor accounts

Payments

• Search the payments file for payees without "Inc", "plc", and "Ltd" in their names to identify payments to individuals (using the @Isini @Function)
• Stratify the size of payments and extract any exceptionally high payments
• If payments are made by electronic transfers, extract lists of bank codes and account numbers from both the P/L payments files and the payroll. Compare to see if any accounts match